Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
eslint-recommended changes in eslint v6.0.0 #10768
Similar to previous release, new rules can be added to
moved this from Needs discussion
to Accepted, ready to implement
Jan 31, 2019
I like all of the new candidates in the original post.
I would like to remove the following from
I would like to reconsider the following:
I'd propose adding the following rules:
If #11279 is accepted and implemented before the next major release, I would also propose adding that rule.
I would lean against adding
I'm ambivalent about adding
Along those lines, I agree that we should remove
It seems like we need a full proposal to decide on. I'll propose the following:
Add the following rules to
Remove the following rule:
referenced this issue
Mar 17, 2019
Personally, I'm convinced that
To me, this is a case where developers can either (a) use a terse notation that is occasionally subtlely wrong, or (b) use a more verbose notation that doesn't have those problems. So my opinion is that always doing (b) is an easy choice, and enforcing against the buggy choice is important for developers who might not be aware of the subtle bug.
We've discussed in the 2019/04/11 TSC meeting.
Resolution: We will modify eslint:recommended as follows:
And we will discuss no-prototype-builtins in the next TSC meeting on 4/25. (Goal is to have a final decision on that rule with that meeting.)