Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

alcuadrado
Copy link

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 a Suite.

Alternate Designs

v6.0.0 introduced a similar feature, but it printed a deprecation warning if a Suite returned any value other than undefined, 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 Promises 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 with async 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 Suites 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)

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Sep 13, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@juergba
Copy link
Contributor

juergba commented Sep 20, 2022

@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".

@juergba
Copy link
Contributor

juergba commented Sep 20, 2022

@wdavidw are you still working with Mocha and CoffeeScript?
I don't understand your comment in #3744:

One way to please everyone is to detect if the return value found in the suite is not the same as the one returned by it.

Does this PR work with CoffeeScript? What happens if the last it in a describe returns a Promise?

@alcuadrado
Copy link
Author

I certainly don't agree with the type of warning (deprecation), since we have never offered a feature "asynchronous describe".

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.

@juergba juergba added area: usability concerning user experience or interface semver-minor implementation requires increase of "minor" version number; "features" labels Sep 27, 2022
@juergba juergba added this to the next milestone Sep 27, 2022
@coveralls
Copy link

Coverage Status

Coverage increased (+0.003%) to 94.329% when pulling 9b338f6 on alcuadrado:issue/4920 into 41567df on mochajs:master.

Copy link
Contributor

@juergba juergba left a 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.

lib/interfaces/common.js Show resolved Hide resolved
lib/interfaces/common.js Outdated Show resolved Hide resolved
@juergba juergba removed this from the next milestone Oct 9, 2022
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a 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?

lib/interfaces/common.js Outdated Show resolved Hide resolved
@JoshuaKGoldberg JoshuaKGoldberg added the status: waiting for author waiting on response from OP - more information needed label Mar 4, 2024
@JoshuaKGoldberg JoshuaKGoldberg changed the title Deprecation message when an async callback is used in a Suite feat: deprecation message when an async callback is used in a Suite Mar 4, 2024
@JoshuaKGoldberg
Copy link
Member

👋 ping @alcuadrado, is this still something you have time for?

@JoshuaKGoldberg JoshuaKGoldberg added the stale this has been inactive for a while... label Jul 2, 2024
@alcuadrado
Copy link
Author

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.

@alcuadrado
Copy link
Author

alcuadrado commented Jul 4, 2024

I rebased against main, added the "[mocha]" tag to the deprecation message, but I can't get the tests to run, not even in main.

I'm using [email protected], [email protected]. Maybe using a devcontainer is bringing problems?

@alcuadrado
Copy link
Author

Sorry, maybe I was wrong. I was getting messages like this one

/tmp/mocha-9cPS1H/test.js:7
    done((;
          ^

SyntaxError: Unexpected token ';'
    at wrapSafe (node:internal/modules/cjs/loader:1281:20)
    at Module._compile (node:internal/modules/cjs/loader:1321:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
    at Module.load (node:internal/modules/cjs/loader:1208:32)
    at Module._load (node:internal/modules/cjs/loader:1024:12)
    at Module.require (node:internal/modules/cjs/loader:1233:19)
    at require (node:internal/modules/helpers:179:18)
    at /workspaces/mocha/mocha/lib/mocha.js:414:36
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/workspaces/mocha/mocha/lib/mocha.js:411:14)
    at Mocha.run (/workspaces/mocha/mocha/lib/mocha.js:972:10)
    at Object.run (/workspaces/mocha/mocha/lib/cli/watch-run.js:263:22)
    at FSWatcher.<anonymous> (/workspaces/mocha/mocha/lib/cli/watch-run.js:184:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

and tons of

⚠ [mocha] cleaning up, please wait...
ℹ [mocha] waiting for changes...
ℹ [mocha] waiting for changes...
ℹ [mocha] waiting for changes...
⚠ [mocha] cleaning up, please wait...
ℹ [mocha] waiting for changes...
⚠ [mocha] cleaning up, please wait...
ℹ [mocha] waiting for changes...
ℹ [mocha] waiting for changes...

yet the tests seem to pass.

@alcuadrado
Copy link
Author

Regarding checking against !== undefined. While I like the idea, I haven't implemented that yet, as that's a bigger product change, and I don't feel in a position to make that decision.

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.

@JoshuaKGoldberg
Copy link
Member

can't get the tests to run

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.

@alcuadrado
Copy link
Author

alcuadrado commented Jul 8, 2024

can't get the tests to run

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

@JoshuaKGoldberg
Copy link
Member

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.

@alcuadrado
Copy link
Author

Anything I can do to help move this forward?

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Aug 3, 2024

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?

@JoshuaKGoldberg JoshuaKGoldberg added status: in triage a maintainer should (re-)triage (review) this issue status: needs review a maintainer should (re-)review this pull request and removed status: waiting for author waiting on response from OP - more information needed stale this has been inactive for a while... status: in triage a maintainer should (re-)triage (review) this issue labels Aug 3, 2024
Co-authored-by: Josh Goldberg ✨ <[email protected]>
@alcuadrado
Copy link
Author

Edit: and, https://github.com/mochajs/mocha/pull/4921/files#r1511274453 is still in discussion, I believe?

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. ' +
Copy link
Member

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 ' +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asynchronous

...and this too.

Copy link
Member

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?

Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a 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 Promises, the messaging will need to be updated.

@JoshuaKGoldberg JoshuaKGoldberg added status: waiting for author waiting on response from OP - more information needed and removed status: needs review a maintainer should (re-)review this pull request labels Aug 28, 2024
@JoshuaKGoldberg
Copy link
Member

👋 Ping @alcuadrado, is this still something you have energy & time for?

@JoshuaKGoldberg JoshuaKGoldberg added the stale this has been inactive for a while... label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: usability concerning user experience or interface semver-minor implementation requires increase of "minor" version number; "features" stale this has been inactive for a while... status: waiting for author waiting on response from OP - more information needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

🚀 Feature: Fatal error when async functions are passed to describe and context
5 participants