Standard Method (no library)
The arguments are stored in process.argv
Here are the node docs on handling command line args:
process.argv
is an array containing the command line arguments. The first element will be 'node', the second element will be the name of the JavaScript file. The next elements will be any additional command line arguments.
// print process.argv
process.argv.forEach(function (val, index, array) {
console.log(index + ': ' + val);
});
This will generate:
$ node process-2.js one two=three four
0: node
1: /Users/mjr/work/node/process-2.js
2: one
3: two=three
4: four
You did a great job of summarizing what's awesome about Node.js. My feeling is that Node.js is especially suited for applications where you'd like to maintain a persistent connection from the browser back to the server. Using a technique known as "long-polling", you can write an application that sends updates to the user in real time. Doing long polling on many of the web's giants, like Ruby on Rails or Django, would create immense load on the server, because each active client eats up one server process. This situation amounts to a tarpit attack. When you use something like Node.js, the server has no need of maintaining separate threads for each open connection.
This means you can create a browser-based chat application in Node.js that takes almost no system resources to serve a great many clients. Any time you want to do this sort of long-polling, Node.js is a great option.
It's worth mentioning that Ruby and Python both have tools to do this sort of thing (eventmachine and twisted, respectively), but that Node.js does it exceptionally well, and from the ground up. JavaScript is exceptionally well situated to a callback-based concurrency model, and it excels here. Also, being able to serialize and deserialize with JSON native to both the client and the server is pretty nifty.
I look forward to reading other answers here, this is a fantastic question.
It's worth pointing out that Node.js is also great for situations in which you'll be reusing a lot of code across the client/server gap. The Meteor framework makes this really easy, and a lot of folks are suggesting this might be the future of web development. I can say from experience that it's a whole lot of fun to write code in Meteor, and a big part of this is spending less time thinking about how you're going to restructure your data, so the code that runs in the browser can easily manipulate it and pass it back.
Here's an article on Pyramid and long-polling, which turns out to be very easy to set up with a little help from gevent: TicTacToe and Long Polling with Pyramid.
Best Answer
npm 2 and newer
It's possible to pass args to
npm run
since npm 2 (2014). The syntax is as follows:npm run <command> [-- <args>]
Note the
--
separator, used to separate the params passed tonpm
command itself, and the params passed to your script.With the example
package.json
:here's how to pass the params to those scripts:
Note: If your param does not start with
-
or--
, then having an explicit--
separator is not needed; but it's better to do it anyway for clarity.Note below the difference in behavior (
test.js
hasconsole.log(process.argv)
): the params which start with-
or--
are passed tonpm
and not to the script, and are silently swallowed there.The difference is clearer when you use a param actually used by npm:
To get the parameter value, see this question. For reading named parameters, it's probably best to use a parsing library like yargs or minimist; nodejs exposes
process.argv
globally, containing command line parameter values, but this is a low-level API (whitespace-separated array of strings, as provided by the operating system to the node executable).Edit 2013.10.03: It's not currently possible directly. But there's a related GitHub issue opened onnpm
to implement the behavior you're asking for. Seems the consensus is to have this implemented, but it depends on another issue being solved before.Original answer (2013.01): As a some kind of workaround (though not very handy), you can do as follows:
Say your package name from
package.json
ismyPackage
and you have alsoThen add in
package.json
:And in your
script.js
:That way, by default
npm start
will use 8080. You can however configure it (the value will be stored bynpm
in its internal storage):Then, when invoking
npm start
, 9090 will be used (the default frompackage.json
gets overridden).