Evaluate usage of npx

[addyosmani]

Kudos to @zkat for suggesting we take a look at npx - a module for executing npm package binaries and installing any dependencies needed for them to work. Here's a demo of npx in action with yo:

https://twitter.com/maybekatz/status/883846850171641856

libnpx is a lib-ified version of npx that we could embed in yo, opening the door to $ yo <generator-name> installing and running <generator-name> automatically in a private scope the same way npx does without polluting globals.

Why is this potentially useful?

This effectively reduces the two steps of npm install -g yo generator-name followed by yo generator-name into yo generator-name - lowering the friction for how easy it would be to start off a new project.

The differences between merely stringing these steps into npm install -g yo generator-name && yo generator-name and npx support is:

• No global conflicts
• Easily pick different versions
• Private scopes
• Don't pollute global installs with things you'll only ever run once

npx is slated to land in npm sometime in the next few weeks.

[SBoudrias]

I think this is a great idea (and I believe we've had such a discussion before). So it's great to see a library that would make building this functionality easy.

Integrating this with yo though would still require the user to first install yo; so we just skip the npm install generator-node step once yeoman is installed right?

Does anyone knows more about the private scope? I'm not clear what's the impact of this.

[zkat]

the gist of the "private scope" is that npx installs things using ~/.npm/_npx as a "global prefix", and then adds ~/.npm/_npx/bin to $PATH. That means installations work exactly like globals, except npx happens to be doing some $PATH magic to arrange it into place. npx also does a bit of juggling to make that (mostly) safe to do, make it relatively efficient, etc.

Note that integrating this with yo wouldn't require users to install yo, if they already have npx installed (which any users using npm@>=5.2.0 will have, starting next week).

So, putting it all together, if yeoman integrates libnpx and a user has npx available in their system, as most npm users will, you can do:

$ npx yo node --opt1 --opt2
# npx installs yo, then yo installs generator-node
...scaffolding time!...

Or, if they're using the npx fallback:

$ yo@3 node

Which is I think about as short as you can get for any scaffolding ever tbh. ;) Note that this is something users would be able to do just by installing Node.js and nothing else.

[SBoudrias]

@zkat is there API/integration documentation for npx?

[zkat]

@SBoudrias the "API" is really just a fairly hacky/quick refactor of what was once a CLI-only app, so I could use it with npm itself. There's nothing specifically documented yet at the JS API level, but also what's currently there is all I need from it, so I'm hoping having other use-cases for it will help develop it a bit. Literally the only consumers of libnpx right now are npm and npx.

[Telokis]

So, what's the progress on this. It would be a very nice to have. Are you still discussing it internally or do you wait for a PR?

[SBoudrias]

@Telokis PR is welcomed :)

[kirillgroshkov]

PR anyone?:)

[JoshuaKGoldberg]

libnpx is no longer supported - it's part of npm now. Renaming this issue to note being more generally about using npx.

We should note that npx added an installation confirmation prompt for security reasons. It's enabled by default unless a -y/--yes CLI flag is provided. We should do that here too: it's a security concern that users could type the wrong generator by accident and suddenly install + execute a malicious package with an intentionally similar name.

https://docs.npmjs.com/cli/v7/commands/npx#compatibility-with-older-npx-versions