npm run a bin script

[redchair123]

Suppose my package.json looked like

{
    ...
    "bin": { "foo": "./bin/bar.js" },
    ...
}

Is there a subcommand npm _____ foo that will execute the script? I'm in development, so the symlinks dont exist, and I really don't want to perform some link jujutsu to get this to work. I'd hope that npm bin foo would work but that does something different

[smikes]

I don't think there's anything like that at present, no.

The only thing that's somewhat similar is that scripts specified in package.json can assume that "./node_modules/bin" is in the PATH, but if your package hasn't been installed yet, its bin scripts won't be in the path.

Can you tell us more about what you're trying to do? There may be some other way to achieve it.

[redchair123]

@smikes thanks for the response.

I'm developing a module which will ship with executable scripts. If I put the entries in bin, npm install does exactly what I expect. However, when I'm in development, those symlinks are unavailable. I don't want to install over the global version, and npm link seems like the wrong thing to do when working on the same module (as i understand it, npm link is primarily useful when working with other modules)

[smikes]

I would probably suggest npm link -g but that would install over the global version.

Does the unmodified global version need to exist for the use of other scripts/people? One option might be to use an environment manager such as "nvm" and designate an older version of node as using the devel version of your package and bins...

[smikes]

Hi again! I'm assuming that this is still a problem, because I'm pretty sure we haven't done anything to change the circumstances.

I think this is basically a feature-request, similar to the outstanding request for npm exec #6053 (which maybe could be extended to cover this).

Another possibility would be for npm run foo to check for bin.foo as a fall-back when scripts.foo does not exist. (That has its own problems, though, as we discovered when fiddling with the nonexistent script handling before.)

[othiym23]

This is a feature request, and pretty different from npm-exec in its way, although the two could maybe be merged. A way in which it is similar to npm-exec is that the core npm team isn't going to have time to tackle this anytime soon, so if somebody wants to take a stab at an implementation of this, I'd be happy to work with them to get it in shape to land, but otherwise, it's probably not going to happen until then.

[redchair123]

@smikes @othiym23 I ended up writing a fairly simple shell script to implement this

[ianfixes]

Is this the wrong approach?

var exec = require('child_process').exec;
var argv = require('process').argv;
var join = require('path').join;
var spawn = require('child_process').spawn;
var firstArgPos = 2; // after 'node' and the name of this script
exec('npm prefix', function(err, prefix, _) {
  spawn(join(prefix.trim(), 'node_modules', '.bin', argv[firstArgPos]),
        argv.slice(firstArgPos));
  // do something with output
});

[Haroenv]

Could this issue be reopened? Installing the script you're developing to be able to run it from that directory seems kinda weird to me. Currently I use this:

"script": {
  "bin": "same/path/as/bin"
}

and then use npm run bin. At this point I'm repeating the paths in the package.json, which is fine if you just have one bin, but hypothetically in the case where there are a bunch of bins this would get messy.

Also by putting this in the scripts I'm not really sure if this is useful for endusers.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.

[jasonkarns]

@Haroenv just a note: you can "simplify" (not sure it's actually simpler) that script to "bin": "$npm_package_bin_<pkg.name>" since the normalized package.json is flattened to $npm_package_* env vars within npm scripts.

[Haroenv]

I'm using Yarn now, which has this feature

[0xcaff]

@Haroenv How?

[jasonkarns]

@Haroenv agree, I'd like to see that working in yarn.

Personally, I follow a pattern of making the start script for any package which is a CLI point to the main bin:

"name": "foo-app",
"bin": "./bin/foo",
"scripts": {
  "start": "$npm_package_bin_foo_app"
}

No repetition of path that way.

And if using the object form:

"bin": {
  "foo": "./bin/foo",
  "bar": "./bin/bar"
},
"scripts": {
  "start": "$npm_package_bin_bar"
}