binDependencies

[shannonmoeller]

Would be nice to have the ability to have a list of dependencies that are only needed when a module is installed globally (commander, liftoff, nopt, etc.).

[othiym23]

What problem are you trying to solve? Right now, consumers of a module don't need to differentiate between installing it for its module code and installing it for its included binaries – you can add scripts that get run with a path that includes all the binaries exported by the current package's dependencies, so you can do things like "npm run check" that in turn runs jshint and jscs without having them globally installed on your machine. This is pretty nice behavior, and adding a way to override it feels like a footgun to me.

[othiym23]

What problem are you trying to solve? Right now, consumers of a module don't need to differentiate between installing it for its module code and installing it for its included binaries – you can add scripts that get run with a path that includes all the binaries exported by the current package's dependencies, so you can do things like "npm run check" that in turn runs jshint and jscs without having them globally installed on your machine. This is pretty nice behavior, and adding a way to override it feels like a footgun to me.

[shannonmoeller]

Perhaps "binDependencies" is a misnomer. The problem I'm trying to solve is the weight of a global installation vs a local installation. Many modules that have a CLI, also have a JS api. Often, some dependencies are only needed by the CLI, so when installing a module locally for its JS api, CLI-specific modules such as commander and nopt are needlessly included.

What I would like to be able to do is maintain a separate list of dependencies that are only used for the CLI, so that they will be installed by npm i -g, but not by npm i.

[shannonmoeller]

Perhaps "binDependencies" is a misnomer. The problem I'm trying to solve is the weight of a global installation vs a local installation. Many modules that have a CLI, also have a JS api. Often, some dependencies are only needed by the CLI, so when installing a module locally for its JS api, CLI-specific modules such as commander and nopt are needlessly included.

What I would like to be able to do is maintain a separate list of dependencies that are only used for the CLI, so that they will be installed by npm i -g, but not by npm i.

[aredridel]

Is there any reason these shouldn't be two separate packages, perhaps the cli depending on the API?

[aredridel]

Is there any reason these shouldn't be two separate packages, perhaps the cli depending on the API?

[othiym23]

I endorse @aredridel's line of questioning – this is, in fact, the direction that npm itself is heading. It's already a set of semi-dependent modules that are combined into the CLI, and one of the major projects I have over the next few quarters is loosening the coupling between those modules, so that people can use only the bits they need without having to install npm as a whole. What would the functionality proposed buy us that outweighs the additional complexity introduced to the installer?

[othiym23]

I endorse @aredridel's line of questioning – this is, in fact, the direction that npm itself is heading. It's already a set of semi-dependent modules that are combined into the CLI, and one of the major projects I have over the next few quarters is loosening the coupling between those modules, so that people can use only the bits they need without having to install npm as a whole. What would the functionality proposed buy us that outweighs the additional complexity introduced to the installer?

[shannonmoeller]

There are many packages that take this approach. grunt and grunt-cli are a classic example. However, it can be confusing for users of these modules to know the difference. When I first started learning grunt, I often npm i -g grunt and wondered why the grunt command was not available.

Additionally, I don't like the overhead of having to maintain two separate packages, READMEs, etc. for what is essentially one package.

[shannonmoeller]

There are many packages that take this approach. grunt and grunt-cli are a classic example. However, it can be confusing for users of these modules to know the difference. When I first started learning grunt, I often npm i -g grunt and wondered why the grunt command was not available.

Additionally, I don't like the overhead of having to maintain two separate packages, READMEs, etc. for what is essentially one package.

[othiym23]

In grunt's case, I think that's because grunt and grunt-cli have their names backwards. If it had been grunt (cli) and grunt-support (infrastructure) it would have been much less confusing. But this is one of those things we had to do a few times before the pattern became clear, so let's take the lesson for what it is and not try to generalize it too much.

Additionally, I don't like the overhead of having to maintain two separate packages, READMEs, etc. for what is essentially one package.

For most packages, this is pretty low overhead. A bunch of the npm-internal packages expose convenience CLIs, and it hasn't proved to be much of an issue.

That is to say, thanks for taking the time to define the problem space with me, but I'm a qualified -1 on this. If somebody wants to take a stab at putting together a PR for it, I'm happy to review it, but I don't think this is a pressing need for the client right now.

[othiym23]

In grunt's case, I think that's because grunt and grunt-cli have their names backwards. If it had been grunt (cli) and grunt-support (infrastructure) it would have been much less confusing. But this is one of those things we had to do a few times before the pattern became clear, so let's take the lesson for what it is and not try to generalize it too much.

Additionally, I don't like the overhead of having to maintain two separate packages, READMEs, etc. for what is essentially one package.

For most packages, this is pretty low overhead. A bunch of the npm-internal packages expose convenience CLIs, and it hasn't proved to be much of an issue.

That is to say, thanks for taking the time to define the problem space with me, but I'm a qualified -1 on this. If somebody wants to take a stab at putting together a PR for it, I'm happy to review it, but I don't think this is a pressing need for the client right now.

[iarna]

While the idea of having dependencies that are only installed when installing associated binaries is intriguing, I can’t think of a scenario where we wouldn’t be installing the binaries. Intra-module dependencies on binaries is a thing, even outside of the use of binaries from devDependencies in the scripts section of the package.json. As @othiym23 said earlier, thank you for putting together this write of this use case. As I can’t see anything actionable at this point, I’m going to close this.

[iarna]

While the idea of having dependencies that are only installed when installing associated binaries is intriguing, I can’t think of a scenario where we wouldn’t be installing the binaries. Intra-module dependencies on binaries is a thing, even outside of the use of binaries from devDependencies in the scripts section of the package.json. As @othiym23 said earlier, thank you for putting together this write of this use case. As I can’t see anything actionable at this point, I’m going to close this.

[piranna]

I think the point here is about dependencies like CLI arguments parsers or terminal colors, that on a good design they would (should?) only be used/depended/downloaded when the module is directly used as a CLI command, not when the module is used as a dependency library.

[piranna]

I think the point here is about dependencies like CLI arguments parsers or terminal colors, that on a good design they would (should?) only be used/depended/downloaded when the module is directly used as a CLI command, not when the module is used as a dependency library.