Audit public APIs

[jedel1043]

In preparation for our 1.0 release, we should go through all our public APIs, then determine if they need changes to avoid breaking changes in the future, where possible.

Possible changes

• Use getters instead of public fields
• #[non_exhaustive]

[Jayant-kernel]

Hi Hi @jedel1043 I'd love to work on this for GSoC 2026.

Here's how I'd approach this:

Phase 1 — Discovery
→ Use cargo doc + cargo-public-api to map out everything that's currently exposed
→ Categorize into: types, traits, functions, feature flags

Phase 2 — Audit
→ Flag public fields that should be behind getters
→ Identify structs/enums missing #[non_exhaustive]
→ Spot anything that's pub but probably should be pub(crate)
→ Check for inconsistencies in naming, patterns, or conventions

Phase 3 — Propose & Refactor
→ Share an audit summary for maintainer review before touching code
→ Submit focused PRs — one concern at a time, easy to review

Phase 4 — Prevent Future Breakage
→ Explore adding cargo-semver-checks to CI
→ Document the stability guarantees for post-1.0

I'd love to start with a small PR to show my approach — maybe picking one crate and auditing its public surface. Are there any specific areas or crates you'd want me to prioritize first?

Also, are there any existing discussions around the 1.0 milestone I should catch up on?

[jedel1043]

@Jayant-kernel Thank you for your interest in this. We haven't really decided on what the overall list of changes is, so it might first require a discussion on which changes we want to do, and what we need to redesign.

[jedel1043]

I guess before the discovery phase, I would propose first doing a research on public Rust codebases with good code quality, and what is their stance on breaking changes + which changes they make to their APIs to ensure they can ship new features without pushing breaking changes.

[arnavsharma990]

Thanks for the direction @jedel1043 ! I’m also interested in contributing here.

I can help with the research phase by looking into how projects like tokio, serde, and rust analyzer manage API stability and semver guarantees.

If helpful, I can draft a short comparison summary so we can identify patterns relevant for Boa.

[Jayant-kernel]

Thanks @jedel1043 — research first makes total sense.

I've actually seen this up close with ICU4X — they went through the same 1.0 stabilization process. A few patterns that worked well for them:

-#[non_exhaustive] on enums/structs to keep new variants non-breaking
-Sealed traits where extensibility was needed without exposing internals
-Default to pub(crate), only promote to pub after deliberate review
-cargo-semver-checks in CI to catch accidental breakage early

I can put together a short comparison of how ICU4X, tokio, and serde handle this — what worked, what they'd do differently, and what's most relevant for Boa. Would a write-up on the discussion thread or as a gist work?

[jedel1043]

I would integrate a time for initial research in your GSOC proposal, to ensure fairness for every candidate.

[Jayant-kernel]

That's fair — I'll include the research phase as part of my GSoC proposal. Thanks for the guidance!

[lalamAnusha2027]

Informative for every freshers to go forward

[dev-gandhi]

Thanks for the feedback, @jedel1043! I really appreciate the direction and guidance. I agree that research should be the first step to understand how other successful Rust codebases handle API stability and breaking changes.

I’m excited to start with the research phase. Once I’ve gathered the info, I’ll share a draft for review.

would you recommend any specific areas to prioritize, or should I focus on a broad comparison across these projects? Let me know if there’s anything else I should keep in mind as I dive into this!

Looking forward to working on this!

[houd1ni]

Hey, guys! I'm not sure that it's the best place to ask, yet anyways, is it a paper anywhere how to add external APIs like filesystem or DB access into boa on high level ? I'm thinking of using it as an engine in edge devices, being more a NodeJS dev, interested in Rust ecosystem.