You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before merging, can we discuss whether mutating BUILD_KEYS is actually an intentional API? For the Babel 8 breaking changes, we could stop doing this and perform much faster node building by specializing each builder function. Eg, t.identifer(name) can be (a little more than) function identifier(name) { return { type: 'Identifier', name } }.
We support swapping the parser and the generator, but not the other packages.
You can handle custom AST modifications by changing VISITOR_KEYS.
On the other hand, I don't see why someone would want to change BUILDER_KEYS (you can just directly create the node without using the builder function).
On the other hand, I don't see why someone would want to change BUILDER_KEYS (you can just directly create the node without using the builder function).
In our codebase we don't mutate BUILDER_KEYS. I think we can expand builder keys in babel-types from Babel 8 and leave a note that the BUILDER_KEYS export is for reference only, it does not change the builder behavior.
On VISITOR_KEYS, I think we can offer an overrideVisit(originalVisit) API for those mutating VISITOR_KEYS: So we can expand VISITOR_KEYS in babel-traverse, too. It should remove the slow object access due to dynamic property access on different AST nodes. TS expands visitor keys, too.
The text was updated successfully, but these errors were encountered:
💻
From #13843 (review):
@jridgewell
@nicolo-ribaudo
@JLHwung
The text was updated successfully, but these errors were encountered: