Can I hide or shut up "npm ERR!" output when using npm run script?

Question

I use npm run script to perform tasks such as build and test.

For example, my package.json looks like this:

 { "name": "fulfillment-service", "version": "1.0.0", "description": "Endpoint for CRUD operations on fulfillment status", "main": "src/server.js", "scripts": { "build": "tsc", "test": "tape tests/*.js" }, "dependencies": {}, "devDependencies": { "typescript": "^1.8.10" } } 

When I launched npm run build and it will succeed, the output will be as follows:

 > fulfillment-service@1.0.0 build d:\code\fulfillment-service > tsc 

When I run npm run build and it fails, the output is as follows:

 > fulfillment-service@1.0.0 build d:\code\fulfillment-service > tsc src/server.ts(51,81): error TS2339: Property 'connection' does not exist on type 'IncomingMessage'. npm ERR! Windows_NT 10.0.10586 npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build" npm ERR! node v6.2.1 npm ERR! npm v3.9.3 npm ERR! code ELIFECYCLE npm ERR! fulfillment-service@1.0.0 build: `tsc` npm ERR! Exit status 2 npm ERR! npm ERR! Failed at the fulfillment-service@1.0.0 build script 'tsc'. npm ERR! Make sure you have the latest version of node.js and npm installed. npm ERR! If you do, this is most likely a problem with the fulfillment-service package, npm ERR! not with npm itself. npm ERR! Tell the author that this fails on your system: npm ERR! tsc npm ERR! You can get information on how to open an issue for this project with: npm ERR! npm bugs fulfillment-service npm ERR! Or if that isn't available, you can get their info via: npm ERR! npm owner ls fulfillment-service npm ERR! There is likely additional logging output above. npm ERR! Please include the following file with any support request: npm ERR! d:\code\fulfillment-service\npm-debug.log 

This fills the entire console with useless information, and I need to scroll up to see why it failed.

Do I need to hide / freeze lines starting with npm ERR! during development?

Answer 1

You should use npm run build --silent .

This is not documented in npm help , npm help run or something else obvious, but with some searching on the Internet you can find out that it is obviously documented in npm help 7 config . You can also use the loglevel option in .npmrc .

The --silent (short: -s ) -s suppresses:

• The two lines starting with > say which command you are using.
• npm ERR! .
• Creating npm-debug.log if there is an error.

---

Note. Using npm scripts to run other npm scripts may require using --silent more than once. Example package.json :

 { . . . "scripts": { "compile": "tsc", "minify": "uglifyjs --some --options", "build": "npm run compile && npm run minify" } } 

If you do npm run build and TypeScript finds an error, you will get npm ERR! from both scenarios. To suppress them, you must change the script construct to npm run compile --silent && npm run minify and run it with npm run build --silent .

Answer 2

There is a problem with npm: run-scripts are too noisy when used in development # 8821 (also mentioned in the comment above)

In discussing this issue, several people mentioned creating an alias, for example. npr (using the --silent option gcampbell describes in its answer). Although --silent may hide some problems like npm, such as malformed package.json, at the moment this seems like a reasonable solution.

 alias npr='npm run --silent $*' 

Another thing from that discussion that might be interesting, although this is another tool, is yarn , which is described on a facebook blog post .

Answer 3

If you created your own script and it returns with an NPM error (even if there is no error), add process.exitCode = 0; at the end of the script to avoid an error.

Answer 4

As others noted, the problem with --silent is that you are losing everything . Another way that seems to work in most cases:

 npm run something 2>/dev/null 

If one of the executables you run is written to stderr, then this will be suppressed. But most of the materials node writes to stdout, so this should not be a problem.

Of course, this will only work in a shell environment that supports output redirection.