WIP: support for class fields

[nathancahill]

Solves #123.

This is just a start. Todo:

• Regular fields x = 0
• Bare fields x
• Computed fields [x] = 0
• Bare computed fields [x]
• Does not remove surrounding whitespace

Feedback and pointers on removing the whitespace (does Buble generally do that or leave it?) See the whitespace in the tests.

Additional tasks by @adrianheine:

• Add support data
• Throw error on attempted private field transpilation
• Bare string literal fields "ab"
• String literal fields with value "ab" = 0
• Don't throw on two fields with newline (class {x\ny})

[adrianheine]

Maybe it's possible to use move here instead of removing the text and inserting it somewhere else?

[nathancahill]

I'm not sure it's possible to do this, since we're creating the constructor as a string, not a magic string. Right now the logic is collect fields => join fields with newlines => insert into top of constructor. To do this with move (besides converting constructor to magic string), we'd have to loop backwards (so we can always append to the front) or track the end position of the last inserted field.

[adrianheine]

Yeah, it's probably complicated if possible at all. Let's leave it as it currently is and deal with issues once they arise. Maybe it will be possible to move the super call to the front, that should fix a lot of issues.

[nathancahill]

Wondering about private fields, if they should be included in this PR. The current spec is interesting https://tc39.github.io/proposal-class-fields/#sec-private-names

[adrianheine]

I'm definitely willing to merge this without private fields if they are considerably more work. You could use acorn-private-methods to parse them, if you want to try it. There's also acorn-static-class-features, but I think we should get this with the current scope merged :)

[nathancahill]

Removing the private class fields todo for now. Your acorn-class-fields does support them, but it'll be complex to implement it in this PR, so we'll leave it for later (maybe with private methods too).

Last remaining item is the whitespace, does Buble remove it in other places when code is fully removed from a line leaving the line blank?

[adrianheine]

Since we parse private fields, but don't transpile them, we should throw an error until we support them.

[adrianheine]

Could you add the package-lock.json changes, too?

[adrianheine]

I think for now I'm okay with the whitespace as it is.

[nathancahill]

Done, but not sure why it's failing in Node 4 and 6.

[nathancahill]

I think it might be a parser error?

       classes-no-named-function-expressions.js
         transpiles a subclass with super calls:
     SyntaxError: super() call outside constructor of a subclass (4:5)
  1 : 
  2 :       class Foo extends Bar {
  3 :         constructor ( x ) {
  4 :           super( x );
                ^

It seems right, the super call is inside the constructor.

[adrianheine]

It's leaving stray semicolons:

class X { constructor() {} m = 5; y = 4; }

var X = function X() {
	this.m = 5;
	this.y = 4;}; ; 

[nathancahill]

Ah, thanks! How'd you see that? And how can I reproduce that to fix it?

[adrianheine]

Yeah, I don't know about the node 4/6 issues either. I'll look into it. As for the semicolons, the first snippet is the input, the second the output.

[nathancahill]

Took a swing at the semicolon issue by removing everything up to the next statement. Doesn't work because it would trim comments. Going to rework it to loop until hitting the next character, if it's a ; remove it, otherwise stop.

[nathancahill]

Here's another approach that handles the semicolons but leaves the comments. This might not actually be as nice, since the comment is left dangling where the class fields were pulled from.

[nathancahill]

Here's the outputs of the two options:

Input

class X {
    constructor() {}
    m = 5;
    // comment
    y = 4;
}

Output trim until semicolon:

var X = function X() {
    this.m = 5;
    this.y = 4;};

// comment

Output trim until next statement:

var X = function X() {
    this.m = 5;
    this.y = 4;}; 

[nathancahill]

I don't think other parts of Buble move code around like classes does, so this might be new territory as far as deciding what to do about stray comments.

Babel leaves the comment dangling:

var X = function X() {
    _classCallCheck(this, X);

    this.m = 5;
    this.y = 4;
}
// comment
;

[adrianheine]

I 'm wondering if it's not possible to leave the body where it is and turn the class around it into a function and move the methods out of the function?

[nathancahill]

You'd still end up having to move some code. To me, the "least surprising" code movement is the class fields to the constructor rather than the methods.

[adrianheine]

Could you rebase this and maybe already squash the commits? I just added running bublé over the test262 tests to travisci and I'd like to see the result of that :)

[nathancahill]

Rebased and squashed. Will look in to test262 soonish.

[greypants]

Excited about this work! We're using react-live for our component docs, and getting this feature in will remove a bunch of boilerplate from our examples.

[adrianheine]

I rebased this, added some data about failing test262 tests and added 5 tasks to the top post which I think need to be done before we can merge.

[yeliex]

any progress?

[trusktr]

Come on Svelte! Where you at?