This has come up before. See: #159

Right now, adding this rule would make any modules using standard unusable with Node v0.10 and v0.12. Let's re-consider adding this rule once those versions are officially unsupported.

@feross actually this rule only enforces using const instead of let, it doesn't affect var usage at all...

@LinusU Good to know!

I still think we should wait a while before putting this into a release. The jury is still out on which ES6 language features are "good parts" and which are not.

In 6 months to a year, we should consider doing a release of standard that enforces some new ES6 rules like this one. Node v0.10 and v0.12 will finally be unsupported at that time and the native support for features like const will have increased to the point where transpilation is not required to use them.

For example, with const, less than 60% of browsers have caveat-free support. Once that's over 90%, we can consider recommending it.

The effect on the ecosystem is moderate:

# tests 427
# pass  405
# fail  22

@feross actually this rule only enforces using const instead of let, it doesn't affect var usage at all...

And that tips me over the line 👍

any modules using standard unusable with Node v0.10 and v0.12

surprisingly const works in >=0.10

surprisingly const works in >=0.10

I always thought const was in >= 0.12. So I fired up my dusty v0.10 and by golly, you're right!

Be aware that it doesn't work in the same way in 0.x though.

See this table for more info: http://node.green/#const

In 6 months to a year, we should consider doing a release of standard that enforces some new ES6 rules like this one.

Looking forward to this!

Here's a link to the Node.js LTS schedule.

TL;DR:

• v0.10 LTS support ends 2016-10-01
• v0.12 LTS support ends 2016-12-31

Looking forward to seeing this rule land once the v0.* releases are no longer supported!

Standard 8 doesn't support Node.js 0.10 or 0.12 though since ESLint decided to drop support for them... Maybe standard 9 could start introducing ES2015 and up rules now that most runtimes are compatible...

@LinusU I'm not against the idea.

I'm not against the idea.

I think this issue should be reopened for consideration in v9. Feel free to reclose.

This rule is worth considering, but on top of all the other changes going into standard v9, I think this might be a bit too much in one version.

1..422
# tests 422
# pass  396
# fail  26

I'd also like to figure out a solution for all ES6+ rules at one time, instead of merging just this one right now.

Moved it to standard v10 milestone.

How do folks feel about this today? I know opinions have changed around const lately :)

Opinions around const have changed? I use it exclusively these days.

👍 Always use the most strict declaration first, starting with const then let then var

Thumbs up for this rule

How do folks feel about this today?

It's important. I recently switched my team over to Airbnb's ESLint config. This was a factor.

Generally in favour now that block scoped const is considered typical, as when this issue was opened, https://stackoverflow.com/questions/35234850/const-within-block-scopes-in-node-and-chrome-v8 was a common occurence burning you in production.

@fanatid

@feross maybe when the new node LTS is >5.0.0?

I used to use const, and am now back on the var train. The spec champion for const at the time recently called const: "One of my main ES6 regrets", and I get where they're coming from.

The only thing const helps catch is double declarations, something standard does too. const is more characters to type, mostly for the sake of it. I don't think it's a particularly useful language feature, and I don't see myself ever using it again.

That said, I get it if people still want to write const. That's fine; it's a choice. However, I think enforcing const for everyone would be overly prescriptive.

@yoshuawuyts ?

const x = 2
x = 3 // ERROR

let x = 2
x = 3 // OK

Yes, it doesn't help with

const x = {}
x.y = 3 // hmph

But, it isn't that bad.

The main thing it guards against is:

const foo = 3
const foo = 2 // ERROR

But the same thing is picked up by standard:

var foo = 3
var foo = 2 // ERROR

My main point is that if we could argue for disallowing const all together, we should probably not enforce it to be used everywhere instead.

I don't understand, an example of what it does guard against is:

const x = 2
x = 3 // ERROR

What did I miss? Isn't that the point? Not double declaration.

This rule just tells to use const if you don't reassign a variable. It has nothing to do with the multiple declaration.

Nowadays in ES6 it's highly recommended to use only const and let (and drop the usage of var). So this rule kinda makes sense to implement.

I've noticed that the milestone has changed -- does this mean it will be accepted in a future release? I'm not familiar with the development process on this repo but this issue would be a major factor in switching to eslint-config-standard.

@christianbundy The plan is to merge this in standard 13. I just did a quick standard 12 release to get us on ESLint 5.

PR is up standard/eslint-config-standard#133, I'm going to start sending pull requests to affected repos...

Any update on this?

This will ship in standard 13.