mcollina / make-promises-safe Goto Github PK
View Code? Open in Web Editor NEWA node.js module to make the use of promises safe
License: MIT License
A node.js module to make the use of promises safe
License: MIT License
According to Node.js recommendation:
Calling process.exit() will force the process to exit as quickly as possible even if there are still asynchronous operations pending that have not yet completed fully, including I/O operations to process.stdout and process.stderr.
In most situations, it is not actually necessary to call process.exit() explicitly. The Node.js process will exit on its own if there is no additional work pending in the event loop. The process.exitCode property can be set to tell the process which exit code to use when the process exits gracefully..
if you think this is necessary I can create a PR.
is there possible scenarios where the exit code wouldn't be 1
(depending on the nature of the error in the rejection?)
If so, how do we handle this?
Hi,
I'm working on a security tool and i'v discovered that some files has been published in the tarball:
So because you'r using http in example.js my tool put a flag (the little planet). If there is no reason to publish these files, can you consider removing them for the next release ?
(to be added to the package.json)
{
"files": ["make-promises-safe.js"]
}
Thanks for your time and work.
Best Regards,
Thomas
๐ I'll just leave this here.
Should we support an option to generate a core dump in these situation?
Just so I understand correctly... since the the default mode for unhandledRejection
is changed to throw
, is it correct to say that this package is now no longer needed for newer versions?
Currently the listener is only attached if there's no other listener. I personally believe it should always be attached no matter if other listeners already exist or not as the user actively opted in.
It would also be good to add a warning in the docs that this library should not be used by any "regular" module but only by the users that write the used application.
The README.md
for this project currently contains the following warning
It is important that this module is only used in top-level program code, not in reusable modules!
but does not (or does it?!) really explain why it's important to only use this module in top level program code.
Is this simply a best practice warning against surprising users by changing the behavior of their un-handled promise rejections via a third party module? Or are there other, subtle problems with defining a process level unhandledRejection
handler via reusable module code?
I have seen the codebase and commits in #8 mentioning that it includes multipleResolves
event but in the version 2 which is available in NPM, it does not include the event handling for multipleResolves
. I can verify it by visiting the unpkg url for the package https://unpkg.com/[email protected]/make-promises-safe.js
Please confirm if it's not yet released. Thanks.
It would be nice to see that mentioned in readme.
See docs about flag here https://nodejs.org/docs/latest-v12.x/api/cli.html#cli_unhandled_rejections_mode
Any usage of Promise.race()
with more than 1 resolving promise triggers an exit!!
require('make-promises-safe');
Promise.race([Promise.resolve('a'), Promise.resolve('b')]);
setImmediate(() => console.log('done'));
Result:
resolve Promise { 'a' } b
Version: 3.0.0
Node: v10.13.0
@mcollina Nice work on this, thanks!
Sorry to make an issue just to ask a question, let me know if i should have asked some other way.
Anyway, I was wondering when this deprecation will be enforced? i.e. when will uncaught promise rejections actually kill the process?
Nightly builds don't seem to be, even for v9.
nvm use 9 && node -e 'Promise.reject()'
Now using node v9.0.0-nightly20170620d2913384aa (npm v5.0.3)
(node:70293) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): undefined
(node:70293) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
The event exists since node 10.12
@BridgeAR
Suggestion for a sequel module: make-promises-debuggable
Might not be possible, but making a process crash when there's a syntax error
in a promise that already has a catch handler would be helpful for development experience
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.