-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop dependency on Q, use native promises #710
Conversation
raphinesse
commented
Sep 29, 2018
•
edited
Loading
edited
- Resolves Use native Promises instead of Q #681, part of Drop dependency on Q, use native promises cordova#7
- I took care to make a dedicated commit for every change that wasn't a simple search-and-replace
- Apart from the actual removal of Q this fixes a few problems that surfaced thereafter
Behavior of cordova/requirements should remain unchanged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got a handful of comments, but I think all of them are future cleanup. Lots of weird behaviour that you accidentally drew attention to, but none of which you caused 😛
@@ -32,21 +32,18 @@ var knownPlatforms = require('../platforms/platforms'); | |||
* requirements check results for each platform. | |||
*/ | |||
module.exports = function check_reqs (platforms) { | |||
return Q().then(function () { | |||
var platforms = cordova_util.preProcessOptions(platforms).platforms; // eslint-disable-line no-use-before-define | |||
return Promise.resolve().then(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to wrap this in a promise, given that the inner block is already returning Promise.all
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a poor-man's Promise.try
.
In a nutshell: It ensures that this function always returns a Promise
. Even if anything we do would cause an error to be thrown, thanks to the wrapping it will be converted to a rejection instead of bubbling up the call stack.
In this case, suppose preProcessOptions(platforms)
would return undefined
. Then our accessing the result's platforms
property would result in an error to be thrown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I actually just left a comment on the cordova-fetch PR referencing Promise.try
. Since we seem to use this pattern frequently, maybe it makes sense to depend on something like https://github.com/tc39/proposal-promise-try (although that isn't published to npm 😞)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sorry for doing a ELI5 here. And I agree with you regarding the lib: I just suggested the exact same thing in the cordova-fetch PR 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OTOH, as soon as Node 6 EOLs, we get a nicer Promise.try
in the form of async
functions. So it might not be worth the trouble beginning to micro-optimize here.
@@ -111,7 +110,7 @@ function installPlatformsFromConfigXML (platforms, opts) { | |||
|
|||
// No platforms to restore from either config.xml or package.json. | |||
if (comboArray.length <= 0) { | |||
return Q('No platforms found in config.xml or package.json. Nothing to restore'); | |||
return Promise.resolve('No platforms found in config.xml or package.json. Nothing to restore'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern seems awkward to me, since it feels more like these should be emitted as logging events.
Does this function always resolve with a log message string, or with an array of the added platforms? Currently it does both and it would be better in terms of API to be consistent with the resolved value type.
@@ -45,7 +44,7 @@ function HooksRunner (projectRoot) { | |||
*/ | |||
HooksRunner.prototype.fire = function fire (hook, opts) { | |||
if (isHookDisabled(opts, hook)) { | |||
return Q('hook ' + hook + ' is disabled.'); | |||
return Promise.resolve('hook ' + hook + ' is disabled.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method resolves with a string, or throws an error (not rejects), or resolves with the result of running scripts, or rejects with error from running scripts? 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds about right. Powerful stuff 😁
I have some improvements for HooksRunner
in the making anyway. I'll try to include a cleanup of this function's behavior too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for merging, and we can make note of those other cleanup tasks somewhere. Some of them are probably breaking API, so we'd want to tackle them as part of a major bump (perhaps the next next major?)
Could you take care of that please @dpogue? 🙏 Thanks a lot for the review! 🙇♂️ |
Along with this change, docs for Hooks: Sample Usage should be updated |
@piotr-cz Agreed. Actually the whole page is quite dated. I will try to fix that in the next few days. |