💻

• Would you like to work on this feature?

From #13843 (review):

@jridgewell

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 } }.

Re: #13843 (comment), #13843 (comment)

@nicolo-ribaudo

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).

@JLHwung

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.