Rely entirely on sourceType for module vs script differentiation. #7417
Conversation
| @@ -330,6 +330,7 @@ function run(task) { | |||
| const newOpts = merge( | |||
| { | |||
| filename: self.loc, | |||
| sourceType: "unambiguous", | |||
There was a problem hiding this comment.
It might be nice to ditch this and allow input.mjs and output.mjs files or something, then our tests will also assert that if a transform changed the sourceType, our input and output would have different extensions.
If we should change the default to be |
loganfsmyth
force-pushed
the
sourcetype-reliance
branch
from
368aef7
to
cedb013
Compare
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6936/ |
loganfsmyth
added
the
PR: Breaking Change 💥
Isn't it already enabled by default? I think that it shouldn't, since it is better to throw soon than making webpack throw later with a less descriptive error. (Btw, is that option documented somewhere?) |
|
@nicolo-ribaudo Good catch, that's just a typo, definitely meant disable by default. |
Summary: The `sourceType` option is a new mandatory option for Babel which determines whether to parse the file with the module or script goal. The value "disambiguous" determines this state by parsing. See babel/babel#7417 Reviewed By: mjesun Differential Revision: D7685610 fbshipit-source-id: 3958c5ad396592bb1d790e2df4ce315737421a2f
**What**: Resolves #669 **Why**: Current yarn.lock blocks dtslint to download new TS versions. **How**: Update package.json and yarn.lock **Checklist**: <!-- add "N/A" to the end of each line that's irrelevant to your changes --> <!-- to check an item, place an "x" in the box like so: "- [x] Documentation" --> - [N/A] Documentation - [x] Tests - [x] Code complete Snapshots of babel-plugin-emotion are changed when I update `@babel` things to `7.0.0-beta.41` or higher. I cannot figure out why... Maybe [this PR](babel/babel#7417) is related with the problem.
Summary: The `sourceType` option is a new mandatory option for Babel which determines whether to parse the file with the module or script goal. The value "disambiguous" determines this state by parsing. See babel/babel#7417 Reviewed By: mjesun Differential Revision: D7685610 fbshipit-source-id: 3958c5ad396592bb1d790e2df4ce315737421a2f
lock
bot
added
the
outdated
from 6.x it depends on if we disable(we didn't set this option, in this PR anyway, so things now behave like they did in Babel 6.x, but we haveallowCommonJSExportsby defaultsourceType:unambiguousnow as an alternative))Per #7416, we're in a weird place right now in Babel 7 because we've landed some logic that tries to be smart about whether something is a module or a script. The two points that affect this issue are:
use strictand convertthistoundefined.transform-runtime(andtransform-async-to-generatorwhen usingmoduleandmethodoptions), we try to insert eitherrequireorimportbased on the type of file.So this puts us in a weird place.
In Babel 6, we just assumed it was always an ES6 module, which leads to breakage with Webpack because if
transform-runtimeinserts an import, but the user's file was CommonJS, Webpack will consider the whole file an ES6 module and the CommonJS stuff will break.In Babel 7 we rectified that in the short term by basically saying it's an ES6 module if both:
sourceType: moduleimportorexport.Unfortunately this means that if you want something to be an ES6 module and it doesn't have an import or export, it's actually impossible, hence #7416.
To resolve this, we've introduced
sourceType: "unambiguous"that performs the above logic at the parser level, so instead of checking those 2 states during transformation, the parser produces either ascriptormodule, which means that Babel itself can respect thesourceTypeas a source of truth.With that work landed in the parser, this PR removes the logic from the transformation system. The downside here being that we don't want to default to
sourceType: unambiguousbecause it isn't a formal specification and isn't backed by anything in particular. Instead we'd like to leave that up to the user to opt into.This means that with this PR, Babel will revert to it's Babel 6 behavior as mentioned above for
use strictandthisrewriting.I personally think that is fine. The main question I have is, should we try to make it more painful to treat a CommonJS module this way (auto-injecting use-strict and this->undefined) to encourage people to explicitly set
sourceTypebased on what they actually want?This could easily amount to us injecting code to throw a nice error saying "please set
sourceType:scriptorsourceType:unambiguousin your Babel config". We already have anallowCommonJSExportsoption on the CommonJS transform that we could easily disable by default, though the message will need updating to be more helpful. If we don't, it'll just be like Babel 6 if someone runstransform-runtimeon a CommonJS module, withmodules:falsefor Webpack they'll get unhelpful error messages aboutmoduleandexportsbeing undeclared.