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

ES6 Rule Wishlist #1617

Closed
xjamundx opened this Issue Jan 2, 2015 · 20 comments

Comments

Projects
None yet
7 participants
@xjamundx
Copy link
Contributor

xjamundx commented Jan 2, 2015

There are a lot of new features included in ES6. I know ESLint is working hard to support them. There is no doubt going to be a long list of rules that are likely going to be needed as more features of ES6 are supported. I'd like to propose this as the place where we can discuss feature requests for ES6 rules that maybe aren't quite ready to be made into full-on feature requests. If you'd prefer this on the mailing list (or as separate issues) let me know.

  • no var (prefer let and const for everything
  • Prefer setPrototypeOf to __proto__
  • Enforce * location for generator functions function* bazooka or function *bazooka
  • Prefer super to Class.prototype.methodName.apply(this, arguments) or variations
  • Avoid arguments completely
  • Avoid toMethod (possibly, it just seems like a a weird edge to me and not normally used)
  • Use default parameters (instead of param1 || 'value')
  • Avoid UPPER_CASE (i.e. use const instead)
  • Never use for (instead just use .forEach and variants, unless you're dealing with iterators.... hmm)
  • Only use => for short functions and not for methods (or some variation)
  • Prefer shortened object literal syntax for methods var toaster = { toast() {} };
  • Prefer template strings to string concatenation
  • ...

Are these good rules to consider having? Are any of them in the works already? What other ES6 specific ideas are out there?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Jan 10, 2015

Some of these make sense as built-in rules for ESLint, others I'm not sure. The ones I definitely would like are:

  1. no var
  2. setPrototypeOf over __proto__
  3. * location for generators
  4. Prefer super
  5. Avoid arguments
  6. Use default parameters
  7. Prefer concise object literal syntax
  8. Prefer template strings over string concatenation

I can't think of a good reason to avoid toMethod(), it's basically just bind() for super, and I see no issue with using it.

I'd still use UPPER_CASE for constants even in ES6. Makes it much easier to see which identifiers are writable in code.

@nzakas nzakas added the triage label Jan 10, 2015

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Jan 11, 2015

Great, I'll take a stab at them over the next couple of weeks (and file them as individual PRs per rule). Hmm any examples of customizing ecmaFeatures on a per-rule basis? Hmm that probably won't work. thinking...

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Jan 11, 2015

Not possible at the moment. We do probably need to expose ecmaFeatures to rules so they can turn themselves off when not applicable.

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Jan 11, 2015

Yeah or like let the ecmaFeatures get defined dynamically by which rules are enabled that need certain features or something. I'll start building some of these out and we'll see what trouble we run into :)

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Jan 11, 2015

Rules can't define such information, nor would I want them to. We will work on showing the info to rules.

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Jan 11, 2015

Yeah what I wanted for now was just the the latest version of https://github.com/eslint/eslint-tester/

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Jan 13, 2015

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Jan 13, 2015

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Jan 13, 2015

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Jan 13, 2015

@OliverJAsh

This comment has been minimized.

Copy link

OliverJAsh commented Feb 4, 2015

Can we add ES6 modules aka import to the list?

@lo1tuma

This comment has been minimized.

Copy link
Member

lo1tuma commented Feb 4, 2015

@OliverJAsh this issue is about ES6 related linting rules, not about ES6 syntax.

We use espree for parsing, if espree supports ES6 modules we will support it too (see eslint/espree#10).

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Feb 4, 2015

But @OliverJAsh, @lo1tuma there's already a PR for it eslint/espree#43, so I imagine it will land in the next couple of days :)

Holixus pushed a commit to Holixus/eslint that referenced this issue Feb 12, 2015

Holixus pushed a commit to Holixus/eslint that referenced this issue Feb 12, 2015

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Feb 26, 2015

Hey so hanging out in the babel chatroom I found a few more things we should probably consider gently discouraging around fat arrows:

  • () => {} // will not return {}
  • prop => {a: prop} // is even weirder

suggestion may be to wrap in () such as

  • () => ({})
  • prop => ({a: prop})

or possibly add an explicit return statement (which i think may confuse people even more)

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Feb 26, 2015

Hmm, still probably a bit too early to tell about these. I've used ()=>{} for empty functions in a bunch of places. We don't really know if people will be confused as to what this does yet.

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Feb 27, 2015

Yeah let's take a wait and see approach. I imagine patterns of mistakes will become obvious pretty quickly :)

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Mar 5, 2015

Any interest in a require-module-type : "amd", "es6", "cjs" rule?

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Mar 5, 2015

I'm ambivalent. Seems a bit of a stretch to think that people would accidentally usethe wrong module format.

@ericelliott

This comment has been minimized.

Copy link

ericelliott commented Mar 16, 2015

I've used ()=>{} for empty functions in a bunch of places. We don't really know if people will be confused as to what this does yet.

I've done this, too, but I can see how this form is pretty ambiguous from a reader's perspective. :|

@xjamundx

This comment has been minimized.

Copy link
Contributor Author

xjamundx commented Apr 7, 2015

Hey I think it's time to revisit these again. I'll take a stab at "Prefer concise object literal syntax" soon.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Apr 7, 2015

👍

I'm also thinking of a "prefer const" rule that flags uses of var and let for variables that never change.

@Josh-a-e

This comment has been minimized.

Copy link

Josh-a-e commented Apr 7, 2015

+1

On 7 Apr 2015, at 20:31, Nicholas C. Zakas notifications@github.com wrote:

I'm also thinking of a "prefer const" rule that flags uses of var and let for variables that never change.


Reply to this email directly or view it on GitHub.

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Apr 8, 2015

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Apr 8, 2015

@AsaAyers

This comment has been minimized.

Copy link

AsaAyers commented Apr 13, 2015

I'm also thinking of a "prefer const" rule that flags uses of var and let for variables that never change.

Having a rule that will error when you assign to a const would be nice too. I'm not sure if it's technically a syntax error, but Babel throws an error at compile time if you do this.

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Apr 13, 2015

xjamundx pushed a commit to xjamundx/eslint that referenced this issue Apr 13, 2015

nzakas added a commit that referenced this issue Apr 16, 2015

Merge pull request #2257 from xjamundx/prefer-shorthand
New: object-shorthand rule (refs: #1617)
@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Apr 17, 2015

Let's close this and just start filing individual issues now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.