Support sourceType: "unambiguous" parsing #449
Conversation
src/index.js
Outdated
| child.type === "ImportDeclaration" || | ||
| child.type === "ExportDeclaration" || | ||
| child.type === "ExportAllDeclaration" || | ||
| child.type === "ExportDefaultDeclaration" |
There was a problem hiding this comment.
An interesting case would be AwaitExpression -- though that probably just throws in the babylon stage instead, before even becoming an AwaitExpression.
await is reserved as a keyword at the top level (so not only in async functions), but only when the source type is module (Note 1 in https://tc39.github.io/ecma262/#prod-AwaitExpression).
There was a problem hiding this comment.
You still get an AwaitExpression either way, I think that part of the spec is more to make like easier for parsers if they want.
In this example, if you use await as an identifier it'll throw and reparse as a script successfully, which I think is good?
There was a problem hiding this comment.
Is it possible to warn if ambiguous code is detected?
Codecov Report
@@ Coverage Diff @@
## master #449 +/- ##
==========================================
- Coverage 98.26% 97.81% -0.45%
==========================================
Files 20 20
Lines 3511 3527 +16
Branches 934 940 +6
==========================================
Hits 3450 3450
- Misses 22 37 +15
- Partials 39 40 +1
Continue to review full report at Codecov.
|
src/index.js
Outdated
|
|
||
| // Rather than try to parse as a script first, we opt to parse as a module and convert back | ||
| // to a script where possible to avoid having to do a full re-parse of the input content. | ||
| if (!hasModuleSyntax(ast)) ast.program.sourceType = "script"; |
There was a problem hiding this comment.
The "correct logic" would be to parse as script first and module later if that fails, but true, it's a lot more likely to get code that parses as both (or module only) as input. Not a lot of people still have code that only parses in sloppy mode, even if they still use sloppy mode semantics.
There was a problem hiding this comment.
Yeah, I think it's as long as the output result is the same, the potential better average performance makes me want to go this route.
There was a problem hiding this comment.
For perf I had the acorn folks dig into proofing out an optimized top level parse.
In reify we also do a source sniff for import or export and if it fails we skip it.
|
Will node do the same now? |
|
Nope! This is still a best guess. The only thing that's certain is that if |
|
I think at this point Node will end up with |
loganfsmyth
force-pushed
the
unambiguous-parsing
branch
2 times, most recently
from
f4fe97d
to
7ccf0d8
Compare
loganfsmyth
changed the title
loganfsmyth
force-pushed
the
unambiguous-parsing
branch
from
7ccf0d8
to
22fe40c
Compare
|
We moved babylon back into the monorepo at https:/babel/babel/tree/master/packages/babylon. Unfortunately pull requests cannot be migrated between repositories automatically. If this PR is still valid please reopen it there. |
This code is ugly so definitely consider a WIP, but I'm posting for feedback before I go any further. This is the same logic used by Webpack to parse files and will result in files being treated as modules if they contain at least one import/export statement.
My proposed usage of this in Babel itself would be to change Babel's current default
sourceType: "module"tosourceType: path.extname(opts.filename || "") === ".mjs" ? "module" : "script"so that files that Babel can begin toggling module transpilation directly based onsourceType, and can throw errors if import statements are inserted into a CommonJS module for instance. Similarly, this means we can stop addinguse strictat the top of CommonJS files automatically and stop rewritingthistoundefined.With this, users can opt into
sourceType: unambiguousin their.babelrcto tell Babel to essentially guess what type of file it is. This same logic is already implemented in Webpack and a new other loaders.