-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
feat: deprecation message when an async callback is used in a Suite #4921
Conversation
test/integration/fixtures/suite/suite-async-callback.fixture.js
Outdated
Show resolved
Hide resolved
@alcuadrado thank you, I will review within the next few days. I certainly don't agree with the type of warning (deprecation), since we have never offered a feature "asynchronous describe". |
@wdavidw are you still working with Mocha and CoffeeScript?
Does this PR work with CoffeeScript? What happens if the last |
I copied this from the previous implementation. I guess the reasoning behind that is that some users are getting away with async callbacks now, and a fatal error can be seen as breaking by them. |
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.
@alcuadrado I'm quite sure this change will trigger deprecation warnings to CoffeeScript users in certain circumstances. Anyway this PR is much softer than the original proposal and there is a work-around by adding a return
statement to the suites. Otherwise they will have to live with a single deprecation warning.
Could you please do some manual browser testing, since we don't run our integration tests on browsers. And confirm the outcome, thank you.
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.
Looks good as a general re-implementation of #3550! Heck, I even think we should go further and fully re-implement to check all truthy values - not just Promises.
Thoughts?
👋 ping @alcuadrado, is this still something you have time for? |
Hey, sorry I dropped this. I can take a look over the weekend. iirc I dropped this as I don't have the necessary setup to run the browser tests locally. |
Co-authored-by: Franco Victorio <victorio.franco@gmail.com>
I rebased against I'm using |
Sorry, maybe I was wrong. I was getting messages like this one
and tons of
yet the tests seem to pass. |
Regarding checking against I'll gladly implement that and update the tests if that is a change that you (as in the maintainers) are willing to accept it. |
Do you mean for the GitHub PR? If so: we have to click an Approve and run every time you push a new commit. I've done that just now. |
No, sorry, the error messages during the test run confused me. Should I do anything about the netlify deploy preview failure? I don't have permission to see the details |
No, that's just hanging around. ou don't have to worry about that. |
Anything I can do to help move this forward? |
Oh, sorry, I'd misinterpreted your messages and didn't realize this was ready for re-review! Thanks for the ping. Added back to our queue of PRs to review. Edit: and, https://github.com/mochajs/mocha/pull/4921/files#r1511274453 is still in discussion, I believe? |
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Yes, I think so. I'm not familiar with the decision process for things like this within mocha. But anyway, I committed your suggestion, assuming that this will probably/hopefully be accepted. |
errors.deprecate( | ||
'[mocha] Suite "' + | ||
suite.fullTitle() + | ||
'" returned a Promise. ' + |
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.
A Promise
Now that it's !== undefined
above, this'll need to be updated.
'[mocha] Suite "' + | ||
suite.fullTitle() + | ||
'" returned a Promise. ' + | ||
'Asynchronous suites are not supported, use a ' + |
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.
Asynchronous
...and this 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.
[Testing] This has a very clean + good unit test for the async (returning a Promise) case. But since the common.js
change now is the more general !== undefined
check, could you also add a unit test for a non-undefined
, non-Promise
value?
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.
Progress! 🚀
Now that the check is for any non-undefined
value, rather than just Promise
s, the messaging will need to be updated.
👋 Ping @alcuadrado, is this still something you have energy & time for? |
Closing out to free up the backing issue. @alcuadrado if you end up seeing this and having time again, no worries, feel free to re-open the PR or send a new one. If anybody else sees this message and there isn't a new PR, feel free to send one yourself. Just make sure to add a co-author attribution if it takes code from this PR. Cheers all! 🤎 |
I'm sending this PR after having proposed this feature in #4920, getting some positive reactions, and researching the history of a similar feature that was removed
Description of the Change
This PR introduces a change that prints a depreciation message if an
async
callback is used in aSuite
.Alternate Designs
v6.0.0
introduced a similar feature, but it printed a deprecation warning if aSuite
returned any value other thanundefined
, which was not practical in some cases (see #3744), so it was removed.This PR is a specialization of that feature that prints a warning when
Promise
s are returned instead.Also, I originally proposed throwing a fatal error, but that would be a breaking change, so I changed it to a deprecation message. This same criteria was applied to the previous version of this feature.
Why should this be in core?
I don't think this can be implemented outside of core.
As this PR benefits users who don't have a clear understanding of how a
Suite
works, taking this functionality out of core will have much lower, as there wouldn't be a clear path for those users to discover how to enable it.Benefits
Many users don't realize that Suite's callbacks can't be
async
. In some cases, they get away withasync
callbacks, which further increases the confusion.This PR is intended to clarify that confusion.
Possible Drawbacks
I don't think this version of the feature has any serious drawback.
It may print deprecation warnings for people who were using async callbacks in
Suite
s with some success (and a ton of luck), but those users were already at high risk of their code breaking. This change is intended to help them.Applicable issues
Fixes #4920
semver-patch
(copying the semver criteria of #3550)