Open nathancahill opened 6 years ago
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
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 :)
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?
Since we parse private fields, but don't transpile them, we should throw an error until we support them.
Could you add the package-lock.json
changes, too?
I think for now I'm okay with the whitespace as it is.
Done, but not sure why it's failing in Node 4 and 6.
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.
It's leaving stray semicolons:
class X { constructor() {} m = 5; y = 4; }
var X = function X() {
this.m = 5;
this.y = 4;}; ;
Ah, thanks! How'd you see that? And how can I reproduce that to fix it?
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.
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.
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.
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;};
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
;
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?
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.
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 :)
Rebased and squashed. Will look in to test262 soonish.
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.
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.
any progress?
Come on Svelte! Where you at?
Solves #123.
This is just a start. Todo:
x = 0
x
[x] = 0
[x]
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:
"ab"
"ab" = 0
(class {x\ny})