I have these two node.js command line commands:
$ NODE_ENV=dev_local npm start --fp data_for_testing/csvfile.csv --mptp map_ivr_itg
$ NODE_ENV=dev_local node start_script --fp data_for_testing/csvfile.csv --mptp map_ivr_itg
I am using nconf the command line and environment variable parser for node.js.
The problem is the command line arguments --fp and --mptp seem to disappear when using npm start.
Furthermore, as an aside, does any program interpret --fp as a force flag, as NPM is warning?
Your command line flags (e.g., --fp) are being sent to npm and not the script that results from running npm start. To send them to the resulting script as arguments, first send -- by itself as an argument. That indicates that the remaining arguments are for the resulting script and not for npm itself.
npm start -- --fp ...
Related
In node 14 I had the following script
scripts: {
"test": "node test.js",
}
Then I ran it with the following command npm run test -- --value '10' this gave the output
node test.js "--value" "10"
But when I switch to node 16 every argument that starts with -- gets removed
So whenI run npm run test -- --value '10' this gives the output
node test.js "10"
Where did "--value" go?
I'm not sure 100% about the root cause, but I can now explain the semi-root causes and ways to work around it.
It appears that while on my machine there is only an npm.cmd file in C:\Program Files\nodejs, on yours there is also an npm.ps1 file. It appears this file is created only in some install/upgrade paths, and your node upgrade seems to cause this file to be created.
That means that when you run npm in PowerShell, it is invoking an ExternalScript and not an Application. For this reason, semantics for calling cmdlets apply to the invocation and not semantics for calling native commands/applications.
These semantics include the use of -- to stop parsing further arguments. That means that in this case PowerShell will consume the -- token so it never arrives to npm! And in turn, npm now being called with npm run test --value 10 without -- will swallow --value because it's considered an argument to npm and not to the script you want to invoke.
Quote from the docs:
The end-of-parameters token (--)
The end-of-parameters token (--) indicates that all arguments following it are to be passed in their actual form as though double quotes were placed around them. For example, using -- you can output the string -InputObject without using quotes or having it interpreted as a parameter
It doesn't state here that it applies only to cmdlets and external scripts but my testing showed that that's the case.
There are four possible solutions I can think of:
Create an alias to manually point npm to npm.cmd instead of npm.ps1: Set-Alias -Name npm -Value npm.cmd
Rename/remove npm.ps1 to make sure PowerShell uses npm.cmd instead
Add another -- in front which is consumed by PowerShell to allow the following -- to be consumed by npm: npm run test -- -- --value 10 or npm -- run test -- --value 10
Quote the --: npm run test '--' --value 10
I'm trying to pass environment variables to npm scripts as arguments
with no success.
export ENVIRONMENT=test.proxy.json
npm run test
I'm trying to do something like this in package.json
npm run test --proxy-config-file $ENVIRONMENT
When you do this:
export ENVIRONMENT=test.proxy.json
npm run test
or this:
ENVIRONMENT=test.proxy.json npm run test
then you will pass the "test.proxy.json" string as a value of the environment variable named ENVIRONMENT.
If you want to pass arguments to npm scripts then you may need to use:
npm run test -- --proxy-config-file $ENVIRONMENT
Keep in mind that if you pass the argument to the npm script, it doesn't necessarily mean that it will be passed to other scripts that this script is executing. With environment variables it's the other way around - by default they should be passed from one script to the other but there is still no guarantee as the caller may decide what environment variables to pass, if any.
But it's hard to tell from your question what is your real problem here - the phrase "with no success" is too general to know what is the problem here.
Is there a way to measure the performance of an npm scripts similar to the way time-grunt works?
I am moving some of my critical build tasks to use npm instead of Grunt as writing my own build script is more flexible than using some of the Grunt plugins like grunt-browserify for example.
I have tried using console.time() but it finishes before the script is done, I assume because the methods are asynchronous. I also tried running the npm script as a Grunt task like this:
grunt.registerTask('collectify', function () {
grunt.util.spawn({
cmd: 'npm',
args: ['run', 'collectify:app']
});
});
But the output is different than if I run npm run collectify:app from the command line, perhaps because of pwd issues.
Coloured bars would be nice but at the very least I'd like to see the time in numbers.
Have you tried prepending the time command before your npm run command ?
So if your command is:
npm run collectify:app
It becomes:
time npm run collectify:app
And it'll output 3 lines e.g.
real 0m11.580s
user 0m7.400s
sys 0m1.304s
Let me know if it helps!
Your best option is likely pre[foo] and post[foo] scripts.
So if I have a NPM script called "foobar" then I can create a script called "preboofar" and "postfoobar" and they will be executed automatically before and after "foobar" is executed.
So in "pre" you can touch a file with a timestamp and in "post" you can read that file and calculate the difference.
I have installed this module globally however it fails with an error when run due to a dependency error however if I run my local copy by running the command
node ./bin/xl-json
the command works. I believe when running the npm i -g xl-json command that dependencies aren't being installed properly. Any ideas why one way works and the other doesn't?
The reason it doesn't work is because it is not [exactly] the same command you are running.
If you look at the error you see:
if (cptable === 'undefined') cptable = require('./dist/cpexcel');
^
ReferenceError: cptable is not defined
When you run the global command xl-json, the .cmd file (created by npm) takes precedence. iow. npm creates a file called xl-json.cmd which is a wrapper that invokes xl-json in the bin folder.
This file uses the strict option which the code should use but does not.
Try your command with --use-strict and you should see the same error message. i.e.:
node --use-strict ./bin/xl-json
I have installed an application using the command express new 'filename'. I have just learned that you can start an application using:
npm start
Thus far I have used:
node app.js
to start my server. Anyone know what the difference is between the two? Thanks.
From the man page, npm start:
runs a package's "start" script, if one was provided.
If no version is specified, then it starts the "active" version.
Admittedly, that description is completely unhelpful, and that's all it says. At least it's more documented than socket.io.
Anyhow, what really happens is that npm looks in your package.json file, and if you have something like
"scripts": { "start": "coffee server.coffee" }
then it will do that. If npm can't find your start script, it defaults to:
node server.js
The documentation has been updated. My answer has substantial changes vs the accepted answer: I wanted to reflect documentation is up-to-date, and accepted answer has a few broken links.
Also, I didn't understand when the accepted answer said "it defaults to node server.js". I think the documentation clarifies the default behavior:
npm-start
Start a package
Synopsis
npm start [-- <args>]
Description
This runs an arbitrary command specified in the package's "start"
property of its "scripts" object. If no "start" property is specified
on the "scripts" object, it will run node server.js.
In summary, running npm start could do one of two things:
npm start {command_name}: Run an arbitrary command (i.e. if such command is specified in the start property of package.json's scripts object)
npm start: Else if no start property exists (or no command_name is passed): Run node server.js, (which may not be appropriate, for example the OP doesn't have server.js; the OP runs nodeapp.js )
I said I would list only 2 items, but are other possibilities (i.e. error cases). For example, if there is no package.json in the directory where you run npm start, you may see an error: npm ERR! enoent ENOENT: no such file or directory, open '.\package.json'