Set alias shorthand for scripts and config

[cesarandreu]

tl;dr: Allow aliasing npm_package_config and npm_package_scripts to something shorter.

I've been using npm as script runner for my apps with great success; I'm very happy to get rid of Gulp/Grunt and the complexity they bring along.
However, an issue I've been noticing is that referencing configs as npm_package_config_foobar makes it harder to parse what's going on, especially for longer combinations. The information you truly care about is always at the end, but you have a bunch of npm_package_config_'s repeated everywhere.

It's become more evident as I've started using 6to5-node, which requires you to call scripts directly.
For example: 6to5-node _mocha test.spec.js won't work because it'll try to load ./_mocha. So you have to run 6to5-node node_modules/.bin/_mocha test.spec.js. But it starts to become a problem when you have a bunch of scripts and you want to reuse different configs.

Small example of the difference that it could make:

Currently

{
  "config": {
    "all_tests": "test/**/*.spec.js",
    "mocha": "node_modules/.bin/_mocha",
    "istanbul": "node_modules/.bin/istanbul"
  },
  "scripts": {
    "base": "6to5-node --ignore='foo|bar|baz' --experimental --cache",
    "test": "npm run base -- $npm_package_config_mocha $npm_package_config_all_tests",
    "coverage": "npm run base -- $npm_package_config_istanbul cover $npm_package_config_mocha $npm_package_config_all_tests"
  }
}

Idea/Proposal

{
  "config": {
    "npm_package_config_alias": "c_",
    "all_tests": "test/**/*.spec.js",
    "mocha": "node_modules/.bin/_mocha",
    "istanbul": "node_modules/.bin/istanbul"
  },
  "scripts": {
    "base": "6to5-node --ignore='foo|bar|baz' --experimental --cache",
    "test": "npm run base -- $c_mocha $c_all_tests",
    "coverage": "npm run base -- $c_istanbul cover $c_mocha $c_all_tests"
  }
}

Obviously in this example it wouldn't be a problem to just write the paths directly. But as you end up adding multiple test types, production and development environment scripts, build scripts, application-specific scripts, etc. it becomes painful.

I think this isn't generally an issue for library developers (it seems like most libraries don't require as many scripts). For application development, my experience has been that you end up needing a lot more scripts.

To achieve this, a new alias/shorthand/whatever section could be added to package.json or certain values could be defined in config. One potential problem with defining it in config is that it would break if someone set the value to something else, so it should probably be a per-project config.

If npm has no interest in this or considers it out of scope of the problems that it tries to address then it could be implemented as a third-party library. I figured I'd ask because npm is already so close to fulfilling my script-runner needs.

[smikes]

/cc @othiym23 as a feature request

This sounds interesting... can you implement a proof-of-concept as a small independent module? It should be possible to write a program that reads the environment and copies all npm_config_package_<var> variables to <prefix>_<var>.

Some other approaches --

1. You may wish to file an issue with 6to5-node about searching PATH for the script
2. You could use which _mocha, since ./node_modules/.bin is in your PATH
3. consider using the #! hack-around described here: http://sambal.org/2014/02/passing-options-node-shebang-line/

[DVLP]

+1 any workarounds?

This works in command line but not in NPM

function v () { echo \"$npm_package_config_${1}\"; };
v param-name

How to use it with NPM without any evil "evals" etc. so this could work out-of-the-box in i.e. AWS (automatic deployment) ?

[othiym23]

I hear you; once you have a bunch of package scripts, package.json can get a little hard to scan. That can be worked around by breaking them down into smaller pieces, but as you've noticed, once you start trying to do more complex things, they still get unwieldy. I think at that point you're reaching the limits of what package scripts are meant to do, and want to look at a utility like scripty or p-s, which are designed to extend / modularize package scripts for power users who need that extra flexibility.

The CLI team tries not to mess with the functionality of package scripts much, as there are lots of non-obvious backwards compatibility issues, and because we believe their success is due, in large part, to the way they balance simplicity with expressivity. As such, we're probably not going to implement this change. I hope the workarounds above are useful solutions to the problem you describe, and thank you for your time!