Add prefer-to-be-defined rule #8
Conversation
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
c206685
to
86177e2
Compare
docs/rules/prefer-to-be-defined.md
Outdated
|
|
||
| ## Rule details | ||
|
|
||
| This rule triggers a warning if `toBe()` is used to assert a undefined value. |
docs/rules/prefer-to-be-defined.md
Outdated
| The following patterns are considered warning: | ||
|
|
||
| ```js | ||
| expect(true).not.toBe(undefined); |
There was a problem hiding this comment.
I don't think this should warn, that should be caught by the other rule.
As eslint fixes are multipass, you'd get the same result in the end when autofixing, and then you don't have 2 rules warning about the same thing at once 🙂
rules/prefer_to_be_defined.js
Outdated
| const parentProperty2 = node.parent.parent.property; | ||
| const propertyName2 = parentProperty2.name; | ||
| const argument = node.parent.parent.parent.arguments[0]; | ||
| const propertyDot = context |
There was a problem hiding this comment.
put this inside of the fixer so we don't do it every time
rules/prefer_to_be_defined.js
Outdated
| ); | ||
| if ( | ||
| (propertyName === 'not' && | ||
| propertyName2 === 'toBe' && |
| 'use strict'; | ||
|
|
||
| const RuleTester = require('eslint').RuleTester; | ||
| const { rules } = require('../../'); |
There was a problem hiding this comment.
Can't use destructuring (failing CI)
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
4 times, most recently
from
6ccdf5c
to
73894e2
Compare
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
73894e2
to
5489863
Compare
|
|
||
| invalid: [ | ||
| { | ||
| code: 'expect(true).not.toBe(undefined);', |
There was a problem hiding this comment.
See #8 (comment), I don't think this rule should warn on toBeUndefined(), the other rule can warn on that
|
@xfumihiro This needs a rebase. Can you also update the changelog? 🙂 |
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
5489863
to
819ff47
Compare
|
|
||
| invalid: [ | ||
| { | ||
| code: 'expect(true).not.toEqual(undefined);', |
There was a problem hiding this comment.
Should have a test for toBe as well
| const ruleTester = new RuleTester(); | ||
|
|
||
| ruleTester.run('prefer_to_be_defined', rules['prefer-to-be-defined'], { | ||
| valid: ['expect(true).toBeDefined();'], |
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
ed580ca
to
67c6560
Compare
|
I like the direction! Definitely something we can build upon. It's currently failing on Node 4, as that does not support destructuring. |
|
Isn't Node 4 support being dropped? |
|
Yep, in the next release. |
|
It's being dropped for jest core in the next release, not necessarily here 🙂 See #1 where it was discussed |
|
We could add babel, but it is nice to not have to do that |
|
I agree it makes more sense that this should be merged with prefer-to-be-undefined rule, but what name should it have? |
|
What about just |
|
Needs a rebase 🙂 |
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
2 times, most recently
from
ebc0615
to
b6a59b9
Compare
|
needs a rebase again, sorry. |
|
Can you mark the commit with |
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
b6a59b9
to
ffb1cdf
Compare
BREAKING CHANGE: prefer-to-be-undefined rule has been removed and merged into this rule.
xfumihiro
force-pushed
the
prefer-to-be-defined
branch
from
ffb1cdf
to
0f7c6ba
Compare
|
@xfumihiro Are you still interested in championing this PR, as it would be cool to get this across the line :) Since it was done before the typescript migration, it's probably best to create a new PR rather than rebase. Otherwise if you're not interested (or don't have the time), I'm happy to pick up this PR. |
|
@G-Rath go ahead plz :) |
|
I'm going to close this off for now - overall I'm not against the rule, but this PR has been around for a while, and you should at least be able to archive a similar effect with |
No description provided.