Search code examples
node.jsexpressnpmnpm-run

What are the differences between the processes run by npm command:

Recently I made a simple API server using node.js+express. And the script below is a part of my package.json file I use to run with npm commands.

"scripts": {
  ...
  "release": "cross-env NODE_ENV=production MODE=release node server/app.js",
}

After I starts the server with npm run release, I can see multiple processes such as below are running on my Linux server.

/bin/sh /api/node_modules/.bin/cross-env NODE_ENV=development MODE=test node server/app.js
node /api/node_modules/.bin/../cross-env/bin/cross-env.js NODE_ENV=development MODE=test node server/app.js
node server/app.js

I read a related documentation here, but I don't understand what actually happens in background.

  1. What is the order of creating processes? npm => /bin/sh => node /api/.. => node server/app.js ?
  2. What does each process do? All three processes are necessary to run my server?
  3. If I wants to kill the server with pid, which process id should I use?
Solution

  • What is the order of creating processes? npm => /bin/sh => node /api/.. => node server/app.js ?

    What does each process do? All three processes are necessary to run my server?

    Well, the flow is like this:

    • NPM is spawned (you run it) inside your shell, npm itself runs with NPX in order to set the local path.
    • Your npm script spawns a process from a package called cross-env for cross-OS environment variable setting.
    • That process in turn spawns Node.js (after setting the environment variables)

    That's why you see 3 processes. After your server itself run - only the actual server process is needed to run the server.

    If I wants to kill the server with pid, which process id should I use?

    This one: node server/app.js - since that's your actual server, the others are just "utility processes" (one for the npm script you ran and the other for the environment variables").

    It's worth mentioning that in general - servers are run inside containers or other orchestrators/managers that have built-in logic for restarting/killing the process. Typically the orchestrator sends SIGTERM to the process.