limulus / call-me-maybe Goto Github PK

will this code from pongstr:

'use strict';

var next = function (f) {
setTimeout(f, 0);
};

module.exports = function maybe(cb, promise) {
if (cb) {
promise.then(
function (result) {
next(function () {
cb(null, result);
});
},
function (err) {
next(function () {
cb(err);
});
}
);
return undefined;
} else {
return promise;
}
};

will be merged anytime in this repository ?
i tried it and then it works, but if i want to use it in a docker container it always loads the current index, which causes me the global undefined error.

kind regards :)

Hello,

It would be great if the module could detect if bluebird promises are used instead of native ones. Currently returning 'undefined' yields a warning. null should be returned instead.

https://github.com/petkaantonov/bluebird/blob/master/docs/docs/warning-explanations.md#warning-a-promise-was-created-in-a-handler-but-was-not-returned-from-it

Seems like by checking the version field of the Promise object is enough to determine if it's a native one or not. petkaantonov/bluebird#1237

Testing libraries that help developers mock timers will globally replace setTimeout and setImmediate. We only use these for getting an new call stack, so per taylorhakes/promise-polyfill#15, it is justified to keep these from getting replaced.

The change should be a simple addition of var setTimeout = setTimeout, plus a comment to explain why we are doing it. Our usage of setImmediate happens to already be protected, but a comment that covers that should be used as well.

The test is creating a dummy promise, which it then would be entirely disregarded as the test is checking that only the first resolve operation actually fulfills.

This is the actual line: https://github.com/limulus/call-me-maybe/blob/master/test/maybeTest.js#L134

And here is the text output:

    ✓ should allow errors thrown in the callback to be uncaught
(node:13030) UnhandledPromiseRejectionWarning: Error: bah
    at call-me-maybe/test/maybeTest.js:134:29
    at call-me-maybe/index.js:11:28
    at process._tickCallback (internal/process/next_tick.js:61:11)
(node:13030) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:13030) [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.

Such text output looks misleading as..

1. it shows the test as correctly passed
2. it shows that there is an underlying issue, as warning

More so, this test will start failing once nodejs changes the warning into an error.

More info about the deprecation:

https://nodejs.org/api/deprecations.html#deprecations_dep0018_unhandled_promise_rejections

Solution:

The test could simple resolve a dummy value, like:

return Promise.resolve("bah")

Please let me know if this is worth a PR, I'm more than glad to submit one.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀