-
-
Notifications
You must be signed in to change notification settings - Fork 256
Conversation
91872db
to
1f83feb
Compare
1f83feb
to
030dc4c
Compare
@@ -1,2 +1,2 @@ | |||
export interface foo { p: number }; | |||
export interface foo<T> { p: T }; | |||
export interface bar<T> { p: T }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty new to Flow - let me know if this isn't the correct fix for this test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct
Looks like the CI tests are failing because of test files in Babel plugins that contain duplicates exports in the same file. I think it'll require similar changes to this PR: babel/babel#3518. How are cross-repo changes like this usually handled? I'm happy to make the necessary changes in the Babel repo, including reverting the band-aid fix for duplicate default exports if and when this PR lands. |
Good job. That looks really good. The flow test looks good. 👍 The tests of babel now fail, but this is okay for now, but we would need to correct them at some point, before we release this. |
Cool! Should I go ahead and make a PR to the main babel repo? |
Yes that would be nice. Thanks. Oh for some reason I did not see the other comment of you. So there is no real workflow yet on how to do the cross-repo stuff. I described in this PR how to link babylon in babel. I should really but that in the Contributing file. |
Thanks for all the info on this! One more question - do you think I should split the changes into batches? Splitting each one of those files into multiple files is going to be a pretty massive diff. |
Ah sorry, for not answering. As long as the changes belong together I think they should go into the same PR imho. And I think this would account for this case. |
Finally started in on this, though might take me a few days. Doing it in chunks because there are a lot of changes. |
Finally got around to fixing those tests! PR open here: babel/babel#4538 I mention it in the issue as well, but will also make a 2nd PR that removes the initial band-aid fix that was merged into Babel itself and to rename the test files so they follow the convention used in the currently open PR. I plan on getting to this tomorrow! |
Current coverage is 97.04% (diff: 100%)@@ master #107 diff @@
==========================================
Files 19 19
Lines 3130 3185 +55
Methods 320 327 +7
Messages 0 0
Branches 800 819 +19
==========================================
+ Hits 3029 3091 +62
+ Misses 101 94 -7
Partials 0 0
|
@@ -844,7 +844,7 @@ pp.parseExport = function (node) { | |||
} | |||
node.declaration = expr; | |||
if (needsSemi) this.semicolon(); | |||
this.checkExport(node); | |||
this.checkExport(node, true, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a thought: might be nice if this method wasn't taking in true, true (an object, named, etc) but I know we do that everywhere else ^ this.parseFunction(expr, true, false, false, true);
😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, was trying to follow the style I saw elsewhere, but agree. Would you like me to change that to an object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hzoo: Do you mean checkExport(node: Node, options: { named: boolean, default: boolean })
or what do you mean with object? Maybe also checkExport(node: Node, type: "named" | "default" | null)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah to make it more readable - dono if it was done before for perf?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assumed it was done this way for performance reasons
@@ -844,7 +844,7 @@ pp.parseExport = function (node) { | |||
} | |||
node.declaration = expr; | |||
if (needsSemi) this.semicolon(); | |||
this.checkExport(node); | |||
this.checkExport(node, true, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hzoo: Do you mean checkExport(node: Node, options: { named: boolean, default: boolean })
or what do you mean with object? Maybe also checkExport(node: Node, type: "named" | "default" | null)
?
Opened one more PR that reverts the commit I made that throws a warning in babel itself since we have moved that into babylon. I also updated the test names so that they match the convention I used in my more recent PR that was merged today. Let me know if you need anything else! |
Seems like this change causes Babylon to throw for one of my files that worked fine before. The file in questions looks like this: export toString from './toString'; `toString` has already been exported. Exported identifiers must be unique. (1:7)
> 1 | export toString from './toString';
| ^
2 | Is this an intended change, is not Seems like all keys on |
@@ -913,6 +937,20 @@ pp.checkExport = function (node) { | |||
} | |||
}; | |||
|
|||
pp.checkDuplicateExports = function(node, name, isDefault) { | |||
if (this.state.exportedIdentifiers[name]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to manage Object.prototype
here.
Something along the lines of this maybe?
if (Object.getOwnPropertyNames(this.state.exportedIdentifiers).indexOf(name) !== -1) {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, I wrap up a fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting, thanks for the report
cc @kaicataldo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wow, that makes sense. @danez Let me know if you need me work on a fix - happy to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue in jscs-dev/node-jscs#1204 😄
I think I got all the cases for named exports - let me know if I missed one! Also wasn't sure about the error message wording, but was hoping that by including the name of the offending duplicate export that debugging could be made easier for the end user. Finally, wasn't sure where to put the tests - happy to move them!