Pull out npm scripts into another file with p-s

Instructor: [00:01] As you start to get more and more npm scripts, you might be looking for an alternative way to manage them. Think why there is a node package called npm package scripts or p-s. I'll install it as a dev dependency.

[00:16] An easy way to get started is to type node_modules.bin p-s or nps for short and then init. What this did is to remove the npm scripts from our package JSON and move them into a new JavaScript file called package-scripts.js.

[00:34] In its place, npm left two scripts in our package JSON. One is start, which will run the default script in package scripts, and the other is test, which is just a alias to the TestScript and package scripts.

[00:46] On the terminal if I run npm start, it'll run the app just like normal. Let me cancel that. If I run npm t, it will run our test like it would before. Since we moved our scripts to another file, we can just say npm run in your module to get a list of our available scripts, but we can't say npm start-----help.

[01:06] The reason we provide the first double dash is to pass the flag on to the npm script and not npm itself. Now, we see a list of all the scripts available to us in the package-scripts file.

[01:18] Since that is somewhat cumbersome, if you don't already have a help script defined in your package script file, you could just run npm start help and nps will display the usage information for you.

[01:28] Before we run any other scripts, we need to make a few changes before they could run. Before we do that, one of the upsides of having in JavaScript file is we could add actual comments. For tests, we can have a comment that's says, "Run our mocha tests."

[01:45] We could go one step further and make test an object. Then, we'll take our script and add it to a key called script. Then, we can have a description. Inside of it, we can have a description from above, run our mocha tests.

[02:04] We'll delete our comment. Now in our terminal, if we say npm more on help and scroll up, you'll notice that it will show the test key description and the script itself, which is pretty cool.

[02:17] Now, let's go and fix our scripts. One thing that we use to have a lead by, it's not supported in package scripts, is npm run all. We need to use a different technique which we could easily say nps, and we could provide a common element list of all the scripts that we want to run like lint.js, lint.css, and lint.css.fix.

[02:40] Likewise, we'll also need to update our watch script. Here, we'll say nps and thankfully nps understands the parallel flag. You don't have to worry about that. Then, we'll say watch.test, watch.lint. We'll save that.

[02:56] We'll also need to update our BuildScript. Coming here, we'll say nps build.html, build.css, and build.js. Finally, we'll need to update our server default script. Here, we'll say nps. We'll keep the parallel flag. Then, we'll say server.create, server.launch.

[03:22] Another thing that nps doesn't support our pre or post scripts, but thankfully those are pretty easy to work around. For example, in our post start near the top, we just delete that and append to the default &nps build, server.

[03:40] For our pretest, we'll just delete that. In our test, we'll add a default. For its script, we'll say nps lint, test.run, and for our script we'll rename that to run. Import our description inside our default to describe what's going on.

[04:01] For a post cover, we'll delete that and put it into our cover object. Then, we'll rename it to clean. In our default, where && in nps cover clean. We'll also need to move our prebuild into our BuildScript. We'll call it clean as well. Up on top, before we do build.html, we'll say build.clean.

[04:29] Then we could delete our prepush, since it's the git hook that we're using with husky. We'll move that over to our package JSON script. In here, we'll have a prepush. Then, we'll say nps lint to make sure that we're running our linting before we push to Github.

[04:49] Now if we want to run any of our scripts, we could type npm start and name of one of our scripts, for example, we'll say lint and runs our linting. Or we can dive down into one of the subscripts like build.html, for example. nps also supports the idea of aliasing scripts.

[05:08] For example, if I wanted to run the build HTML again, instead of saying build HTML, I could say b which is an alias to build, .h which is an alias for HTML. That'll run the build.html script as well.

[05:24] For convenience, you could also install nps as a global dependency, although I'd still recommend keeping a local dev dependency as well. Instead of saying npm start lint, since we have nps installed globally, we can interact directly with nps, and say nps lint to run our linting.

[05:44] If you look and remove the complexity of your npm scripts from your package JSON file, then using the nps package can be a viable option.