The project has grown through many feature and parity slices, and its structure is becoming harder to navigate. A few areas would benefit from a gradual cleanup:
- Huge implementation files. Heap, compiler, runtime, VM, tests, and some tooling combine several responsibilities in single files. The binary-object boundary checker is one example where splitting responsibilities would help beyond just moving the script into a directory.
- Unclear module boundaries. Shared parent state, broad imports, and mixed responsibilities make it difficult to see where a change belongs and which parts of the engine it affects.
- Scattered tests. Top-level oracle wrappers, nested suites, unit tests, shared helpers, and test data follow different layout conventions.
- Mixed tooling. Architecture checks, conformance tooling, upstream oracle builds, Unicode generators, and web scripts share a mostly flat directory.
- Generated data beside handwritten code. Generated tables are mixed with the implementation that consumes them.
The motivation is broader than reducing file sizes. Clearer ownership and responsibility boundaries would make Rust–JavaScript interoperability easier to develop and use: evaluating JS from Rust, calling JS functions, exposing Rust callbacks, and moving values and exceptions across the boundary should have recognizable implementation paths.
This would also help keep the engine core focused on representation, storage, and memory management, with clearer separation from execution semantics, embedding conveniences, and platform adapters. That separation should make future core optimization and extension easier to reason about and keep changes localized. It does not imply a performance or binary-size improvement by itself.
A possible approach is to split implementations along existing responsibilities, clarify dependencies and visibility, and then organize tests, tooling, and generated sources more consistently. This can proceed through several focused PRs as the boundaries become clearer.
The initial cleanup would preserve existing behavior and public Rust import paths within the current crate layout. A Cargo multi-crate split, public API redesign, and new interop capabilities can be discussed separately; this work would help prepare for them.
The project has grown through many feature and parity slices, and its structure is becoming harder to navigate. A few areas would benefit from a gradual cleanup:
The motivation is broader than reducing file sizes. Clearer ownership and responsibility boundaries would make Rust–JavaScript interoperability easier to develop and use: evaluating JS from Rust, calling JS functions, exposing Rust callbacks, and moving values and exceptions across the boundary should have recognizable implementation paths.
This would also help keep the engine core focused on representation, storage, and memory management, with clearer separation from execution semantics, embedding conveniences, and platform adapters. That separation should make future core optimization and extension easier to reason about and keep changes localized. It does not imply a performance or binary-size improvement by itself.
A possible approach is to split implementations along existing responsibilities, clarify dependencies and visibility, and then organize tests, tooling, and generated sources more consistently. This can proceed through several focused PRs as the boundaries become clearer.
The initial cleanup would preserve existing behavior and public Rust import paths within the current crate layout. A Cargo multi-crate split, public API redesign, and new interop capabilities can be discussed separately; this work would help prepare for them.