Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Allow dynamic loading of npm subcommands using the powers of UNIX #3999

Closed
grncdr opened this Issue · 5 comments

2 participants

Stephen Sugden Luke Arduini
Stephen Sugden

I propose having npm <command> fall back to searching for an external npm-<command> script to be executed in the same environment as npm run-script if-and-only-if no internally defined command <command> is found.

This is exactly what git does, and it makes creating and maintaining extensions much easier. Given that the proposed npm-exec would prepend node_modules/.bin to the path, it would also make it much easier for users to compose their npm experience out of other modules, without having to rely on any globally installed tools.

(See some discussion over on #3313 as well)

Stephen Sugden

npm already depends on which so I think some sort of npm exec is really the only barrier to implementing this. I'm working on that and aim to have a PR against npm available by the end of the week.

Luke Arduini

So when npm adds a new command, would this not potentially break workflows if there's a conflict?

Stephen Sugden

Yes, but demand for adding new commands to npm should decrease significantly, as this provides a very reasonable alternative when users want npm to do some new thing that the maintainers aren't sure about. This, and the potential modularity benefits for existing npm commands hopefully outweigh the costs.

npm adding a new command would break users setups in the following (probably rare) circumstance:

  • Somebody is using a custom npm command
  • npm maintainers decide to add a command to the core with the same name
  • the users custom npm command is either not in the registry or
  • the command is in the registry and the npm maintainers feel that it deserves to have it's name clobbered.

If the existing command in the registry is the one the maintainers want to add to the core, then they can simply add it to npm's package.json and everybody wins.

Still it might make sense to warn the user if a built-in command takes precedence over an external command of the same name, which I'd be happy to add to the feature if/when I get around to writing it.

Luke Arduini

the command is in the registry and the npm maintainers feel that it deserves to have it's name clobbered.

We don't have 1-1 mapping with npm commands and package names in the registry.

The cultural problem I want to avoid is a hypothetical third party npm command becoming popular with a group of n people, then instantly pissing off n people because we decided to add a command with the same name that does something else. Sure, we could avoid that by naming it something else, but this creates a situation where we need to keep track of command names we should and shouldn't use because of an external force over which we have no control.

Q: If 300 people like this npm command, doesn't it make sense for it to be added in?
A: No, it wouldn't necessarily make sense, because there's no guarantee of consistency that the custom command is both in the scope of what npm is trying to achieve and is generic enough for most use cases.

Q: How can I run custom commands then?
A: You can use npm exec (once it exists), or npm run scripts. The only tradeoff here is having to type a few extra characters. If this is not convenient, you can write a shell alias to make it less.

Luke Arduini luk- closed this
Stephen Sugden

Sure, we could avoid that by naming it something else, but this creates a situation where we need to keep track of command names we should and shouldn't use because of an external force over which we have no control.

I agree, but strongly believe npm should be removing commands, not adding them. If 300 (or 3000) people like an npm command, great, they can continue to add it to their dependencies. I like this idea because it significantly raises the bar for adding new commands to npm.

You can use npm exec (once it exists), or npm run scripts. The only tradeoff here is having to type a few extra characters. If this is not convenient, you can write a shell alias to make it less.

This is fair, saving 5 characters is most likely not worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.