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.
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
Allow plugins to assert that a specific babel version has loaded the plugin. #7450
Conversation
import { types as t } from "@babel/core"; | ||
|
||
export default function() { | ||
export default declare(api => { | ||
api.assertVersion(7); |
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.
Definitely curious for feedback on this approach. It's a little verbose, but it means that since this is the function that throws, the preset/plugin doing the validation is the thing that throws, so the name of it shows up in the stack trace making debugging a lot nicer.
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.
Would it make sense to convert this to "assertSemverVersioning" or something like that? Presumably it will be possible for plugins to be compatible with multiple major versions of Babel.
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.
Hmm, I worry about that getting pretty verbose. Is the concern that people will assume that assertVersion
requires a single version?
api.assertVersion(">=7.x < 9.x")
I at least think is acceptable.
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.
Is the concern that people will assume that assertVersion requires a single version?
Yeah exactly. When I read assertVersion
and saw your example it wasn't immediately obvious that a semver range could be given.
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 feel like documentation would probably be enough to address that, but I do see where you're coming from. I was thinking of the function like assertVersionSatisfies(...)
so the version
is the Babel core version, not argument string, so the fact that the string can be semver seemed not strongly tied to the mention of version in the name.
At the end of the day, most people bothering to put this assertion in in the first place will probably look at our docs, or else copy paste and not give it a second thought. Since this is only an issue once we start releasing future versions, it seems expected that once it becomes important, people will wonder what specifically it supports as an argument, and at that point the docs are enough.
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6989/ |
I at first thought maybe it would be nicer if modules that contain plugins simple export a second constant which is the version of babel-core that this plugin supports. I don't think it is too verbose, but if so then we could maybe include the assert in the helper? In the stack the plugin would still how up if I'm not wrong. export default declare('>=7.2.3', () => plugin); But I also like how it is now. |
@danez Yeah, I was on the fence about that approach and mostly I opted to go with this PR's approach instead because having it be a programmatic API like
|
This allows plugins to use
api.assertVersion(7)
as a general version, or any semver string to assert that the current version of Babel is one that is supported.Trying to load
@babel/preset-env
for instance with Babel 6's CLI results inwhere before it would throw about accessing
loose
onundefined
or something along those lines because theoptions
object isn't passed to plugins in Babel 6.x.