Older node support

[ljharb]

To truly be a replacement for npm run, npx needs to work on as many node versions as possible.

Currently, use of untranspiled const and destructuring, and probably other things, means it can't work prior to node 4.

Would it be possible to babel-transpile npx, so that your language level choice isn't a barrier to using it on older node versions (including travis-ci runs on those versions)?

[zkat]

npx relies on npm5 under the hood, which strictly only supports node@4 and higher. There's workarounds for that, but I'd rather not have to support node versions that are now well out of maintenance and support. I'm definitely getting the impression that the node community as a whole has been moving wholesale to node@>=4, too.

I generally prefer avoiding transpilation, too: I've done enough of that that it's a huge relief to be able to just instantly run my changes, and not have to also maintain a whole build setup. I'm leaning strongly towards saying no to this, though I understand the desire to have it work in more versions.

This will probably be helped better in the future when we start packaging npx as a standalone binary with a statically-compiled node built into it (probably using pkg), but that'll also require npm to be able to do that, too. I guess if you use the --npm option, you can do that right now by building an npx binary and passing the flag in to point to your legacy npm.

[ljharb]

hmm - what about it relies on node 5?

I understand the desire to avoid transpilation; while I'd be happy to submit a PR using babel, I'd be equally happy to submit a PR rolling back to ES5 :-)

[zkat]

@ljharb npx bundles npm5 itself, and npm5 doesn't support anything below node4.

I'd personally rather have npx have the same version support range as npm itself -- which is pinned to "supported versions of node".

[ljharb]

:-/ that's really unfortunate, since it doesn't satisfy the need that motivated npm/npm#6053.

(also, it's kind of odd to have it depend on npm 5, while npm 5 plans to depend on it?)

What about doing something fancy where it babel-transpiles on publish, but the bin does a conditional require - ie, on node 4+, it hits the raw entry point, and on older nodes, it runs the babel one? Since this is a CLI, there wouldn't be any bundling cost.

I'm primarily interested in incorporating this into nvm, which supports every version of node (that shipped with an npm, for this comment's purposes). If npx requires node 4+, i won't be able to use it :-/

[zkat]

If you're gonna be incorporating it into nvm, why not do the transpilation at that point? That way you can do a wrapper around npx itself that then re-points it to the npm you want to use? Would that solve your use-case here?

[ljharb]

I want to npm install -g npx in every version of node automatically, so i can provide a better nvm exec in all node versions.

iow, I don't think that would solve my use case because nvm doesn't ship any JS. Also, it's not safe to transpile code you didn't write.

[zkat]

Alright so!

I spent a little bit setting up a new "compat" build for npx that would transform the sources to 0.10-compatible code. Everything seemed to be alright and all and then...

..turns out some of npx's dependencies, for example npm-package-arg, are themselves using node@>=4 features. So transforming npx itself is insufficient to get this going. Otherwise, I would've just pushed what I did.

It's worth noting that npx users who want to do one-off runs of commands can still retain a primary, npx-compatible node and then use $ npx -p [email protected] <command to run>. If @aredridel gets around to hashing out npm.im/node, it'll be as easy as $ [email protected] ... and related incantations, if you're also using the npx fallback.

Since I really don't want to make this an even bigger maintenance effort, and I really don't want to start downgrading or transpiling npx's own dependencies, I'm going to close this. I know it's likely disappointing that you can't do exactly what you wanted here, but I think it's a reasonable resolution given the constraints. I think it's acceptable even for tools like npx to drop support for node versions that are significantly out of maintenance at this point, specially when they're lacking such basic features as Promise and let -- I'm not even using shinier things like destructuring.

Cheers!

[ljharb]

@zkat would you be willing to reconsider if things like npm-package-arg expands its support? I'd be happy to file all the requisite PRs, and commit to covering any related maintenance going forward.

[zkat]

@ljharb The issue at hand here is that the cost of continuing to support legacy, unsupported versions of node is starting to really rear its head. I don't think it's sustainable in the long term to start going to every single dependency npm uses and reverting their decisions to start using newer versions. The costs are going to add up, and they're really not just gonna happen to be deps maintained by the npm team itself.

If an author of an external dep decides that no, they won't take your request, does that mean that now npx needs to either pin its dependency for the foreseeable future, or worse -- be forced to pick up maintenance just to maintain that compatibility? I really just don't think that's reasonable.

I think if you're willing to put this much effort into maintaining compatibility, you're much much better off just maintaining a project that wraps/depends on npx and doing your own transpilation/bundling, even if it might seem to be a bad idea to "transpile someone else's project". People apply transpilation transforms to their dependencies all the time -- this is pretty much what bundlers do. I don't think it's that much of a problem to pull off.

What I would do is take a patch that turns that DEFAULT_NPM declaration in parse-args.js to say something like const DEFAULT_NPM = +process.versions.node[0] < 4 ? 'npm' : path.resolve(....), so you don't have to do anything weird in the bundler, even though the raw code will never run on node < 4.

[ljharb]

Thanks, I'll think about what I want to do going forward. Appreciate the thoughtful responses, even though it didn't shake out my way.