A development dependency supports work such as live reloading or testing but is not needed to run the microservice in production. Install one with `npm install --save-dev <package>`; npm records it under `devDependencies` in `package.json`. A normal `npm install` includes it, while `npm install --omit=dev` leaves it out of a production installation. section 2.6.7 section 2.6.8
Live reloading with nodemon
Run `npm install --save-dev nodemon`, then use `npm run start:dev` to restart the service automatically when code changes. Keep the ordinary `npm start` script for running the service without nodemon. section 2.6.8
Listing 2.7 Adding a start script for development
{
"name": "example-3",
"version": "1.0.0",
"description": "",
"main": "src/index.js",
"scripts": {
"start": "node src/index.js", #1
"start:dev": "nodemon src/index.js" #2
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"express": "^5.0.0-beta.1"
},
"devDependencies": { #3
"nodemon": "^2.0.18" #4
}
}
The package.json listing shows nodemon under `devDependencies`, separate from the production dependency Express, with distinct start and development scripts. section 2.6.8
Use the same distinction for tests: Jest is a development dependency because it runs in development or testing, not in the production service. Judge a package by whether the running service needs it, not merely by whether tests use it. The MongoDB library is also used by test fixtures, but it remains a production dependency because the microservice uses it in production. section 9.5.2 section 9.7.3
This split carries into containers: a production Dockerfile installs only production dependencies with `npm ci --omit=dev`, while a development Dockerfile installs all dependencies before running the development script. Leaving unnecessary packages out of production avoids bloat and reduces potential security exposure. section 5.5.3 section 2.6.8
