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

Implement no-async-describe rule #188

Merged
merged 5 commits into from
Feb 13, 2019

Conversation

papandreou
Copy link
Contributor

@papandreou papandreou commented Feb 5, 2019

I've seen describe('my test', async function () { ... }) cause subtle problems, so I think it makes sense to add a rule for it.

);
}

function containsDirectAwait(node) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know if this could be implemented with a funky ramda function that looks for a nested object with a type of AwaitExpression not contained within one with a type of FunctionExpression etc. -- but I have to admit that I'm not really familiar with that.

Copy link
Owner

Choose a reason for hiding this comment

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

Don’t worry, it’s not a requirement to write funky ramda expressions 😉.

Example:

```js
describe(async function () {
Copy link
Owner

Choose a reason for hiding this comment

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

Is this a valid example? Doesn’t describe require a string as the first argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, it isn't 🙄

Fixed in 7c9b6dc

The following patterns are considered problems, whether or not the function uses `await`:

```js
describe'something', async function () {
Copy link
Owner

Choose a reason for hiding this comment

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

Missing ( after `describe.

it('should work', function () {});
});

describe'something', async () => {
Copy link
Owner

Choose a reason for hiding this comment

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

Same here.


If the `describe` function does not contain `await`, a fix of removing `async` will be suggested.

This rule looks for every `describe.only`, `it.only`, `suite.only`, `test.only`, `context.only` and `specify.only` occurrences within the source code.
Copy link
Owner

Choose a reason for hiding this comment

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

Why does it look for it.only and test.only etc? Maybe the whole paragraph can be removed as the first paragraph in this section already explains that describe, context and suite is supported.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Whoops, that part was copy/pasted from the docs for another rule where it did make sense. Maybe I was getting anxious because the other rules are so thoroughly documented 😆


```js
var describeOnly = describe.only;
describeOnly.apply(describe);
Copy link
Owner

Choose a reason for hiding this comment

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

I’m not sure if this example makes sense. It is completely unrelated to async.

Copy link
Owner

Choose a reason for hiding this comment

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

I guess one edge case that we can’t detect might be something like this:

async function mySuite() {
    it('my test', () => {});
}

describe('my suite', mySuite);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

D'oh, brain fart. I think I copy pasted from https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/test/rules/no-mocha-arrows.js#L15 and then my brain reset itself into a state where describe and it don't take a string argument.

Fixed in 7c9b6dc

if (isAsyncFunction(fnArg)) {
context.report({
node: fnArg,
message: `Do not pass an async function to ${name}()`,
Copy link
Owner

Choose a reason for hiding this comment

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

I would suggest something like Unexpected async function in ${name}() to be more in line with messages of other rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in a5fa46a. Looks like I copy/pasted from the no-mocha-global-arrows rule.

if (!containsDirectAwait(fn.body)) {
return fixer.replaceTextRange(
[ fn.start, fn.end ],
sourceCode.text.slice(fn.range[0], fn.range[1]).replace(/^async /, '')
Copy link
Owner

Choose a reason for hiding this comment

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

When a function is async, isn’t the first token always the async identifier? If so it might be easier to just get the first token of the function node and use fixer.remove.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point, fixed in 0c113b5

We also need go get rid of the whitespace after async, so we can remove the range from the start of the async token to the start of the next function or ( token.

ruleTester.run('no-async-describe', rule, {
valid: [
'describe()',
'describe(function () {})',
Copy link
Owner

Choose a reason for hiding this comment

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

The function should be the second argument of describe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Of course! 👍

Fixed in 7c9b6dc

Copy link
Owner

@lo1tuma lo1tuma left a comment

Choose a reason for hiding this comment

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

@papandreou Thanks for the great work, this looks already quite good. I’ve just left a few comments, but only minor things.

@papandreou
Copy link
Contributor Author

Thanks for the feedback, I think I've addressed all of it now.

By the way, the linting setup for this project was a pleasure to work with. I could really feel the presence of the maintainer's opinions in my editor, and that helped a great deal!

The only slightly annoying thing is that I can't even run the test suite if everything doesn't lint, because of

"pretest": "eslint .",
-- that gets in the way when you temporarily have some dead code, or if you've commented out some code without the appropriate amount of whitespace after // :)

Could it be changed to posttest instead?

@lo1tuma
Copy link
Owner

lo1tuma commented Feb 13, 2019

The only slightly annoying thing is that I can't even run the test suite if everything doesn't lint

That’s true, I usually use only npm run test:unit during development, which should even work in watch mode via npm run test:unit -- --watch. This command also doesn’t instrument the code for coverage, so it should be much faster.

Copy link
Owner

@lo1tuma lo1tuma left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks again, great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants