Giter Club home page Giter Club logo

nps's Introduction

Sponsorship

NPS is being sponsored by the following tool; please help to support us by taking a look and signing up for a free trial.

GitAds

nps

All the benefits of npm scripts without the cost of a bloated package.json and limits of json

nps is short for npm-package-scripts

What happened to p-s?

Build Status Code Coverage Dependencies version downloads MIT License

All Contributors PRs Welcome Donate Code of Conduct Roadmap Examples nps friendly

The problem

Even though npm scripts have a ton of advantages (learn more), it can grow into an unmaintainable mess in your package.json file. Part of the problem is we're configuring scripts in json which has fundamental issues (like no comments).

This solution

nps is a package that solves this problem by allowing you to move your scripts to a package-scripts.js file. Because this file is a JavaScript file, you can do a lot more with your project scripts. Here's an example of a package-scripts.js file:

const npsUtils = require("nps-utils"); // not required, but handy!

module.exports = {
  scripts: {
    default: "node index.js",
    lint: "eslint .",
    test: {
      // learn more about Jest here: https://facebook.github.io/jest
      default: "jest",
      watch: {
        script: "jest --watch",
        description: "run in the amazingly intelligent Jest watch mode"
      }
    },
    build: {
      // learn more about Webpack here: https://webpack.js.org/
      default: "webpack",
      prod: "webpack -p"
    },
    // learn more about npsUtils here: https://npm.im/nps-utils
    validate: npsUtils.concurrent.nps("lint", "test", "build")
  }
};

Or in case you prefer YAML, here's an example of how that would look in a package-scripts.yml file:

scripts:
  default: node index.js
  lint: eslint .
  test:
    # learn more about Jest here: https://kcd.im/egghead-jest
    default: jest
    watch:
      script: jest --watch
      description: run in the amazingly intelligent Jest watch mode
  build:
    default: webpack
    prod: webpack -p
  validate: concurrent "nps lint" "nps test" "nps build"

To use nps, it's recommended that you either install it globally (npm i -g nps) or add ./node_modules/bin to your $PATH (be careful that you know what you're doing when doing this, find out how here).

Then you can run:

nps help

Which will output:

Usage: nps [options] <script>...

Commands:
  init        automatically migrate from npm scripts to nps
  completion  generate bash completion script

Options:
  --config, -c      Config file to use (defaults to nearest package-scripts.yml
                    or package-scripts.js)
                      [default: "<path-to-your-project>/package-scripts.js"]
  --silent, -s      Silent nps output                  [boolean] [default: false]
  --log-level, -l   The log level to use
                    [choices: "error", "warn", "info", "debug"] [default: "info"]
  --require, -r     Module to preload
  --prefix, -p      Prefix for each <script> name
  -h, --help        Show help                                           [boolean]
  -v, --version     Show version number                                 [boolean]
  --help-style, -y  Style of help to use
                    [choices: "all", "scripts", "basic"] [default: "all"]

Examples:
  nps.js test build                         Runs the `test` script then the
                                            `build` script
  nps.js "test --cover" "build --prod"      Runs the `test` script and forwards
                                            the "--cover" flag then the `build`
                                            script and forwards the "--prod"
                                            flag
  nps.js --prefix=test unit functional      Runs the `test.unit` script then
                                            the `test.functional` script

Available scripts (camel or kebab case accepted)

lint - eslint .
test - jest
test.watch - run in the amazingly intelligent Jest watch mode - jest --watch
build - webpack
build.prod - webpack -p
validate - concurrent "nps lint" "nps test" "nps build"

You can also use the help command with a script name

nps help test.watch

Which will output the details of the script test.watch:

test.watch - run in the amazingly intelligent Jest watch mode - jest --watch

Now, to run a script, you can run:

nps lint
nps test.watch
# etc.

But the fun doesn't end there! You can use a prefix:

nps b # will run the build script
nps help b # will display help for the build script

And these prefixes can go as deep as you like!

nps b.p # will run the production build script

Cool stuff right? And there's more on the roadmap.

Also check out the examples. You'll find some good stuff in there (including how to deal with windows and other cross-platform issues).

Note: If you don't like installing things globally and don't want to muck with your $PATH (or don't want to require that your co-workers or project contributors to do so), then you can add a single script to your package.json. We recommend that you use the start script because it requires less typing:

package.json

{
  "scripts": {
    "start": "nps"
  }
}

You don't have to use the start script if you don't want. Note that if you're writing a node application, you're likely using start for starting your server. In that case, you can create a default script which will be run when nps is run without arguments (so effectively it'll work just the same). But if you'd prefer, you can use whatever you wish. For example you could easily create a nps script and do: npm run nps b.

Installation

This module is distributed via npm which is bundled with node and should be installed as one of your project's devDependencies:

npm install --save-dev nps

global installation

You can install this module globally also (this is recommended):

npm install --global nps

From here you can use nps on the command line via one of the installed aliases: nps or nps.

If you do this, you may also be interested in installing the shell autocompletion script. See more about this below.

Getting started

If you're already using npm scripts, you can get up and going really quickly with the init command:

./node_modules/.bin/nps init

or

./node_modules/.bin/nps init --type yml

This will use your package.json scripts to generate a package-scripts.js (respectively a package-scripts.yml) file and update your scripts to utilize the nps binary.

API

CLI

Commands

help

If you have a help script, then your help script will be run. Otherwise, this will output the help.

Note: you can do this with nps --help, but if you're using the start script in your package.json this allows you to run npm start help rather than npm start -- --help

init

As indicated above, this will migrate your npm scripts to package-scripts.

completion
nps completion >> <your-bash-profile-file>

Normally <your-bash-profile-file> will be ~/.bash_profile, ~/.bashrc, or ~/.zshrc.

Note: you should probably only do this if you have the package installed globally. In that case you should probably also normally use the nps alias rather than nps because it's easier to type.

Note: for zsh support, you must enable zsh's bash completion script compatibility mode.

CLI options

-h, --help

Will print out the help you see above (the available scripts are colored ๐ŸŒˆ and come from the config specified/default config).

-s, --silent

By default, nps will log out to the console before running the command. You can add -s to your command to silence this.

--no-scripts

By default, the script's command text will log out to the console before running the command. You can add --no-scripts to prevent this.

-c, --config

Use a different config

nps -c ./other/package-scripts.js lint

Normally, nps will look for a package-scripts.js file and load that to get the scripts. Generally you'll want to have this at the root of your project (next to the package.json). But by specifying -c or --config, nps will use that file instead.

-l, --log-level

Specify the log level to use

-r, --require

You can specify a module which will be loaded before the config file is loaded. This allows you to preload for example babel-register so you can use all babel presets you like.

scripts

To run a script, you simply provide the name of the script like so:

nps cover

And you can run multiple scripts in series by simply adding more space-separated arguments.

nps cover check-coverage

And you can pass arguments to scripts by putting the scripts in quotes:

nps "test --cover" check-coverage
-y, --help-style

By default, nps will dump a very long help documentation to the screen based on your package-scripts.js file. You can modify this output with one of three help-style options:

all gives you the normal default output:

nps help "--help-style all"

scripts will give you only the help information built from your package-scripts.js file

nps help "--help-style scripts"

basic will give you only the name and description of the scripts from your package-scripts.js file

nps help "--help-style basic"

CLI Configuration File

Some of the options accepted by CLI can also be provided in a .npsrc or .npsrc.json JSON configuration file. It will search upwards starting in the directory the nps command was invoked from.

The accepted options are:

  • require
  • config

The other options can be provided in the specified configuration file (or the default package-scripts.js) once it is loaded, but these options need to be provided in order to find and parse the configuration file.

This is can be useful when you have a reqular set of options you need to pass to nps, especially when using series.nps() or concurrent.nps() from nps-utils.

{
  "require": "ts-node/register/transpile-only",
  "config": "package-scripts.ts"
}

That's all for the CLI.

package-scripts.js

Remember, this file is JavaScript, so you can write functions to make things more simple! See other/EXAMPLES.md for examples of cool things you can do with this.

nps expects to your package-scripts.js file to module.exports an object with the following properties:

scripts

This can be an object or a function that returns an object. See the annotated example below for what this object can look like (and different ways to run them):

module.exports = {
  scripts: {
    default: 'echo "This runs on `nps`"', // nps
    // you can assign a script property to a string
    simple: 'echo "this is easy"', // nps simple
    // you can specify whether some scripts should be excluded from the help list
    hidden: {
      script: "debugging script",
      hiddenFromHelp: true
    },
    test: {
      default: {
        script: "jest", // nps test
        description: "Run tests with jest"
        // your scripts will be run with node_modules/.bin in the PATH, so you can use locally installed packages.
        // this is done in a cross-platform way, so your scripts will work on Mac and Windows :)
        // NOTE: if you need to set environment variables, I recommend you check out the cross-env package, which works
        // great with nps
      },
      otherStuff: {
        // this one can be executed two different ways:
        // 1. nps test.otherStuff
        // 2. nps test.other-stuff
        script: 'echo "testing other things"',
        description: "this is a handy description"
      }
    },
    // this one can be executed a few different ways:
    // 1. nps k
    // 2. nps kebab-case
    // 3. nps kebabCase
    "kebab-case": 'echo "kebab-case"',
    series: "nps simple,test,kebabCase" // runs these other scripts in series
  }
};
nps k # runs nps kebab-case

options

This object is used to configure nps with the following options:

silent

Setting this to true will prevent nps from outputting anything for your script (normally you'll get simple output indicating the command that's being executed). This effectively sets the logLevel to disable.

logLevel

This sets the logLevel of nps.

ENV variables

LOG_LEVEL

By setting LOG_LEVEL environment variable you can control the log level for nps

Log level

Log levels available:

  • error - errors only
  • warn - errors and warnings only
  • info - info, errors, and warnings (default)

Badge

Congratulations your repo is nps-friendly. Time to flaunt it! Add the nps-friendly badge to your README using the following markdown:

[![nps friendly](https://img.shields.io/badge/nps-friendly-blue.svg?style=flat-square)](https://github.com/sezna/nps)

Your badge will look like this:

nps friendly

It may also make sense to change your README.md or CONTRIBUTING.md to include or link to the nps project so that your new contributors may learn more about installing and using nps.

FAQ

How do I do ___ ?

Have you looked at the examples in other/EXAMPLES.md?

Why npm start?

Just to be clear: You do not have to use the start script. You can use whatever you like. But I recommend using the start. npm scripts are generally run with npm run <script-name>. There are some exceptions to this. For example:

  1. npm run test === npm test === npm t
  2. npm run start === npm start

So, while you could use a script called script and run npm run script build, I just think it reads more clearly to just use the start script and run npm start build. It's also nice that it's fewer things to type. You could also use the test script and then type even less: npm t build, but thats just... odd.

Note, often servers are configured to run npm start by default to start the server. To allow for this case, you can provide a default script at the root of your scripts which will be run when npm start is run without any arguments. Effectively this will allow you to have a script run when npm start is executed.

Resources / Tutorials

Inspiration

This was inspired by a tweet by @sindresorhus.

Thanks

Big thank you to @tmpvar for giving up the name nps! The original nps is now called npmsearch-cli.

Related Packages

  • nps-utils - a collection of utilities to make cross-platform scripts and many other patterns (like running concurrent/parallel scripts)
  • nps-i - interactive mode for nps

Other Solutions

  • scripty has a solution for this problem as well. The reason I didn't go with that though is you still need a line for every script (one of the pains I'm trying to solve) and a each script requires its own file (one of the benefits of npm scripts I wanted to keep).
  • nabs is a compiler that turns a nicely structured YAML file into script entries in your package.json

FAQ

What happened to p-s?

This project is p-s! It was just renamed during a major version bump. There were a few breaking changes for this to happen and those are documented on the releases page.

Contributors

Thanks goes to these people (emoji key):


Kent C. Dodds

๐Ÿ’ป ๐Ÿ“– ๐Ÿš‡ ๐Ÿ’ก ๐Ÿ“น ๐Ÿ‘€

David Wells

๐Ÿ’ป

Abhishek Shende

๐Ÿ’ป โš ๏ธ

Rowan Oulton

๐Ÿ’ป ๐Ÿ“– โš ๏ธ

Gilad Goldberg

๐Ÿ’ป

Tim McGee

๐Ÿ’ป ๐Ÿ“–

Nik Butenko

๐Ÿ’ก ๐Ÿ’ป

Tommy

๐Ÿ› ๐Ÿ’ป โš ๏ธ ๐Ÿ‘€

Jayson Harshbarger

๐Ÿ’ก ๐Ÿ‘€

JD Isaacks

๐Ÿ’ป โš ๏ธ

Christopher Hiller

๐Ÿ‘€ ๐Ÿ› ๐Ÿ’ป ๐Ÿ“– โš ๏ธ

Robin Malfait

๐Ÿ’ก

Eric McCormick

๐Ÿ‘€ ๐Ÿ“–

Sam Verschueren

๐Ÿ‘€

Sorin Muntean

๐Ÿ’ป โš ๏ธ ๐Ÿ“–

Keith Gunn

๐Ÿ› ๐Ÿ’ป โš ๏ธ

Joe Martella

๐Ÿ› ๐Ÿ’ป โš ๏ธ

Martin Segado

๐Ÿ“–

Bram Borggreve

๐Ÿ› ๐Ÿ’ป

Elijah Manor

๐Ÿ“น

Ragu Ramaswamy

๐Ÿ’ป โš ๏ธ ๐Ÿ›

Erik Fox

๐Ÿ› ๐Ÿ’ป ๐Ÿ“– โš ๏ธ

Aditya Pratap Singh

๐Ÿ‘€

bumbleblym

๐Ÿ’ป ๐Ÿ“–

Islam Attrash

๐Ÿ’ป

JasonSooter

๐Ÿ“–

Nate Cavanaugh

๐Ÿ’ป

Wissam Abirached

๐Ÿ’ป โš ๏ธ

Paweล‚ Mikoล‚ajczyk

๐Ÿ’ป โš ๏ธ

Kyle Welch

๐Ÿ’ป โš ๏ธ

Lufty Wiranda

๐Ÿ’ป

Bhargav Ponnapalli

๐Ÿ’ป

falieson

๐Ÿ“– ๐Ÿ”ง

Suhas Karanth

๐Ÿ› ๐Ÿ’ป

Eric Skram

๐Ÿ“–

Kether Saturnius

๐Ÿ’ป ๐Ÿ“–

Sviatoslav

๐Ÿ› ๐Ÿ’ป

Wei Wang

๐Ÿ’ป

Sami Jaber

๐Ÿ› ๐Ÿ’ป

Florian Lรถchle

๐Ÿ’ป

Kevin J

๐Ÿ’ป

Ben Teichman

๐Ÿ’ป ๐Ÿ“–

Alex Hansen

๐Ÿ’ป ๐Ÿš‡ ๐Ÿ‘€

Casey Primozic

๐Ÿš‡ ๐Ÿ‘€

Vivek Fitkariwala

๐Ÿ’ป

Danny Coates

๐Ÿ’ป

This project follows the all-contributors specification. Contributions of any kind welcome!

LICENSE

MIT

nps's People

Contributors

ameobea avatar amilajack avatar beeman avatar bfred-it avatar boneskull avatar bumbleblym avatar danecando avatar dannycoates avatar davidwells avatar edm00se avatar effervescentia avatar erikfox avatar falieson avatar florianloechle avatar giladgo avatar gunnx avatar hypercubed avatar imbhargav5 avatar jasonsooter avatar jisaacks avatar k3th3r avatar luftywiranda13 avatar martellaj avatar miklet avatar nkbt avatar robinmalfait avatar sezna avatar sudo-suhas avatar sxn avatar vpr99 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nps's Issues

Feat: Run multiple scripts in series

As indicated on the ROADMAP.md under "Want to do":

Add the ability to specify multiple scripts that run in series (right now the solution is to just &&)

Let's implement that. I'm going to work on it right now.

Publish @next as @latest

I need help! Could people please try upgrading to p-s@next and tell us about your experience? I'll come back to this issue when I have a second to add a migration guide (I'll actually put it in docs somewhere).

Thanks!

npm install p-s@next

`nps init` should import scripts that work exactly as they do in npm run.

npm init script should import scripts from package.json so that they work the same under p-s.

i.e. if I run nps init on the following package.json

scripts:{
  "prething": "echo pre-thing",
   "thing":"echo thing"
}

then I should get the following output (in yaml)

scripts:
    prething: 
        default: echo pre-thing
    thing: 
         default: nps prething && echo thing

passing args isn't working as advertised

using 2.4.3 in Node.js 6.4.0:

> $ npm start xmas

> [email protected] start /tmp
> p-s "xmas"

p-s executing: npm xmas

                     โ˜…
                    ๏ผ๏ผผ
                   ๏ผ โ‚๏ผผ
                  ๏ผ i  ๏ผผ
                 ๏ผโธ›  &  ๏ผผ
                ๏ผ โธ›   โ‚โ‚ ๏ผผ
               ๏ผโธฎ  โธ›โธฎ   ๏ฝก ๏ผผ
              ๏ผ ๏ฝก โธ›  &โธฎ    ๏ผผ
             ๏ผ i   iโ‚  ๏ฝก i  ๏ผผ
            ๏ผi  โธฎi   โธฎ   ๏ฝกi๏ฝก ๏ผผ
           ๏ผ     ๏ฝกโ‚โ‚ @      @โธ›๏ผผ
          ๏ผ    โธ›  ๏ฝก@   & โธ›โธฎโธฎโธ›iโ‚๏ผผ
         ๏ผ    & iโธ› @ i โธฎ      โธ›โธฎ๏ผผ
        ๏ผโ‚  ii  โธฎโธฎ     &  @  โธ›  i๏ผผ
       ๏ผ& @    โ‚ โ‚  iโ‚โ‚  โธฎ  โ‚โธ› @  ๏ผผ
      ๏ผ โธ›โ‚& โธ›๏ฝก๏ฝก   &   โ‚  @     ๏ฝกโธฎ๏ฝก ๏ผผ
     ๏ผ    โธฎ    โ‚  โธฎ  iโ‚      @@๏ฝกโธฎ๏ฝก  ๏ผผ
    ๏ผ@    โธ›i โธฎโธ› @   โ‚   &     โธ›@  ๏ฝก  ๏ผผ
   ๏ผ โธฎ@   ๏ฝก ii         iโธฎ   โธฎ   โธ›     ๏ผผ
  ๏ผ       โธ›    i  &โ‚i  โ‚  @ โธ›โธ›โธฎ  โธฎโ‚    ๏ผผ
 ๏ผ  โ‚ โธ› i  @๏ฝก  โธ› โธ›  iโ‚i  โธฎโธฎ&    โธฎโธฎโธ›   @ ๏ผผ
 ^^^^^^^^^^^^^^^^^^^|  |^^^^^^^^^^^^^^^^^^^
                    |  |

npm loves you Happy Xmas, Noders!

Now, passing an argument:

> $ npm start xmas --grinch

> [email protected] start /tmp
> p-s "xmas"

p-s executing: npm xmas

                     โ˜…
                    ๏ผ๏ผผ
                   ๏ผi ๏ผผ
                  ๏ผ ๏ฝก ๏ฝก๏ผผ
                 ๏ผ @ &โ‚@๏ผผ
                ๏ผ     i  ๏ผผ
               ๏ผ&   โธฎโธฎโธ› @ ๏ผผ
              ๏ผ @@๏ฝก   โ‚    ๏ผผ
             ๏ผ    &  โธฎ   โ‚โธฎ ๏ผผ
            ๏ผ๏ฝกi       โ‚  ๏ฝก  &๏ผผ
           ๏ผโธ›โธ›   @   โ‚   โธฎ @  ๏ผผ
          ๏ผ      ๏ฝก โ‚    @&โธ›  ๏ฝก๏ฝก๏ผผ
         ๏ผ   @ โธ› โธ›@   โธ› @  โธ› โ‚  ๏ผผ
        ๏ผโ‚โ‚   ๏ฝก       @   โ‚   i  ๏ผผ
       ๏ผ  ๏ฝก ๏ฝก i   โธ›   &โธฎ โธฎ   โ‚โธ›โ‚ ๏ฝก๏ผผ
      ๏ผ โธฎ    @   @๏ฝก     โธ›    ๏ฝกโ‚    ๏ผผ
     ๏ผ   ๏ฝกโธ›@  & &  @ โธ›   & โธ› ๏ฝก โธฎ    ๏ผผ
    ๏ผโธ›    โ‚     @@ ๏ฝก  ๏ฝก ๏ฝก@     @ @โธฎ &๏ผผ
   ๏ผโธ›โธฎ  ๏ฝก  โธ›   โธฎ โธ›  โธฎ @@  @๏ฝก  โธฎ    @ @๏ผผ
  ๏ผ@      @โธฎโธฎ   @     โ‚    iโธฎ ๏ฝก โธ› @    ๏ผผ
 ๏ผ  โธ›& @  โ‚   โธฎ   @   โ‚  ๏ฝก โธ›   @โ‚iโธฎ&  @ ๏ผผ
 ^^^^^^^^^^^^^^^^^^^|  |^^^^^^^^^^^^^^^^^^^
                    |  |

npm loves you Happy Xmas, Noders!

To get it to work, I have to do this:

> $ npm start xmas -- --grinch

> [email protected] start /tmp
> p-s "xmas" "--grinch"

p-s executing: npm xmas --grinch

                     โ˜…
                    ๏ผ๏ผผ
                   ๏ผ  ๏ผผ
                  ๏ผ    ๏ผผ
                 ๏ผโธฎ     ๏ผผ
                ๏ผ โธ›     ๏ฝก๏ผผ
               ๏ผ๏ฝก  โ‚ โธ› โ‚  ๏ผผ
              ๏ผ   i   @  โ‚ ๏ผผ
             ๏ผ   @&  i   ๏ฝก โธฎ๏ผผ
            ๏ผ   โธ›   ๏ฝก โธฎ    ๏ฝกi๏ผผ
           ๏ผ  โธฎ ๏ฝก      โธฎ โธฎ  โธฎ ๏ผผ
          ๏ผ @   &โธฎ  โธ›โ‚ โธ›      โธฎ๏ผผ
         ๏ผ@i      โ‚@&โธฎ  i &@   โธ›๏ผผ
        ๏ผโธฎ@@iโธฎโ‚   โธ› ๏ฝก โ‚  iโธฎ    โธฎ ๏ผผ
       ๏ผ๏ฝก   i     @ i โธ›      โ‚ โ‚  ๏ผผ
      ๏ผ  โธ› ๏ฝก๏ฝกโ‚  @๏ฝก   @ i    i     &๏ผผ
     ๏ผ     โธฎ&  โธ›@  โธฎiโธฎ &  โ‚@  โธ›     ๏ผผ
    ๏ผ @๏ฝก    โ‚  โธฎ    โธฎ @           โธฎ  ๏ผผ
   ๏ผโ‚โ‚     โธฎ โธฎ๏ฝก โธ› &         @ โธ›โธฎ โธฎโ‚   ๏ผผ
  ๏ผ @     ๏ฝก     โ‚โธ›        i&     โ‚ โ‚   ๏ผผ
 ๏ผ    @      โธฎ i  โ‚&  iโธ›โธ›    โธฎ@   โธ› โ‚โธ›@๏ฝก๏ผผ
 ^^^^^^^^^^^^^^^^^^^|  |^^^^^^^^^^^^^^^^^^^
                    |  |

npm loves you Happy Xmas, Noders!

Allow initializing to a YAML file

Currently, users who want to start using p-s in an existing project can hit the ground running by using nps init. This will generate a package-scripts.js file from their package.json file and update the latter to utilize the nps binary.

Since we now have YAML config support (#64), it would be great if nps init would allow generating a package-scripts.yml file as well.

What about nps init --type=yaml?
Feel free to pick it up, otherwise I'll probably be able to do this some time this weekend. ๐Ÿ˜„

Idea: Prefixes for scripts

This is bad:

scripts:
  db:
    default: babel-node scripts/db.js help
    help: babel-node scripts/db.js help
    start: babel-node scripts/db.js start
    restore: babel-node scripts/db.js restore
    dump: babel-node scripts/db.js dump
    reset: babel-node scripts/db.js reset

๐Ÿ‘Ž Serious need of DRYing
๐Ÿ‘ 1:1 for script methods = easy reading

Current solution barely better:

scripts:
  db:
    help: nps db help
    start: nps db start
    restore: nps db restore
    dump: nps db dump
    reset: nps db reset
    default: 
      script: babel-node scripts/db.js
      hiddenFromHelp: true

๐Ÿ‘Ž Looks incredibly messy the more it occurs
๐Ÿ‘Ž Uses up script.default, which I often use to auto-print help

This would be great:

scripts:
  db:
    _prefix: babel-node scripts/db.js
    default: help
    help: help
    start: start
    restore: restore
    dump: dump
    reset: reset

๐Ÿ‘ Very DRY!
๐Ÿ‘ Keeps default free!
๐Ÿ‘ 1:1 relationships!

Would be cool too:

scripts:
  serve:
    _postfix: --watch
    ...

Just wanted to have a feasibility discussion first, willing to implement myself!

Error thrown if "scripts" property missing from package.json

  • p-s version: 3.0.3
  • node version: 7.4.0
  • npm version: 4.0.5

Scripts file (or at least the relevant bits):

/p-s/dist/bin-utils/initialize/index.js

The command executed:

./node_modules/.bin/p-s- init

The output:

./node_modules/p-s/dist/bin-utils/initialize/index.js:31
   test: scripts.test ? 'nps test' : undefined
                 ^

TypeError: Cannot read property 'test' of undefined

Problem description:
Init fails to work if there is no "scripts" object in package.json

Suggested solution:
Inform user of problem or create "scripts" property automatically.

Not all scripts are displayed in help

  • p-s version: 0.9.0
  • node version: 6.2.0

Looks like not all scripts are displayed in the help section. I'm almost sure it's because the process ends before displaying everything.

It seems to be related to Node 6 though because the issue doesn't exist in Node 5.

p-s autocomplete in zsh

I'm using prezto and it has an autocomplete for npm run commands. It would be great to have the same for p-s or npm start when p-s is used.

Does someone has some experiences writing something like that? :)

Idea for clarity for folks unfamiliar with p-s

Kent love this idea!

One issue that I have seen by all of the 'better npm scripts' setups is new folks not grokking what exactly the abstraction is doing or what it is running.

A.k.a the "p-s... what in the..." reaction from people unaware of this package

Has a proposal to potentially help folks looking at the package.json

before:

{
  "scripts": {
    "start": "p-s"
  }
}

after:

{
  "scripts": {
    "start": "p-s && echo 'Look in package-scripts.js for script information'"
  }
}

Just my 2 cents!

Feat: Improve help output

  1. Output the default script if it's present (put it at the top and highlight it)
  2. At the top, we should also list docs for the other commands (like help (if they don't have a help script), init, and completion)

Thoughts? ๐Ÿ’ญ

add eject command

Lots of people want to be able to try out p-s for a while to evaluate it. Just like we have an init command that'll allow you to initialize the package-scripts.js and update your npm scripts in package.json, I think we should have an eject command that will do the reverse.

Filter the help list?

Would it be a good idea to have a way to filter the help list, like listing only the scripts which contains a description, or adding a flag "private" and filter them out?

I don't know if it's the right way to do it, but I have a few tasks without description because I treat them as "private", so the developer is not supposed to directly run them.

Also support function

currently

module.exports = {
  scripts: {
    build: 'babel-node scripts/build'
  }
}

expect to support as well:

module.exports = {
  scripts: {
    build(){
      return  'babel-node scripts/build'
    }
  }
}

convert 'npm run' scripts to 'nps' in init

Problem description:

currently if you run nps init on a script, it just copies over your scripts verbatim. it would be nice if it any scripts I have which execute other scripts would be converted to nps (since they also moved).

Suggested solution:

scripts:{
  "blah": "npm run blah:ext && echo hello",
  "blah:ext": "echo hello2"
}

would get init'd as:

scripts:
  blah:
    default: nps blah.ext && echo hello
    ext: echo hello2

Running the coverage in p-s reports package-scripts.js

When I run my test command in p-s instead of npm scripts, the file package-scripts.js is displayed in my report, even if it's not part of the pattern glob of mocha.

  • p-s version: 0.9.0
  • node version: 6.2.0
  • npm version: 3.8.9

The command executed:

p-s executing: nyc --reporter=text --reporter=lcov p-s test.suite
p-s executing: cross-env NODE_PATH=./src mocha "./test/**/*.spec.js" --compilers js:babel-register -r ./test/helper

The issue seems to be located when executing the second command. Because during the first command, if I changed p-s test.suite for npm run test.suite (my old command), the output is different and the file disappears from the coverage.

Preload module option

How about a command line option similar to avas or tapes --require so you can have Babel, Coffescript or Typescript config files.

package.json

"scripts": {
  "start": "package-scripts --require babel-register"
}

package-scripts.js

export default {
  scripts: {
    build: 'webpack'
  }
}

command line

npm start build

Add init script

It'd be awesome to have an init script that read the package.json scripts and transferred them to a package-scripts.js and update the scripts in package.json to use the recommended start script.

Indent child task descriptions when running help command

  • p-s version: 3.0.1
  • node version: 6.9.1
  • npm version: 3.10.8

Scripts file (or at least the relevant bits):

https://github.com/kentcdodds/p-s/blob/master/src/bin-utils/index.js

The command executed:

./node_modules/p-s/dist/bin/nps.js help

The output:

dev - DEVELOPMENT: Build CSS, build and run server, build, serve and watch client - npm start dev.build-sass,dev.runServerRunClientAndWatchSass
dev.buildServerAndStart - npm start dev.build,start

Problem description:
Tasks that are namespaced do not render out indented.

Suggested solution:
Output any nested tasks with spaces to indicate they are children of parent task

syntax errors in package-scripts.js should not be swallowed.

  • p-s version: 1.0.1
  • node version: 6.2.1
  • npm version: 3.9.3

Problem description:

If there is a syntax error in the package-scripts.js (in my case for example a missing comma) then it will fail to load. However your error message swallows the syntax error and just says that it cannot find the package-scripts.js file which was confusing for me.

Suggested solution:

Basically when capturing the error here

Just add a check for syntax error:

if (e instanceof SyntaxError) {
   throw e;
}

I'll gladly make the change and submit a PR.

Support scripts with prefix names

Given I have these scripts:

module.exports = {
  scripts: {
    thing: 'echo "thing"',
    things: 'echo "things"',
  },
}

It is impossible for me to run the things script because the prefix resolver will resolve to the things script. This may be something that @rowanoulton needs to fix in prefix-matches. This would be acceptable behavior:

  1. npm start thing runs thing
  2. npm start t runs thing
  3. npm start things runs things

This would be a breaking change.

Default root script

Would you be willing to allow a default root script in order to be able to run the script with just npm start, or p-s?

module.exports = {
    scripts: {
        default: {
            script: 'echo default script'
        }
    }
}

p-s v2.4.0 fails to install

looks like dist/ didn't get published, if I had to wager a guess:

> $ npm install p-s@latest                                                                                   โฌก 6.4.0
npm WARN enoent ENOENT: no such file or directory, open '/private/tmp/package.json'
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.
npm ERR! Darwin 15.6.0
npm ERR! argv "/Users/boneskull/.nvm/versions/node/v6.4.0/bin/node" "/Users/boneskull/.nvm/versions/node/v6.4.0/bin/npm" "install" "p-s@latest"
npm ERR! node v6.4.0
npm ERR! npm  v3.10.3
npm ERR! path /private/tmp/node_modules/p-s/dist/bin/p-s.js
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod

npm ERR! enoent ENOENT: no such file or directory, chmod '/private/tmp/node_modules/p-s/dist/bin/p-s.js'
npm ERR! enoent ENOENT: no such file or directory, chmod '/private/tmp/node_modules/p-s/dist/bin/p-s.js'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! Please include the following file with any support request:
npm ERR!     /private/tmp/npm-debug.log

`init` should not move certain scripts

When you run init, currently it moves all the scripts to package-scripts.js. It would be great if we kept a list of scripts that shouldn't be moved (because they have semantic meaning in the package.json scripts).

For example, all the npm lifecycle scripts:

  • prepublish
  • publish
  • postpublish
  • preinstall
  • install
  • postinstall
  • preuninstall
  • uninstall
  • postuninstall
  • preversion
  • version
  • postversion
  • pretest
  • posttest
  • prestop
  • stop
  • poststop
  • prestart
  • poststart
  • prerestart
  • restart
  • postrestart

We already have special handling for these scripts:

  • test
  • start

In addition, husky is a personal favorite package of mine and any of these scripts should be left untouched as well:

  • applypatchmsg
  • preapplypatch
  • postapplypatch
  • precommit
  • preparecommitmsg
  • commitmsg
  • postcommit
  • prerebase
  • postcheckout
  • postmerge
  • prepush
  • prereceive
  • update
  • postreceive
  • postupdate
  • pushtocheckout
  • preautogc
  • postrewrite

Another thought is if we see npm run in any of the scripts, perhaps we could change that to simply nps (unless the script referenced is in this list of scripts to keep around). This could be a little complicated, but I feel like it could be isolated pretty well and improve community adoption. Anyone wanna try their hand at this? Relevant code is here.

Support YAML config

It'd be nice if p-s supported YAML configuration alongside the JS one

CommonJS files are slightly easier to read/write than JSON, but JS objects are still full '{"\,}

module.exports = {
  scripts: {
    default: 'node index.js',
    lint: 'eslint .',
    test: {
      // learn more about Jest here: https://kcd.im/egghead-jest
      default: 'jest',
      watch: {
        script: 'jest --watch',
        description: 'run in the amazingly intelligent Jest watch mode'
      }
    },
    build: {
      default: 'webpack',
      prod: 'webpack -p',
    },
    validate: 'nps --parallel lint,test,build',
  },
}

in YAML it would just be

default: node index.js
lint: eslint .
test:
  # learn more about Jest here: https://kcd.im/egghead-jest
  default: jest
  watch:
    script: jest --watch
    description: run in the amazingly intelligent Jest watch mode
build:
  default: webpack
  prod: webpack -p
validate: nps --parallel lint,test,build

Plus, even the syntax highlighter is nicer to YAML :P

YAML isn't dynamic like JS, but probably most people don't use that (and if they do, they can just use the standard CJS syntax)

Changing Unable to Find Config Log Level

Scripts file (or at least the relevant bits):

https://github.com/kentcdodds/p-s/blob/master/bin/p-s.js#L60

The output:

Unable to find config at /Users/konstantinpschera/Development/Projects/ps/package-scripts.js https://github.com/kentcdodds/p-s/blob/v0.0.0-semantically-released/other/ERRORS_AND_WARNINGS.md#unable-to-find-config
Unable to find config at /Users/konstantinpschera/Development/Projects/ps/package-scripts.js https://github.com/kentcdodds/p-s/blob/v0.0.0-semantically-released/other/ERRORS_AND_WARNINGS.md#unable-to-find-config
Scripts must resolve to strings. There is no script that can be resolved from "echo" https://github.com/kentcdodds/p-s/blob/v0.0.0-semantically-released/other/ERRORS_AND_WARNINGS.md#missing-script

Problem description:
Every time the config couldn't be loaded the scripts are always not working.

Suggested solution:
Rise the log level to error so p-s gets terminated earlier.

Proper handling and forwarding of `--flags`

Right now you can do:

nps foo --bar

And p-s will run the script called foo with the flag called --bar

However if you run:

nps foo --silent --bar

then p-s will run the script called foo with the flag called --bar but without the flag called --silent. This is because of this.

Normally it's not a huge deal. I think that's confusing.

Here are a few possible solutions (all of them are breaking):

  1. Only accept p-s flags before the scripts (so you'd have to do nps --silent foo --bar)
  2. Require -- before the scripts and flags (nps --silent -- foo --bar)
  3. Forward all flags whether they're p-s related or not (nps foo --silent --bar and forwards --silent and --bar both)

I can't think of a way to change this behavior without breaking things.

My favorite solution is the first. Mostly because it's least noisy and seems to make the most sense.

I'm working on #70 right now and will make this a part of that PR. I want feedback on this really quick. If anyone has any ideas let me know. If you'd like to vote for one or the other use github reactions to vote: ๐Ÿ‘ for 1, ๐Ÿ˜„ for 2, ๐ŸŽ‰ for 3, and ๐Ÿ˜• for "I don't know/care"

Nested taks are not displayed properly in the help

Inside the help section, the task list may be wrong.

If I have a few nested tasks, like:

build: {
  x: {
    y: {
      description: "build X-Y",
      script: "do sth"
    }
  }
}

With this example, it only display x.y - build X-Y - do sth

This project doesn't solve any problems

Compare these two examples:

{
  "scripts": {
    "start": "node index.js",
    "lint": "eslint .",
    "test": "ava",
    "test:watch": "ava -w",
    "build": "webpack",
    "build:prod": "webpack -p",
    "validate": "npm-run-all -p -r lint test build"
  }
}
module.exports = {
  scripts: {
    default: 'node index.js',
    lint: 'eslint .',
    test: {
      default: 'ava',
      watch: {
        script: 'ava -w',
        description: 'run in the amazingly intelligent AVA watch mode'
      }
    },
    build: {
      default: 'webpack',
      prod: 'webpack -p',
    },
    validate: 'p-s --parallel lint,test,build',
  },
}

While p-s is supposed to help, it actually introduces more bloat by adding another file with a lot more lines and the configuration is hardly maintainable.

If you Flow-typed the configuration it would look something like this:

/* @flow */

declare type StringScript = string;
declare type DescribedScript = {
  script: StringScript,
  description?: string,
};
declare type ScriptNest = {
  default: StringScript | DescribedScript,
  [key: string]: StringScript | DescribedScript | ScriptNest,
};
declare type Config = {
  scripts: ScriptNest,
  options?: {
    silence?: boolean,
  },
};

declare export default Config;

You can tell that it will be hard to maintain by the type of ScriptNest. Values of it's properties can be any of the three types which will be absolutely indistinguishable in a large configuration. Configuration formats like this are doomed to become a thousand-piece puzzle.


There is the description functionality, but describing scripts like "test:watch": "ava -w" as "Run AVA in watch mode." is absolutely unnecessary. Most scripts are already self-explanatory or can be made self-explanatory by using long forms of arguments. (Bad: ava -w Good: ava --watch)

The "unmaintainable mess" example in the README.md is a bad example. You can maintain a large scripts without any problems if you follow a few rules:

{
  "scripts": {
    "start": "node server.prod.js",

    "start-dev": "babel-node server.dev.js",

    "clean": "rimraf dist",

    "build": "npm run clean && npm run build:webpack",
    "build:webpack": "webpack --config webpack.config.prod.babel.js",

    "test": "npm run test:eslint && npm run test:flow",
    "test:eslint": "eslint \"src/**/*.js\"",
    "test:flow": "flow; test $? -eq 0 -o $? -eq 2"
  }
}

The result of npm run for those scripts will be:

Lifecycle scripts included in app:
  start
    node server.prod.js
  test
    npm run test:lint && npm run test:flow

available via `npm run-script`:
  start-dev
    babel-node server.dev.js
  clean
    rimraf dist
  build
    npm run clean && npm run build:webpack
  build:webpack
    webpack --config webpack.config.prod.babel.js
  test:flow
    flow; test $? -eq 0 -o $? -eq 2
  test:lint
    eslint "src/**/*.js"

As you can see, all scripts can be easily listed and understood. Since task and step names are colon separated, it is easy to see what is a task and what is a step. With steps, if one of your tasks fail, you can run the failed step solo to debug easily.

If you end up with too much steps, you can hack in a creative script that removes steps from npm run output:

"list": "npm run | sed -e '/^  [^ ]*:.*$/,/^/d'"

Descriptions were also suggested for npm's core and decided unworthy of complexity for the same reasons: npm/npm#9952


Another problem is the way "prefixing" is advertised. It is surprisingly used in the actual configuration in the intro video. There is seriously no way you can properly maintain a line like p-s --parallel b.m,b.u,b.u.m in your configuration.

You also can't safely use it in a shell. npm start b.u.m can refer to build.umd.min in one commit and break.user.machine in another. That's why these are never dynamically generated in CLIs and always hardcoded.

Set up all npm environment variables

If you run npm run env it'll show you all the environment variables that npm creates for you. It'd be handy to include those in the environment for the script that's run so there are fewer surprises when migrating from npm scripts to p-s, also, it can be handy in general :)

Hidden scripts error when trying to run

  • p-s version: 3.0.1
  • node version: 6.9.1
  • npm version: 3.10.8

Scripts file (or at least the relevant bits):

https://github.com/kentcdodds/p-s/blob/master/src/resolve-script-object-to-string.js

Config extract:

dev: {
    build: {
      description: '',
      script: `NODE_ENV=development webpack --config ${webpackServerConfig}`,
      hiddenFromHelp: true
    },
...

The command executed:

nps dev.build

The output:

....
Scripts must resolve to strings. There is no script that can be resolved from "dev.build" https://github.com/kentcdodds/p-s/blob/v3.0.1/other/ERRORS_AND_WARNINGS.md#missing-script
....

Problem description:
Assume that the expected behaviour of flag hiddenFromHelp is to only remove it from the help list and not stop you running.

Suggested solution:
Not sure I fully understand the code but looks like resolvePlainObjectToScript is returning undefined if the flag is set, though looks like this function is used by help and run tasks.

/bin-utils loadJSConfig() doesn't support package-scripts.js exporting a function

src/get-scripts-from-config.js allows package-scripts.js to export a function:

import {isPlainObject, isFunction} from 'lodash'

export default getScriptsFromConfig

function getScriptsFromConfig(scripts, input) {
  if (isPlainObject(scripts)) {
    return scripts
  } else if (isFunction(scripts)) {
    return scripts(input)
  }
  return {}
}

but src/bin-utils/index.js loadJSConfig() does not:

const loadJSConfig = getAttemptModuleRequireFn(function onFail(configPath, requirePath) {
  log.error({
    message: colors.red(`Unable to find JS config at "${configPath}". Attempted to require as "${requirePath}"`),
    ref: 'unable-to-find-config',
  })
  return undefined
})

...

function loadConfig(configPath) {
  if (configPath.endsWith('.yml')) {
    return loadYAMLConfig(configPath)
  }

  return loadJSConfig(configPath)
}

So when attempting to run a default script via command line, you get the generic help output with a "no scripts" warning:

// package-scripts.js
exports.scripts = function (input) { ... }
$ nps

  Usage: nps [options]

  Options:

    -h, --help                                  output usage information
    -V, --version                               output the version number
    -s, --silent                                Silent nps output
    -p, --parallel <script-name1,script-name2>  Scripts to run in parallel (comma seprated)
    -c, --config <filepath>                     Config file to use (defaults to nearest package-scripts.yml or package-scripts.js)
    -l, --log-level <level>                     The log level to use (error, warn, info [default])
    -r, --require <module>                      Module to preload

There are no scripts available

--help tosses exception

reproduce

$ npm install [email protected]
# snip
$ node_modules/.bin/package-scripts --help


  Usage: package-scripts [options]

  Options:

    -h, --help                                  output usage information
    -V, --version                               output the version number
    -s, --silent                                Silent p-s output
    -p, --parallel <script-name1,script-name2>  Scripts to run in parallel (comma seprated)
    -c, --config <filepath>                     Config file to use (defaults to nearest package-scripts.js)
    -l, --log-level <level>                     The log level to use (error, warn, info [default])
    -r, --require <module>                      Module to preload

/Volumes/alien/mochajs/mocha-core/node_modules/p-s/dist/bin-utils/index.js:117
  return moduleName[0] === '.' ? (0, _path.resolve)(process.cwd(), moduleName) : moduleName;
                   ^

TypeError: Cannot read property '0' of null
    at getModuleRequirePath (/Volumes/alien/mochajs/mocha-core/node_modules/p-s/dist/bin-utils/index.js:117:20)
    at attemptModuleRequire (/Volumes/alien/mochajs/mocha-core/node_modules/p-s/dist/bin-utils/index.js:122:23)
    at getPSConfig (/Volumes/alien/mochajs/mocha-core/node_modules/p-s/dist/bin/p-s.js:72:41)
    at Command.onHelp (/Volumes/alien/mochajs/mocha-core/node_modules/p-s/dist/bin/p-s.js:93:32)
    at emitNone (events.js:86:13)
    at Command.emit (events.js:185:7)
    at Command.outputHelp (/Volumes/alien/mochajs/mocha-core/node_modules/commander/index.js:1024:8)
    at outputHelpIfNecessary (/Volumes/alien/mochajs/mocha-core/node_modules/commander/index.js:1078:11)
    at Command.parseArgs (/Volumes/alien/mochajs/mocha-core/node_modules/commander/index.js:620:5)
    at Command.parse (/Volumes/alien/mochajs/mocha-core/node_modules/commander/index.js:458:21)

Parallel taks are forwarded to the end command

ERROR in multi main
Module not found: Error: Cannot resolve module 'build.test,build.staging,build.edge'

  • p-s version: 1.0.2
  • node version: 6.6.1

The command executed:

npm start -p build.x,build.y

The output:

ERROR in multi main
Module not found: Error: Cannot resolve module 'build.x,build.y'

Problem description:
My build command run webpack to build a bundle file for my project. But when running npm start -p build.x,build.y, it appends the parallel commands to webpack and produce an error:

webpack 'build.x,build.y'

I think the parallel taks shouldn't be forwarded to the end command

help command for specific scripts

It'd be super cool to be able to do:

nps help lint

Which would result in the lint script itself as well as the description being shown in the output.

This would be helpful in situations where you have many scripts.

`npm start validate` fails after initial clone

  • p-s version: latest from master
  • node version: 6.5.0
  • npm version: 3.10.3

The command executed:

npm start validate

The output:

Test Summary
 โ€บ Ran all tests matching "src/".
 โ€บ 64 tests passed (64 total in 9 test suites, run time 6.792s)
 FAIL  cli-test/cli.test.js
  โœ“ without arguments (419ms)
  โœ“ with config with default script (416ms)
  โœ• with a missing config (398ms)
  โœ“ with --silent (335ms)
  โœ“ with --require (1238ms)

  โ— with a missing config

    Received value does not match the stored snapshot 1.

    - Snapshot
    + Received

      Object {
    -   "stderr": "Unable to find JS config at "./something-that-does-not-exist.js". Attempted to require as "<projectRootDir>/cli-test/fixtures/something-that-does-not-exist.js" https://github.com/kentcdodds/p-s/blob/v0.0.0-semantically-released/other/ERRORS_AND_WARNINGS.md#unable-to-find-config
    +   "stderr": "Unable to find JS config at "./something-that-does-not-exist.js". Attempted to require as "<projectRootDir>/cli-test/fixtures/something-that-does-not-exist.js" https://github.com/kentcdodds/p-s/blob/v3.0.2/other/ERRORS_AND_WARNINGS.md#unable-to-find-config
      ",
        "stdout": ""
      }

      at cli-test/cli.test.js:34:36
      at run (node_modules/core-js/modules/es6.promise.js:87:22)
      at node_modules/core-js/modules/es6.promise.js:100:28
      at flush (node_modules/core-js/modules/_microtask.js:18:9)


Snapshot Summary
 โ€บ 1 snapshot test failed in 1 test file. Inspect your code changes or run with `npm start -- -u` to update them.

Test Summary
 โ€บ Ran all tests matching "cli-test/".
 โ€บ snapshot failure, 1 test failed, 4 tests passed (5 total in 1 test suite, 4 snapshots, run time 4.895s)
The script called "test.cli" which runs "jest cli-test/" failed with exit code 1 https://github.com/kentcdodds/p-s/blob/v3.0.2/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code
The script called "build.andValidate" which runs "nps build,test.cli" failed with exit code 1 https://github.com/kentcdodds/p-s/blob/v3.0.2/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code
The script called "validate" which runs "nps -p build.andValidate,test,lint" failed with exit code 1 https://github.com/kentcdodds/p-s/blob/v3.0.2/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code

npm ERR! Darwin 16.0.0
npm ERR! argv "/Users/martellaj/.nvm/versions/node/v6.5.0/bin/node" "/Users/martellaj/.nvm/versions/node/v6.5.0/bin/npm" "start" "validate"
npm ERR! node v6.5.0
npm ERR! npm  v3.10.3
npm ERR! code ELIFECYCLE
npm ERR! [email protected] start: `nps "validate"`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script 'nps "validate"'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the p-s package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     nps "validate"
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs p-s
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls p-s
npm ERR! There is likely additional logging output above.

Problem description:
Interested in digging into the code a bit. Followed instructions in your CONTRIBUTING, but getting failures before I've even opened my IDE.

Possible error in readme (npm run start === nps)

  • p-s version: 3.0.3
  • node version: 6.9.1
  • npm version: 3.10.8

Scripts file (or at least the relevant bits): N/A

The command executed:

$ nps

The output:

-bash: nps: command not found

Problem description:

The README claims that npm run start is equivalent to nps:

npm scripts are generally run with npm run <script-name>. There are some exceptions to
this. For example:

  1. npm run test === npm test === npm t
  2. npm run start === nps

So, while you could use a script called script and run npm run script build, I just think it reads more clearly to
just use the start script and run nps build.

However, this does not appear to be true (at least in my version of npm)... the only built-in start alias I'm aware of is npm run start === npm start.

Suggested solution:

I'll issue a PR right after submitting this =)

Move to yargs

Commander is cool and all, but there's some hacky things we have to do to get our CLI to do what we want. It'd be sweet to use yargs which is much more flexible.

All changes should happen in here. Should hopefully be able to just use it similar to how I've used it in split-guide here ๐Ÿ‘

Callback called more then once in Appveyor builds

  • p-s version: 2.0.0, 2.0.1, 2.0.2
  • node version: 5.2.0
  • npm version: 3.3.12

Scripts file (or at least the relevant bits):

no js

The command executed:

argv "C:\\Program Files (x86)\\nodejs\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start" "--" "--parallel" "build.lib,build.dist,build.min"

The output:

npm ERR! node v5.2.0
npm ERR! npm  v3.3.12
npm ERR! Callback called more than once.
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>
npm ERR! Please include the following file with any support request:
npm ERR!     C:\projects\react-text-filter\npm-debug.log
npm ERR! Windows_NT 6.3.9600
npm ERR! argv "C:\\Program Files (x86)\\nodejs\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start" "prepublish"
npm ERR! node v5.2.0
npm ERR! npm  v3.3.12
npm ERR! code ELIFECYCLE
npm ERR! [email protected] start: `p-s --config react-component-template/package-scripts -s "prepublish"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] start script 'p-s --config react-component-template/package-scripts -s "prepublish"'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-text-filter package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     p-s --config react-component-template/package-scripts -s "prepublish"
npm ERR! You can get their info via:
npm ERR!     npm owner ls react-text-filter
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\projects\react-text-filter\npm-debug.log
Command exited with code 1

Problem description:
^ error

Suggested solution:
Have not debugged that yet
See https://ci.appveyor.com/project/nkbt/react-text-filter/build/14

Windows command line interprets package-scripts as launching package-scripts.js

Problem description:

Due to a little-known feature, at least to me, on windows, executing package-scripts from the cmd prompt or from npm scripts (even in Cygwin) causes the package-scripts.js file to be opened in the default application for .js files. see here.

Suggested solution:

  • Update documentation to only suggest using p-s. e.g. This solution.
  • Document this issue.

Possible additional solutions:

  • Remove the package-scripts bin.
  • Rename package-scripts.js.

Idea: Add pre/post commands

I miss this from npm scripts =)

What is it was implemented like so?

// if pre
if(cmd['pre' + cmdName ]) {
 // if matching pre command exists run it
 cmd['pre' + cmdName ]()
} 

// do normal command
cmd[cmdName ]()

// if post
if(cmd['post' + cmdName ]) {
 // if matching post command exists run it
 cmd['post' + cmdName ]()
} 

nps init should ask if you want to override an existing package-scripts.js

First of all thanks for creating this great utility. It makes my work a lot easier :)

  • p-s version: 3.0.3
  • node version: v7.2.0
  • npm version: 3.10.10

Scripts file (or at least the relevant bits):

# Any customized script

The command executed:

$ nps init

The output:

Your scripts have been saved at /private/tmp/p-s-is-awesome/package-scripts.js
Check out your scripts in there. Go ahead and update them and add descriptions to the ones that need it
Your package.json scripts have also been updated. Run `npm start help` for help
You may also want to install the package globally and installing autocomplete script. You can do so by running
  npm install --global p-s
  nps completion <optionally-your-bash-profile-file>
The bash profile file defaults to ~/.bash_profile for bash and ~/.zshrc for zsh

Problem description:

When there is an existing package-scripts.js in the project the command nps init will override it with the defaults.

I'm not sure if this is by design but if so I think it makes sense to have a confirmation that asks the user for a confirmation to override it.

Suggested solution:

I think there are generally two solutions to consider:

  • Ask for confirmation to override the existing file.
  • Skip creating the file when it exists, and inform the user to remove the existing file.

Don't include `default` as one of the prefixable scripts

Given these scripts:

module.exports = {
  scripts: {
    thing: {
      default: 'echo "default"',
      dee: 'echo "dee"', 
    },
  },
}

If I run npm start thing it will run thing.default as expected/documented. Same if I run npm start t which is great. But if I want to run the thing.dee script, the best I can get with the prefix resolver is npm start t.dee because running npm start t.de will run the default script.

So I propose that we make a (breaking) change to exclude default from the prefix resolver. @rowanoulton, would you be interested in taking this?

Because this and #24 are both breaking changes, we should probably merge them into a branch called next and when they're both merged into that, we'll merge that into the master branch so we can release them at the same time.

Should p-s stop executing commands when an error occurs?

I wonder if p-s should stop the execution when an error occurs when executing multiple commands (in parallel or not).

Any thoughts?

Especially when p-s run a command and then the second command depends on the first one...

support for pre

  • p-s version:3.1.0
  • node version:6
  • npm version:4

Scripts file (or at least the relevant bits):

The command executed:

The output:

Problem description:

currently there's no support for 'pre' scripts in nps. it would be nice if p-s suppported this for when we import scripts from npm.

Suggested solution:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.