diff options
author | isaacs <i@izs.me> | 2019-08-02 02:48:19 +0300 |
---|---|---|
committer | isaacs <i@izs.me> | 2019-08-02 03:10:01 +0300 |
commit | 5b389022652abeb0e1c278a152550eb95bc6c452 (patch) | |
tree | 911023dae676b7ad2453dd8f3f0357497afd9199 /bin | |
parent | 99edd49e77ab8d41a6b2613f7399c0f9b6fb1675 (diff) |
Handle unhandledRejections, help with cache eacces
Suggested by @godmar in
https://npm.community/t/npm-err-cb-never-called-permission-denied/9167/5
Incidentally, this turned up that we're catching uncaughtExceptions in
the main npm functions, but not unhandledRejections!
Tracing this through, it seems like node-fetch-npm's use of cacache is
particularly brittle. Any throw that comes from cacache is not caught
properly, since node-fetch-npm is all streams and callbacks. The naive
approach (just adding a catch and failing the callback) doesn't work,
because then make-fetch-happen and npm-registry-fetch interpret the
failure as an invalid response, when actually it was a local cache
error.
So, a bit more love and polish is definitely still needed in the
guts of npm's fetching and caching code paths. In the meantime, though,
handling any unhandledRejection at the top level prevents at least the
worst and most useless type of error message.
PR-URL: https://github.com/npm/cli/pull/227
Credit: @isaacs
Close: #227
Reviewed-by: @isaacs
Diffstat (limited to 'bin')
-rwxr-xr-x | bin/npm-cli.js | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/bin/npm-cli.js b/bin/npm-cli.js index 705aa472e..93eddc7a3 100755 --- a/bin/npm-cli.js +++ b/bin/npm-cli.js @@ -62,6 +62,7 @@ log.info('using', 'node@%s', process.version) process.on('uncaughtException', errorHandler) + process.on('unhandledRejection', errorHandler) if (conf.usage && npm.command !== 'help') { npm.argv.unshift(npm.command) |