How to use nodemon in npm scripts to build and start scripts?

Question

"scripts": {
  "build": "babel src -d lib",
  "start": "node --use_strict ./lib/index.js",
  "watch": "nodemon lib/index.js --exec npm run build"
}

Using the command npm run watch results in the following wrong command being run: [nodemon] starting "npm lib/index.js run build"

How would I write a nodemon command that, on reload, transpiles the code using babel and reloads the code?

Solution 1

You could simply run your code with babel-node to avoid explicit transpiling.

$ nodemon lib/index.js --exec babel-node --presets=es2015,stage-2

It seems like this is the recommended way to use nodemon with babel.

Please note, running --exec could have unintended side effects when running your development environment remotely of your localhost

Solution 2

  "scripts": {
    "build": "babel src -d lib",
    "start": "node --use_strict ./lib/index.js",
    "watch": "nodemon --exec \"npm run build && node lib/index.js\" -e js --ignore lib/"
  }

Then run npm run watch. After this, nodemon will rebuild the project and then restart the server every time source code(.js files) is modified.

--exec specifies what non-node scripts (also works for node scripts as above node lib/index.js) you want nodemon to execute when there is a file change.

-e specifies what file extensions you want nodemon to watch.

--ignore specifies the files/directories you want nodemon to ignore. This option is essential to solve this problem because if you do not specify to ignore this lib/ folder, nodemon will restart infinitely as the compiled files in lib/ are also .js files.

Solution 3

You can have two nodemons, one to transpile and the other to run your code. In package.json you can do something like this:

"scripts": {
    "serve": "nodemon --watch dist/ ./dist/index.js",
    "build" : "nodemon --watch src/ --exec babel ./src --out-dir ./dist --source-maps --copy-files"
  },

Solution 4

There is an option to build files with Babel in "watch" mode, let Nodemon monitor just the "build" folder and restart the app upon changes to the compiled output.

{
  "name": "app",
  "version": "1.0.0",
  "private": true,
  "dependencies": {},
  "devDependencies": {
    "@babel/cli": "^7.6.0",
    "@babel/core": "^7.6.0",
    "@babel/preset-env": "^7.6.0",
    "nodemon": "^1.19.2"
  },
  "scripts": {
    "build": "babel src --out-dir build --source-maps=inline --verbose",
    "start": "yarn build --watch & sleep 1 && nodemon --watch build build/index.js"
  }
}

This example is taken from GraphQL API Examples repository on GitHub.

Solution 5

A better option would be to not use a global install but instead use the package installed locally. This will also help for automation builds that might be setup the same as your local machine per 12 factor app design.

"scripts": {
"watch": "node ./node_modules/nodemon/bin/nodemon.js"

}

View more solutions

Comments

[Connorelsea]

What package do I need to install to run babel-node? NPM says babel-node is not in the repository and even though I have babel-cli installed via npm already, running your given command says babel-node is not available.

[Роман Парадеев]

babel-cli is the right one. You should either install it globally or change the execution path to ./node_modules/.bin/babel-node.

[Connorelsea]

I installed babel-cli globally and locally within the project and am getting the following error. i.imgur.com/UwXaPTz.jpg

[Роман Парадеев]

You are trying to run babel-node as an npm script, like it is declared in package.json. You can find a working example here.

[Роман Парадеев]

Ouch, that was my mistake, sorry. I've fixed the answer.

[Роман Парадеев]

Yay! Glad it helped.

[ankit suthar]

can you please explain it more.

[David J]

Instead of using nodemon globally in the cli, use the code above where you can call the local installed package using --save or --save-dev, node ./node_modules/nodemon/bin/nodemon.js either in a npm script or cli cmd. Also add any arguments you my need to pass. Basically instead of calling it using a global identifier you are calling in directly from the solution structure. This helps your team as well as they will all be using the same version where a if the package is installed globally over a period of time on multiple workstations the versions will most likely be different.