Add ES6 Support

[Constellation]

Supporting ES6 block scopes and some special scopes (such as arraw function and method)

[nzakas]

Are you still going to do this? ESLint has a bug related to let scoping that could use this: eslint/eslint#917

[Constellation]

Oh, OK. I'll work on it on weekend :)

[Constellation]

semantics in ES6 spec may be mature enough :)

[nzakas]

They are. I've documented it in my book: https://github.com/nzakas/understandinges6/blob/master/manuscript/01-The-Basics.md#block-bindings

[jlongster]

This would be awesome to have!

[nzakas]

Just checking in - any chance you're working on this? :)

[Constellation]

Hi @nzakas,
Sorry for my further late reply.

I'm now gradually supporting ES6 in the tools, now escodegen supports ES6 Syntax completely.
So, next, I'm planning to support ES6 in estraverse since it is used in the escope. Then, support scoping in escope.

Since there's significant difference between ES5 scopes and ES6 scopes, maybe I'll introduce ecmaVersion option.

[nzakas]

That sounds awesome!

[elwayman02]

@Constellation what's the status on this? Is there anything we can do to help out? I'm working on trying to get an ES6-supported version of ESlint using the harmony branch of esprima, so my next step is to approach ES6 support in escope and estraverse. :)

[Constellation]

OK, so, let's start to support ES6.
I'll start it with estraverse.

[Constellation]

Support ES6 traversing in estraverse. estools/estraverse@19f7a5c

[StoneCypher]

This would really help for getting eslint running on jsx

[sebmck]

Any update on this? Definently keen to use this for 6to5. Reference babel/babel#175

[Constellation]

Currently, we're investigating the ES6 spec and Esprima AST nodes.
And We're now updating escodegen and estraverse.
Does anyone knows the issue about them? I think estraverse now completely support ES6 syntax. If it's correct, my mental model of ES6 AST may be stable.

[sebmck]

Main issues you'll run into is implementing temporal dead zones. Default parameters have their own scope and you can't access let/const variables before they're initialised.

[Constellation]

Main issues you'll run into is implementing temporal dead zones. Default parameters have their own scope and you can't access let/const variables before they're initialised.

Nice, it's very useful information.
And we need to consider destructuring assigned variables.

var { a, b, c } = obj;  // it materialize a, b, c variables.

[Constellation]

And we need to ensure,

for (let i = 0; i < 10; ++i) { console.log(i); }

scope behavior.

[Constellation]

We're now implementing scopes for ES6. But be careful, it's experimental and the behavior might be changed

[Constellation]

@sebmck:

Do you know the actual section in the ES6 draft (rev28)?
I'm now investigating it.

[sebmck]

@Constellation For what specifically?

[Constellation]

@sebmck
I think sticking to the formal spec is very important ;)
It provides a clear reason to "why it is so implemented". And makes the tool stable.

[sebmck]

@Constellation Yeah I understand that. I was referring to what section specifically that you were looking for.

[Constellation]

@sebmck
Ah, I've misunderstood.

Default parameters have their own scope.

I'm looking for it. Now seeing 9.2.13, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-functiondeclarationinstantiation

[Constellation]

@nzakas

OK, I've fixed the bug.
Which is the preferable for you?

1. update the 2.0.1 code with this fix. (8794242)
2. publish the current code as 3.0.0, currently TDZ is not updated yet. But other things are almost identical.

[nzakas]

If you can update 2.0.1 with the fix, I can keep testing for other incompatibilities.

[Constellation]

OK, so I've published it as 2.0.2, it shipps the above bug fix :)

[nzakas]

Thanks!

[nzakas]

I found one more issue. It looks like escope isn't marking increment/decrement as write operations. For example:

/*global b:false*/
b++;

The ref for this has ref.isWrite() return false, whereas in 1.x it returned true.

[Constellation]

@nzakas
Cool! I'll fix it :)

[Constellation]

@nzakas

I've fixed it and released it as 2.0.3 :)

[nzakas]

Thanks!

[nzakas]

@Constellation Found a couple more issues.

First, when using a label, references inside the label are not counted accurately:

var foo = 5;

label: while (true) {
  console.log(foo);
  break label;
}

In this example, the variable foo incorrectly reports zero references when there should be one.

Second, block scope references don't appear to work in loops:

for (let prop in box) {
    box[prop] = parseInt(box[prop]);
}

The variable prop also shows up with zero references instead of two.

[nzakas]

Sorry, I should have said isRead() was the problem, not references.

[nzakas]

Okay, nailed down the problem for the let in loops. Basically, the variable prop appears in the variables array for both the TDZ scope and the block scope. The reference to prop inside the block scope is then counted as a reference to prop in block, whereas the prop in TDZ is said to have zero references. This is what's confusing ESLint.

For the time being, I can avoid checking the TDZ for variables, but it seems like the TDZ logic is not quite correct.

[Constellation]

@nzakas

Oh, thank you for your pointing.
These are raised when using ecmaVersion: 6?
I'll investigate this issues.

[nzakas]

Yes, with ecmaVersion: 6.

[jrvidal]

Just for reference, eslint/eslint#2405 is blocked by this issue, more concretely by "Initializers in Destructuring Assignments".