RFC: ECS design for semantics analyzer

[TzviPM]

What is an ECS

Paraphrased from the Bevy engine docs

The Entity Component System paradigm, which is often shortened to ECS, is often used in game engine design. ECS is a software pattern that involves breaking your program up into Entities, Components, and Systems. Entities are unique "things" that are assigned groups of Components, which are then processed using Systems. This is often done in some sort of run loop.

For example, one entity might have a Position and Velocity component, whereas another entity might have a Position and UI component. Systems are logic that runs on a specific set of component types. In a game, you might have a movement system that runs on all entities with a Position and Velocity component.

The ECS pattern encourages clean, decoupled designs by forcing you to break up your app data and logic into its core components. It also helps make your code faster by optimizing memory access patterns and making parallelism easier.

How does this apply to compiler design?

There's a great video by Andrew Kelley, the creator of the Zig programming language on data-oriented design in compilers. The ECS model is just a more formal technique for doing that type of design that's used in game engines.

For example, some entities we would be dealing with are: AST nodes, CFG blocks, Symbol entries.
Components could include: Type, associations such as AST->CFG nodes or AST->Symbol nodes (bindings).
Systems could include the CFG system, the Binding system, the Types system. Linting rules would also be able to define their own components, such as a component on a CFG node called super was called or this was called before super the rules themselves are a sort of system.

Why?

As oxc gets more complex, we will start to see more fine-grained dependencies between parts of the compiler. For example, lint rules may depend on bindings or CFG nodes or types. Not every rule will depend on every component and some may even provide components for other rules to depend on. For example, contructor_super and no_this_before_super might both need information about super_was_called on a CFG node.

The ECS model allows us to define explicit opportunities for more fine-grained parallelism as well as take advantage of memory access patterns such as cache block sizes when using only a subset of components to traverse a multitude of AST or CFG nodes.

[Boshen]

Comment from Joe: https://twitter.com/en_JS/status/1752574528146768303

[Boshen]

After reading Joe's comments and thinking about this topic, here's what I think:

We have several usage targets:

1. IDE
2. publish as crate for people to build their own tools (think cargo, codemods, custom linters etc)
3. different tools compiled as separate binaries (oxlint, oxformat, oxminify) or combined as one binary:
4. Bundler

In order to support all these usages, consumers should be able to selectively build some the semantic data in a single AST pass.

The current strategy is to add features flags in the semantic builder, which obviously doesn't scale well.

Architectures such as ECS or query-based system (https://github.com/salsa-rs/salsa) may scale well but they may impede contributions if not done well.

---

If we were to explore, a prototype (using https://crates.io/crates/bevy_ecs?) for symbols and scopes would be nice.

For example, we are currently having difficulties with syncing new symbols and scopes in the transformer (https://babel.dev/docs/babel-plugin-transform-classes).