npm exec <cmd> #1543

Closed
slaskis opened this Issue Oct 12, 2011 · 20 comments

7 participants

@slaskis

It would be cool if the npm get would be able to get it's config from the package.json.

Use case for me is to get the port which is defined in the package.json like

{"config":{"port":8001}} 

and then i could do this to test if the app is running (in my deploy.conf):

curl localhost:`npm get port` >/dev/null

alt. I'd have to use npm get foo:port, either way it would be useful i think.

I know it's possible to set on a user basis but this way i wouldn't have to login to the server to set it's port...

@isaacs
npm member

What if it was npm get pkgname:port instead? We could just add the current package's configs to the set like happens with scripts.

@isaacs
npm member

Oh, haha, I should probably have just kept reading to the bit where you suggested that.

Yes. This is a good idea. Note that if you can make this a script, then the port will be set in the npm_package_config_port environment var, and can be overridden by running npm config set foo:port 80 on the server.

Also: it'd be nice to have an npm exec <cmd> which would run a command with all the same environment variables that scripts have. Then you could do: npm exec 'curl localhost:$npm_package_config_port'

@michaelcontento

I think you can improve npm exec <cmd> even further if you prepend the result of npm bin to the PATH. This would fix issues like #957 and would allow to install more packages without -g. Just run npm exec vows test/* instead of npm install -g vows && vows test/*.

And my last wish would be to use npm exec <cmd> inside of the scripts object in the package.json ;)

Thanks!

@isaacs
npm member

And my last wish would be to use npm exec inside of the scripts object in the package.json ;)

Why? The point of npm exec would be to simulate the env that you already get in running scripts from package.json.

@michaelcontento

And my last wish would be to use npm exec inside of the scripts object in the package.json ;)

Why? The point of npm exec would be to simulate the env that you already get in running scripts from package.json.

Including the extended PATH? So "test": "vows test/*" in the package.json will find the vows executable in npm bin and I don't need to install vows globally? Well ... than ignore my last wish and I'm happy :)

@isaacs
npm member

Including the extended PATH? So "test": "vows test/*" in the package.json will find the vows executable in npm bin and I don't need to install vows globally? Well ... than ignore my last wish and I'm happy :)

Yep, that's right! That's why npm bothers to put bins in ./node_modules/.bin, so that it can access them later :)

@michaelcontento

Alright. So npm exec <cmd> would be a superset of npm run-script <script> <name>. It does basically the same but for arbitrary user input and without the package.json lookup.

For me this makes sense and would solve my current problems. But i am new to the whole nodejs and npm ecosystem so .. what do you think about it?

@digitalrinaldo

Was an error on my part. Ant argument processing for the shells expectes the arg to not have spaces. This works...

<exec executable="${basedir}/node/install/bin/npm" dir=".">
  <env key="PATH" path="${basedir}/node/install/bin:${env.PATH}" />
  <arg value="install"/>
  <arg value="nodeunit"/>

The use of ant makes for a very easy to use portable way of allowing developers to isntall a tagged version of node, install the libraries required for testing and other tools and have a local copy that has nothing to do with the local system copy just by checking out the development workspace and typring ant -f node.xml install node

@isaacs
npm member

@digitalrinaldo Was that message intended for some other thread...?

@digitalrinaldo

No -- We want a developer to just do git hub clone and then run ant -f node.xml and it should get the tag we are using and install node with npm ( this was a great addition) and then install other developer dependent things like nodeunit.

Do you have a better idea? I struggled with this. We have a rule that the workspace includes all tooling that is necessary to build and deploy -- granted artifact managers like maven, nexus and artifactory have a long way to go one only cares about java another only about js so when you have a project that has many artifacts we don't want developers tracking it down. When I used to work on big government type things -- you would also archive this system and it was expected to build a year later with the tools used at the time. Virtualization has made it easier but virtual images are too slow and buggy at the ui level.

If I could make time it would be really useful to build a generalized depot manager using npm that makes mvn a subset.

you can close it sorry for the noise.

@isaacs
npm member

@digitalrinaldo Right. That's all interesting of course, but what does that have to do with npm exec <cmd>? Maybe is there some other open issue regarding ant and whatnot that this is more related to? Just trying to figure out context.

@digitalrinaldo
@digitalrinaldo

In the list below I try to set userconfig to a different directory so that node_modules will be created in that directory.

exec is coming from ant. I tried it with and without .npmrc after ${basedir}

xecute:Java13CommandLauncher: Executing '/Users/rinaldo/Documents/workspace/AppletPrint.AppletPrint/node/install/bin/npm' with arguments:
'install'
'nodeunit'
'--userconfig'
'/Users/rinaldo/Documents/workspace/AppletPrint.AppletPrint'

The ' characters around the executable and arguments are
not part of the command.
[exec] npm http GET https://registry.npmjs.org/nodeunit
[exec] npm http 304 https://registry.npmjs.org/nodeunit
[exec] npm http GET https://registry.npmjs.org/tap-assert
[exec] npm http GET https://registry.npmjs.org/tap-producer
[exec] npm http 304 https://registry.npmjs.org/tap-assert
[exec] npm http 304 https://registry.npmjs.org/tap-producer
[exec] npm http GET https://registry.npmjs.org/tap-results
[exec] npm http GET https://registry.npmjs.org/yamlish
[exec] npm http GET https://registry.npmjs.org/inherits
[exec] npm http 304 https://registry.npmjs.org/inherits
[exec] npm http 304 https://registry.npmjs.org/tap-results
[exec] npm http 304 https://registry.npmjs.org/yamlish
[exec] nodeunit@0.6.4 ../../../node_modules/nodeunit
[exec] ├── tap-assert@0.0.10
[exec] └── tap-producer@0.0.1

@digitalrinaldo

Solved it by using prefix to point to --prefx="other installation of node"

@samshull samshull pushed a commit that referenced this issue Apr 25, 2013
Sam Shull Add npm-exec(1) as command for executing dependency executables
references #1543
c7e672b
@foxx

Was any conclusion reached on this? Have you seen npm-exec alias on StackOverflow?

@othiym23 othiym23 removed the nice to have label Oct 7, 2014
@xaka

I wonder if any work is going on to get this done or PR is expected as well? Doing bundle exec <...> in Ruby world is so helpful and it would be nice to have similar killer feature for NPM. It just sucks that you can install packages locally, but to run those you either have to end up with hacks like npm-exec or simply doing dirty things like ./node_modules/.bin/<...>. After all if scripts have painless access to binaries under node_modules/.bin, why users can't?

@othiym23

@xaka Many, many people would find an npm-exec command useful, and even just a small patch getting the ball rolling would probably be enough to get community support sufficient to get the feature landed, but this isn't something that the CLI core team (me and @iarna) is going to have the bandwidth to do anytime soon.

@xaka

There is PR #4058, but your comment was we sort of routed around this PR in favor of #5518 so I'm not quite sure whether you meant that PR doesn't need anymore or what's the deal? We need to clear the confusion and I believe the wheels will start rolling again :)

@othiym23

By that I meant that @bcoe added the ability to pass parameters to run-scripts in npm@2 – it was, in fact, the primary breaking change that led to the bumping of npm's major version.

One version of npm-exec, as described here (as well as #4058, #5518, and #3313), is a standalone command that allows you to run run-scripts free of npm's sophisticated / complicated command-line argument parsing. It allows you to pass arguments to the scripts defined by the scripts stanza in package.json. The arguments passing bits of this are what got implemented in #5518 and which obsoleted the work in progress on #4058. Most of the discussion of npm-exec in terms of incorporating it directly into the main npm install has been this version of npm-exec.

Another version is a direct analog of bundle exec. I think this is what you're describing, and is what would be most useful for many people. @grncdr started work on a standalone version of this in the form of http://npm.im/npm-exec a while ago. I'm also not sure that's a utility that needs to be a part of the main npm distribution, but I'm also not opposed to incorporating it, especially if the behavior described in the previous paragraph is also incorporated.

@othiym23

Closing this in favor of #6053, which has a better description of where we landed on adding this.

@othiym23 othiym23 closed this Apr 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment