-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Move environment-visitor helper into @babel/traverse
#16577
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
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/57359 |
JLHwung
left a comment
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 recall previously we imported the traverse from their peer dependent @babel/core because of compatibility issues. Specifically we want the core, even if it is an old version, to explode any AST alias so that the traverser, imported from core, will not complain about any new AST types beyond its knowledge.
Now that visitors.environmentVisitor will explode the visitors via merge from the latest traverse, maybe we have to defer this change to Babel 8?
|
@JLHwung Most of the plugins changed in this PR already import their traverse (either from I will revert the change for the plugins that currently use the function parameter, so that we don't risk breaking something that is currently working. |
|
Actually, the only packages where we are potentially introducing the problem is I'll add a little check for it. |
d1dfe1c to
1e3bfa5
Compare
6ee00be to
ff3c813
Compare
|
Whops, I meant to mark as ready and I merged 😅 I guess it's fine given that we are close to a release, but I'll revert if needed. |
)" This reverts commit 25d3561.
Fixes #1, Fixes #2I'm working on removing cycles between packages caused by type-only imports. My motivation is that, even if it's a type-only import, it's an actual conceptual cycle and those packages will always be used together anyway. For example:
@babel/traversedepends on@babel/helper-environment-visitor@babel/helper-environment-visitordoes not explicitly depend@babel/traverse, but it can only be used onNodePaths so it can only be used when@babel/traverseThis has two benefits: