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'
Related
I would like to know more about how NPM scripts work.
For example:
package.json
"scripts": {
"build": "set NODE_ENV=production&& webpack --config webpack.config.js",
}
When I execute npm run build:
What happens? I know a Node process will be initiated somewhere and webpack binary file will be called, right? But what are the steps before that? Does that depend whether I'm on Windows, Linux, PowerShell or Git bash? How does that process relate to the OS and the CMD/CLI that is being used?
The npm source code helpfully has the whole run-script functionality separated into its own module and repository so you can review the source code if the documentation does not answer your questions.
Speaking of your questions:
I know a Node process will be initiated somewhere and webpack binary file will be called, right?
The webpack executable will be run. And since webpack is a Node.js script, it will be run with node.
If, however, your "build" value consisted of shell/CLI commands, those commands would be run. Node.js is not necessarily invoked.
But what are the steps before that?
The "steps before that" include certain lifecycle scripts that might also be defined. In particular, if there is a "prebuild" script, it will run before the "build" script.
Does that depend whether I'm on Windows, Linux, PowerShell or Git bash? How does that process relate to the OS and the CMD/CLI that is being used?
npm (and node) make efforts to make Windows and Linux experiences comparable. Differences occur for sure, but without more details, I'm not sure I'd want to speculate about what specifics might be of interest to you beyond that.
Powershell and GitBash: Again, npm will make efforts to smooth out differences, but I'm sure they come up. One thing to be aware of is that your PATH (and other environment variables) might be set differently and that may affect behavior. (It may especially impact which version of node gets executed, if you have more than one version installed.)
I am not a Windows expert, but I have seen a lot of npm scripts that assume a UNIX-like environment. So, if given the choice and all else being equal (which it never is), a bash-like environment is probably going to be a bit smoother.
The answer I was looking for was something like this:
When you call npm run, npm will initiate a shell to run those instructions.
And which shell npm will use is defined in your npm settings.
You can see your npm config by running:
>>> npm config ls
In the example above, npm will run the script on git-bash.
You can change the npm shell by calling:
npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"
Would it be possible to get an explanation of how npm start works?
I have an Angular 2 application written in Typescript. I enter npm start in the console and this both compiles and launches the application using Node's built in web server.
However what is the starting point for this? Which files does the npm start command read in order to compile and start the application? Also why do I use npm start and not e.g. node start? I understood that NPM was just the package manager for node itself.
What I understand so far:
I have a tsconfig.js file which tells the TypeScript compiler what to do.
I have a packages.json file which tells node which packages to download.
Where do the following files fit into this:
main.ts
app/app.module.ts - which I understand is the starting point for my application.
How do all of these components fit together to form the application?
npm start is just an alias for npm run start, which runs whatever command is in scripts.start in your package.json.
It neither knows nor cares about TypeScript, or Angular, or anything like that - it just executes whatever script it's given on the command line.
So I have have been using NPM as a simple build tool for a few years where I can assume that every CLI tool installed through package.json is available in the PATH, as NPM adds the ./node_modules/.bin path to it.
But as I was about to write a small Node script to do some house cleanup chores I got a bit wary if NPM actually has the node executable in the PATH it gives to users. This might seems stupid, as all the scripts in ./node_modules/.bin rely on node being there for the wrapper scripts on Unix to be able to find it, but I thought there might be some magic going on in Windows. Perhaps they use some other magic of their own. Or something. Does not matter, really, I just want to be able to assert:
Is the node executable always on the PATH given to npm scripts by NPM? On all platforms? And is it always the same Node as NPM runs on?
This might seem too basic to almost be asked, but better safe than sorry.
Note: not a definitive answer, but too lengthy for a comment
If you look at the documentation on default values that are set up for scripts:
npm will default some script values based on package contents.
"start": "node server.js":
If there is a server.js file in the root of your package, then npm
will default the start command to node server.js.
Although this isn't a definitive answer to your question, npm uses node as a default in case there's no npm start defined. This is a clear indicator npm relies on node to be present under all circumstances.
On Windows, you can safely make the assumption that npm requires node to be in the PATH, or in the same folder as npm. This is from npm.cmd (the script that is called when you type npm):
SET "NODE_EXE=%~dp0\node.exe"
IF NOT EXIST "%NODE_EXE%" (
SET "NODE_EXE=node"
)
I'm using NodeJs v0.10.29 and Express, among other things, for a project I'm working on.
The thing is that since I updated NodeJs to version 0.10.29 (from 0.10.28) a very annoyning thing is happening when I start the Express server up.
A very common issue was to look in the log generated by Express to see what was happening in case of error but now it's not possible without killing the server. Terminal scroll is locked (it can't go up...) because some kind of "helix" is spining round during "idle time" (| / - | \ | ....) at the end of the log.
Is it possible to avoid this without going back to 0.10.28?
Thanks
León
It is not node doing this. It's probably one of the modules you are loading from npm, but probably not express either. You need to investigate with process of elimination to find what piece of code is doing that. Most likely the last time you ran "npm install", you got a newer version of some module and the new version does this but the old didn't.
I've found out who's the one: npm is guilty of this thing.
I used to type
$ npm start
which is defined as
"scripts": {
"start": "nodemon app.js"
}
If I use
$ nodemon app.js
log behaves as it used to.
npm added this "helix" at the end of the log. It can be seen when you use, for example:
$ npm install my-favourite-package
Version of npm is 1.4.14
Inside my composer.json, there's a postinstall hook setup like the following:
"scripts" : {
"dist" : "node dist; node_modules/.bin/doccoh src/package.js",
"postinstall" : "node_modules/.bin/grunt setup || true; node_modules/.bin/bower install",
"start" : "node server.js"
}
Whenever I run it (on Win from Git/Gnu Bash CLI), I end with
command not found. either the command was written wrong or couldn't be found
Rough translation from German CLI error.
I tried splitting it into multiple ;/semicolon separated parts and first cd into that directory, but it simply ends up with the same error message. Replacing the whole postinstall command set with a simple ls does work. So I guess the problem might be the semicolon separation or a wrong usage of commands. But overall I got no idea what's wrong.
Note: I got grunt-cli version 0.1.9 and grunt version 0.4.1 installed globally.
I'm a bit late to answer, but if you're on Windows, multiple commands on a single line are executed with the use of &&
postinstall: "some command && some other -c"
I ran into this looking for something and thought this may help other people. I have found it easier to move to postinstall.js files as things get a little complicated. This makes it easier to deal with moving forward.