Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Check exported bindings are defined #9589

Merged
merged 4 commits into from Feb 26, 2019
Merged

Check exported bindings are defined #9589

merged 4 commits into from Feb 26, 2019

Conversation

danez
Copy link
Member

@danez danez commented Feb 26, 2019 •
edited

Q                       A
Fixed Issues?
Patch: Bug Fix? n
Major: Breaking Change? n
Minor: New Feature? n
Tests Added + Pass? Yes
Documentation PR Link
Any Dependency Changes?
License MIT

This ensures that exports are always defined before exporting them. This is required according to the spec here: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-module-semantics-static-semantics-early-errors

It is a Syntax Error if any element of the ExportedBindings of ModuleItemList does not also occur in either the VarDeclaredNames of ModuleItemList, or the LexicallyDeclaredNames of ModuleItemList.

@danez danez added PR: Spec Compliance 👓 A type of pull request used for our changelog categories pkg: parser labels Feb 26, 2019
@danez danez added this to In progress in Parser: Spec Compliance, Refactoring and Performance via automation Feb 26, 2019
@babel-bot
Copy link
Collaborator

babel-bot commented Feb 26, 2019 •
edited

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/10315/

@danez danez marked this pull request as ready for review February 26, 2019 03:54
danez
danez commented Feb 26, 2019
View reviewed changes
packages/babel-generator/test/index.js
@@ -489,7 +489,7 @@ suites.forEach(function(testSuite) {
const actualAst = parse(actualCode, {
filename: actual.loc,
plugins: task.options.plugins || [],
strictMode: false,
Copy link
Member Author

@danez danez Feb 26, 2019 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not really correct as sourceType:"module" should always be in strict mode, but it is needed for some of the tests.

@nicolo-ribaudo
Copy link
Member

nicolo-ribaudo commented Feb 26, 2019 •
edited

Can I export { Object }?

EDIT: Ok, I can't. Can you add a test both for it and export { Object as Obj }? I don't want that someone will add an exception for builtins in the future, since this is a bit counter-intuitive.

@danez
Copy link
Member Author

danez commented Feb 26, 2019

I was wondering the same while working on it, but node does not allow to export globals either. I will add a test.

Parser: Spec Compliance, Refactoring and Performance automation moved this from In progress to Reviewed Feb 26, 2019
nicolo-ribaudo
nicolo-ribaudo approved these changes Feb 26, 2019
View reviewed changes
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case you are wondering how much confusing it is: https://twitter.com/NicoloRibaudo/status/1100340777262166016 😛

@danez danez merged commit 43eed1a into babel:master Feb 26, 2019
Parser: Spec Compliance, Refactoring and Performance automation moved this from Reviewed to Done Feb 26, 2019
@danez danez deleted the undefined-exports branch March 7, 2019 00:32
This was referenced Mar 20, 2019
Closed
Closed
@shrinktofit shrinktofit mentioned this pull request Mar 22, 2019
Closed
@shrinktofit
Copy link
Contributor

shrinktofit commented Mar 22, 2019 •
edited

Please take a look at #9745

@shrinktofit shrinktofit mentioned this pull request Mar 22, 2019
Closed
@benjamn
Copy link
Contributor

benjamn commented Apr 8, 2019

#9720 (comment)

It's fine to use the parser to help enforce spec compliance, as long as you make the behavior configurable, but as far as I can tell there's no way to disable this new and surprising behavior.

Babel has a powerful plugin system that allows sophisticated developers to produce valid code even if it looks "wrong" when it's first parsed. If the parser just refuses to parse the code, that power is lost.

Please consider making this behavior configurable! If you're open to that idea, I would be happy to submit a PR.

@mlrawlings mlrawlings mentioned this pull request Jun 11, 2019
Merged
@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 4, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@existentialism existentialism existentialism approved these changes

@nicolo-ribaudo nicolo-ribaudo nicolo-ribaudo approved these changes

Assignees
No one assigned
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue pkg: parser PR: Spec Compliance 👓 A type of pull request used for our changelog categories
Projects
No open projects
Parser: Spec Compliance, Refactoring ...
  
Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
6 participants
@danez @babel-bot @nicolo-ribaudo @shrinktofit @benjamn @existentialism