Add an option to Babylon to have decorators before export #7869
Conversation
nicolo-ribaudo
added
pkg: parser
Spec: Decorators
PR: New Feature 🚀
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/7966/ |
nicolo-ribaudo
force-pushed
the
decorators-parser-options
branch
2 times, most recently
from
09a9319
to
d082db9
Compare
They work similarly to how they work in Babel. e.g.
babylon.parse({
options: [
"plugin1",
["plugin2", { option: true }]
]
});
The inernal api to get an option is
this.getPluginOption("pluginName", "option")
If the plugin isn't defined, it returns undefined.
nicolo-ribaudo
force-pushed
the
decorators-parser-options
branch
2 times, most recently
from
6860e64
to
1df9568
Compare
nicolo-ribaudo
force-pushed
the
decorators-parser-options
branch
from
1df9568
to
82c9311
Compare
|
I think that after this PR I will need to open only one more. If we can finish the work on decorators before the TC39 meeting it would be super! |
packages/babylon/src/index.js
Outdated
| ) { | ||
| throw new Error("Cannot use decorators and decorators2 plugin together"); | ||
| throw new Error( | ||
| "Cannot use decorators and decorators-legacy plugin together", |
There was a problem hiding this comment.
Nit:
Cannot use the
decoratorsanddecorators-legacyplugins together.
| p => p === "estree" || p === "flow" || p === "jsx" || p === "typescript", | ||
| ); | ||
| let pluginList = pluginsFromOptions.filter(plugin => { | ||
| const p = getPluginName(plugin); |
There was a problem hiding this comment.
Hey all, I'm concerned about this. Now that we've defined the ability to pass options to Babylon plugins, ordering becomes critical. What if some other piece of tooling injected a syntax plugin into the plugin list after this one, or before? Which one should take priority? For instance for https://github.com/babel/babel/pull/7934/files#diff-3a8233bcd2766d2c7d87f23f944f7726R12, say the user's framework auto-enables flow, but the user wants to enable all, which comes first?
So far we've avoided this problem by not having options, and not worrying about duplicates. Now it will matter very much both what order your Babel plugins are in, but also what order they enable Babylon plugins in.
At a minimum, have we verified that the ordering on these is consistent with the ordering of visitors? e.g. If two plugins are enabled with different options, whichever one's visitors run first, is also the one who's Babylon configuration takes affect?
There was a problem hiding this comment.
Let's continue the discussion over in #7984 instead of here.
| this.hasPlugin("decorators") && | ||
| this.getPluginOption("decorators", "decoratorsBeforeExport") | ||
| ) { | ||
| this.unexpected(); |
There was a problem hiding this comment.
It would be good to have these throw more helpful errors about what the user is supposed to do to get their code to parse.
lock
bot
added
the
outdated
8f76ff3 adds support for options to Babylon plugins.
3c5c47f adds support for decorators before export (via
["decorators2", { "decoratorsBeforeExport": true }]). I think that this should be an option because the discussion about it is still open; this would allow us to experiment both syntaxes. We can discuss about what the default value is.