GO — Healthy across the board

• Last commit 3d ago
• 26+ active contributors
• Distributed ownership (top contributor 22% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Boa is a JavaScript engine written in Rust that lexes, parses, and interprets ECMAScript code with ~90% spec conformance. It embeds directly into Rust applications via the boa_engine crate and runs in WASM via the live playground at boajs.dev/playground. The core value is providing a performant, maintainable JavaScript runtime without depending on V8 or SpiderMonkey. Monorepo with workspace structure: core/ contains engine crates (ast, parser, engine, gc, interner, runtime, string, macros, icu_provider), utils/ has shared utilities (tag_ptr, small_btree), cli/ provides the REPL, tools/ houses development utilities, tests/ includes test262 conformance. Each major component is a separate crate with independent Cargo.toml.

Rust developers embedding a scripting engine in applications (game engines, configuration systems, automation tools), and contributors building JavaScript language implementations. Also targets WASM/browser users wanting to run JavaScript without external runtimes.

Actively maintained with strong CI/CD (10+ GitHub Actions workflows), extensive test262 conformance testing, and version 1.0.0-dev in development. The codebase is substantial (8.3M lines of Rust), modular across 10 published crates, and has Codecov integration. Verdict: production-ready for embedded use with ongoing spec compliance improvements.

Moderate risk: single organization (boa-dev) maintains this, version 1.0.0-dev indicates potential breaking changes ahead, and the cutting-edge nature of JavaScript spec compliance means edge cases may exist. Dependency footprint is reasonable but includes heavy lifting (ICU4X for internationalization, num-bigint for arbitrary precision). Recommend pinning to releases rather than using -dev.

The project is in active development toward version 1.0.0-dev with Rust 1.91.0 MSRV. Test262 conformance testing is automated via multiple workflows (test262.yml, test262_release.yml). Recent focus appears to be on WebAssembly support (webassembly.yml workflow), security auditing, and release automation. The edition is set to 2024, indicating use of latest Rust features.

git clone https://github.com/boa-dev/boa
cd boa
cargo build
cargo test
cargo run --bin boa_cli  # Start interactive REPL

Daily commands: Development: cargo test (runs all tests). REPL: cargo run --bin boa_cli. Specific crate: cargo run -p boa_engine. Benchmarks: cargo bench (from benches/ directory). Conformance: cargo test --all includes test262 suite.

• Cargo.toml — Root workspace configuration defining all 600 files, member crates (core, ffi, tests, tools), and shared dependencies for the entire JavaScript engine.
• core/engine/Cargo.toml — Core engine crate manifest; defines the primary execution runtime and bytecode interpreter that all other modules depend on.
• core/ast/Cargo.toml — Abstract syntax tree definitions; foundational to lexing, parsing, and compilation stages that feed the engine.
• core/parser/Cargo.toml — ECMAScript parser crate converting source text into AST; critical path for JavaScript intake and validation.
• cli/src/debug/mod.rs — CLI debugging interface and introspection tools; primary user entry point for interactive REPL and script execution.
• .github/workflows/test262.yml — Test262 compliance automation; validates 90%+ ECMAScript spec adherence across commits.
• README.md — Project overview documenting Boa's scope as an embeddable JS engine, supported features, and design philosophy.

Add a new built-in object or method

1. Define the native function implementation in a new module under core/builtins/src/ (core/builtins/src/my_builtin.rs (new file))
2. Export and register the function in core/builtins/src/lib.rs in the appropriate object prototype initialization (core/builtins/src/lib.rs)
3. Add test cases in a corresponding _tests module to validate behavior against ECMAScript spec (core/builtins/src/my_builtin.rs (test module))

Implement a new ECMAScript language feature

1. Extend the AST node definitions to represent the new syntax structure (core/ast/src/statement.rs or core/ast/src/expression.rs (add enum variant))
2. Add parser rules to handle the new syntax in the relevant parser module (core/parser/src/statement/mod.rs or core/parser/src/expression/mod.rs)
3. Implement bytecode generation in the compiler to handle the new AST node (core/engine/src/bytecompiler/mod.rs (add compilation logic))
4. Implement bytecode interpretation in the VM execution loop (core/engine/src/vm/code_block.rs or core/engine/src/vm/mod.rs)
5. Add Test262 test files and validate conformance (tests/test262/ (add test suite or verify existing coverage))

Debug and optimize performance

1. Run or create a benchmark script in benches/scripts/ targeting the slow operation (benches/scripts/properties/access.js or benches/scripts/my_benchmark.js (new file))
2. Execute the benchmark and profile using the Makefile.toml task or cargo bench (Makefile.toml)
3. Use CLI debugger tools (gc, optimizer, shape introspection) to identify hotspots (cli/src/debug/optimizer.rs or cli/src/debug/gc.rs)
4. Optimize the identified component and re-benchmark to validate improvement (benches/benches/scripts.rs (or relevant core crate))

• Rust — Memory safety without GC overhead; enables embeddings in systems without garbage collection; enables WebAssembly compilation; zero-cost abstractions for tight VM loops.
• Bytecode VM (not AST interpreter) — Eliminates repeated AST traversal; enables JIT-friendly code; supports optimization passes (constant folding, dead code elimination).
• Shape descriptor & property caching — O(1) property lookups on common objects; reduces prototype chain walks; enables monomorphic optimization.
• Workspace monorepo (core, ffi, tools, tests) — Modular boundaries (parser, ast, engine, builtins); independent versioning; enables optional features (INTL, regex) without bloat.
• Test262 continuous validation — Enforces ECMAScript spec compliance at scale; detects regressions automatically; tracks progress toward 90%+ conformance goal.

• Bytecode VM over JIT compilation

  • Why: Simpler initial implementation; predictable performance for embeddings; sufficient for most use cases.
  • Consequence: Lower peak throughput than V8/SpiderMonkey; no adaptive optimization; warm-up time for hot code paths.

• Conservative mark-sweep GC over incremental/generational

  • Why: Simpler implementation; correctness guarantees; easier to embed.
  • Consequence: Longer pause times on large heaps; unsuitable for real-time / low-latency applications; memory overhead.

• Single-threaded execution model (no threads in VM)

  • Why: Eliminates synchronization complexity; matches browser JavaScript semantics; easier to embed.
  • Consequence: No parallelism for I/O-bound operations; no multi-core utilization; user must manage concurrency via Rust async/channels.

• No tier-2 compilation or baseline JIT

  • Why: Reduces engineering scope; keeps codebase maintainable.
  • Consequence: Performance ceiling lower than production JS engines; better suited for scripting than compute-intensive workloads.

• Real-time or low-latency execution (GC pauses incompatible with hard deadlines)
• 100% ECMAScript specification compliance (target is 90%+; legacy/rarely-used features may be incomplete)
• Node.js API compatibility (Boa is a core engine, not a runtime; no fs, net, process modules)
• Multi-threaded JavaScript execution (single-threaded model enforced; embedder manages concurrency in Rust)
• Performance parity with V8/SpiderMonkey (Boa optimizes for simplicity, safety, and embeddings, not peak throughput)
• Native code generation or adaptive optimization (no JIT tier-up; static bytecode dispatch only)

Feature flags matter: boa_engine has default-features = false in workspace deps; check individual crate Cargo.toml for what's enabled (regex, intl, etc.). Rust edition 2024: ensure MSRV 1.91.0+ or builds fail. Test262 tests are separate: tests/test262/ excluded from default runs; use cargo test --all to include them. GC integration is mandatory: you cannot allocate JS values without going through the GC; raw pointers will not work. String interning required: strings must be interned via Interner before use in values; hard to debug if skipped.

• Abstract Syntax Tree (AST) — Boa's parser converts JavaScript source into an AST (defined in boa_ast crate) which the interpreter walks; understanding AST structure is essential for adding language features or debugging parsing failures
• Garbage Collection (Mark-and-Sweep) — Boa uses a custom GC in boa_gc to manage JavaScript heap objects; misunderstanding GC integration causes memory leaks or dangling references in Rust's safe abstractions
• String Interning — Boa's boa_interner crate deduplicates strings in memory; string operations rely on intern IDs not raw strings, which affects memory layout and comparisons
• Tagged Pointers — Boa uses the tag_ptr utility crate to pack type information into pointer bits; this reduces memory overhead for JsValue but requires careful pointer arithmetic
• ECMAScript Specification Conformance (Test262) — Boa measures correctness against the official TC39 test262 suite; understanding how tests validate spec compliance is critical for pull requests and debugging edge cases
• Bytecode Compilation vs. Tree-Walking Interpretation — Boa currently uses tree-walking (AST interpreter) rather than bytecode; understanding this tradeoff matters for performance optimization PRs and potential future VM refactors
• ICU (International Components for Unicode) — Boa integrates ICU4X via boa_icu_provider for Unicode, locale, and internationalization support; this dependency is heavy but required for spec-compliant string/number formatting

• denoland/deno — Uses V8 for JavaScript execution; Boa is an alternative for embedded scenarios where V8's size/complexity is overkill
• swc-project/swc — Rust-based JavaScript parser/transpiler; Boa's parser shares similar challenges but Boa focuses on execution vs. transpilation
• RustPython/RustPython — Parallel project implementing Python in Rust; both solve 'embeddable language runtime' problem with similar architecture (lexer→parser→interpreter)
• bytecodealliance/wasmtime — Boa targets WASM deployment; Wasmtime is the execution environment for Boa's WASM builds
• tc39/test262 — Official ECMAScript conformance test suite that Boa runs against; defines spec compliance targets

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test262 compliance tracking dashboard and reporting

The repo has test262 workflows (.github/workflows/test262.yml, test262_comment.yml, test262_release.yml) but lacks a structured system to track which ECMAScript features have conformance gaps. With 90%+ compliance claimed, contributors need visibility into remaining failures. Create a test results aggregation tool that parses test262 outputs and generates a detailed conformance matrix (by spec section/feature) that can be displayed in the README or a dedicated docs page. This helps new contributors identify high-value fixes.

• [ ] Create tools/test262-analyzer/ crate to parse test262 JSON results
• [ ] Generate conformance-matrix.json mapping ECMAScript features to pass/fail counts
• [ ] Add a GitHub Actions step in .github/workflows/test262_release.yml to artifact the matrix
• [ ] Document in CONTRIBUTING.md how to use this data to find fixable issues

Add integration tests for FFI crate public API stability

The workspace includes ffi/* members (visible in Cargo.toml members list) for embedding Boa, but there are no dedicated tests in tests/ directory validating FFI API contracts. New versions could break embedders. Create a dedicated test suite that verifies FFI function signatures, error handling, and GC integration remain stable across changes.

• [ ] Create tests/ffi-integration/ directory with Cargo project
• [ ] Add tests for core FFI scenarios: creating contexts, executing scripts, calling Rust from JS
• [ ] Add tests verifying GC handles don't leak across FFI boundaries
• [ ] Update .github/workflows/pull_request.yml to run FFI integration tests on all PRs

Add benchmarking regression detection CI workflow

The repo has benches/benches/scripts.rs and comprehensive benchmark scripts, but no automated regression detection. Performance regressions can silently accumulate. Create a CI workflow that compares benchmark results against the main branch and comments on PRs if regressions exceed a threshold (e.g., >5% slowdown).

• [ ] Create .github/workflows/benchmark.yml that runs benches/ on PR and main branch
• [ ] Use a tool like criterion or custom script to compare JSON outputs
• [ ] Post comments on PRs when performance regressions detected (with detailed breakdown by benchmark)
• [ ] Document in CONTRIBUTING.md how to run benchmarks locally before submitting performance-critical PRs

• Add comprehensive error message tests for parser failures in tests/ — many edge cases in ES6 syntax (destructuring, arrow functions) lack explicit test coverage. Start by adding .js files that should fail and assert error messages.
• Expand missing ECMAScript builtin method coverage: audit core/engine/src/builtins/string.rs and array.rs against MDN for methods marked 'TODO' or absent (e.g., String.prototype.replaceAll, Array.prototype.findIndex on some versions). Pick one method and add full implementation + tests.
• Document the GC integration pattern with a tutorial in /CONTRIBUTING.md: explain how JsValue allocation requires GcObject::new(), show the pattern in core/engine/src/value/, and provide 2-3 before/after code examples for new contributors.

The Boa JavaScript engine project demonstrates reasonable security practices with a clear security policy, active vulnerability reporting process via Matrix, and organized CI/CD workflows including security audits. However, there are moderate concerns: incomplete dependency specifications in the configuration suggest potential versioning issues, the pre-release version designation indicates active development rather than production-ready code, and excluded fuzz tests reduce the effectiveness of security testing. The project's Rust implementation provides inherent memory safety benefits. Recommendations focus on completing dependency specifications, improving fuzz test integration across platforms, and clearly documenting the pre-release nature of 1.0.0-dev versions for end users.

• Medium · Incomplete Dependency Specification — Cargo.toml - [workspace.dependencies] section. The workspace.dependencies section in Cargo.toml appears truncated (oneshot = '0.' is incomplete). This could indicate missing or improperly pinned dependency versions, potentially leading to unexpected updates or incompatible versions being pulled during build. Fix: Complete and verify all dependency versions are properly specified with exact or conservative version constraints. Ensure all dependencies are fully listed and use lock file (Cargo.lock) for reproducible builds.
• Low · Pre-release Version in Production Use — Cargo.toml - [workspace.package] version field. The workspace is versioned as '1.0.0-dev' which is a development/pre-release version. This version should not be used in production environments as it may contain unstable APIs and unvalidated security fixes. Fix: Reserve 1.0.0-dev versions for development and testing only. Once ready for production, release a stable version (e.g., 1.0.0). Document the stability guarantees for each release.
• Low · Dual Licensing May Introduce Legal Complexity — Cargo.toml and LICENSE files. The project uses dual licensing (Unlicense OR MIT). While both are permissive, dual licensing can create confusion about which license applies and may complicate compliance tracking. Fix: Clearly document in README and contributing guidelines which license is preferred. Ensure all source files have explicit license headers. Consider using SPDX identifiers consistently.
• Low · Fuzz Testing Directory Explicitly Excluded — Cargo.toml - [workspace] exclude section. The fuzz testing directory is excluded from default test runs 'because it does weird things on Windows tests'. This could mask security-relevant bugs that fuzzing would otherwise detect. Fix: Investigate and fix the Windows compatibility issues with fuzz tests. Include fuzz tests in CI/CD pipelines, potentially with platform-specific configurations. Regular fuzzing is important for finding memory safety issues in a JavaScript engine.
• Low · Missing Dependency Audit Workflow Verification — .github/workflows/security_audit.yml. While a security_audit.yml workflow exists, the provided configuration snippets don't show its implementation details. Given the complexity of Rust dependencies, ensure regular audits are actually running. Fix: Verify that 'cargo audit' or similar tools are configured to run on every pull request and release. Set the workflow to fail on vulnerable dependency detection. Keep the Cargo.lock file committed to ensure reproducible builds.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/boa-dev/boa shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live boa-dev/boa repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/boa-dev/boa.

What it runs against: a local clone of boa-dev/boa — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in boa-dev/boa | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of boa-dev/boa. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/boa-dev/boa.git
#   cd boa
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of boa-dev/boa and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "boa-dev/boa(\\.git)?\\b" \\
  && ok "origin remote is boa-dev/boa" \\
  || miss "origin remote is not boa-dev/boa (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "core/engine/Cargo.toml" \\
  && ok "core/engine/Cargo.toml" \\
  || miss "missing critical file: core/engine/Cargo.toml"
test -f "core/ast/Cargo.toml" \\
  && ok "core/ast/Cargo.toml" \\
  || miss "missing critical file: core/ast/Cargo.toml"
test -f "core/parser/Cargo.toml" \\
  && ok "core/parser/Cargo.toml" \\
  || miss "missing critical file: core/parser/Cargo.toml"
test -f "cli/src/debug/mod.rs" \\
  && ok "cli/src/debug/mod.rs" \\
  || miss "missing critical file: cli/src/debug/mod.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/boa-dev/boa"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.