Support version switching for oxfmt, oxlint, and the core

[Dunqing]

Feature Request

Problem

The oxc playground currently uses the oxc-playground package which is built locally from the main oxc repository (napi/playground) and is not published to npm. This architecture makes it challenging to support version switching, as there's no straightforward way to fetch or load different versions of the playground package.

The oxc project maintains three independent version streams:

• oxfmt_vX.X.X - Formatter app releases
• oxlint_vX.X.X - Linter app releases
• crates_vX.X.X - Core crates releases

Users would benefit from being able to switch between versions of these components in the playground to:

• Test code against different versions
• Reproduce bugs reported in specific versions
• Compare behavior across versions
• Validate fixes and new features

Desired Behavior

• Add UI controls (e.g., dropdowns) to select versions for oxfmt, oxlint, and core crates independently
• Load and execute playground code against the selected versions
• Display the currently active version for each component clearly in the UI
• Support switching between versions without page reload if possible

Technical Challenges

1. No npm distribution: The oxc-playground package is private and not published, making traditional version management difficult
2. Multiple version streams: Need to support three independent release tracks
3. Build and hosting: Would require pre-building WASM binaries for each version/tag and hosting them
4. Infrastructure costs: Storage and bandwidth for serving multiple versions of WASM binaries
5. Bundle size: Loading multiple versions could significantly increase initial load time

Potential Implementation Approaches

Option 1: Publish Versioned Packages to npm

• Publish @oxc/playground-oxfmt, @oxc/playground-oxlint, @oxc/playground-crates to npm
• Version them according to their respective release tags
• Load from npm CDN (e.g., unpkg, jsdelivr) dynamically
• Pros: Standard package distribution, reliable CDN
• Cons: Requires publishing infrastructure and maintenance

Option 2: Host Pre-built WASM Binaries

• Build WASM binaries for each tagged version in CI/CD
• Host on GitHub Releases or dedicated CDN
• Fetch and load dynamically based on user selection
• Pros: No npm publishing needed, direct control
• Cons: Custom hosting solution, bandwidth costs

Option 3: On-Demand Building

• Build requested versions on-demand server-side
• Cache built versions for subsequent requests
• Pros: No storage of all versions upfront
• Cons: Slow first load, complex infrastructure, resource intensive

Option 4: Limited Version Support

• Only support latest stable + main branch
• Document why full version switching isn't available
• Pros: Simple, maintains current architecture
• Cons: Limited utility for version comparison

Recommendation

1. Evaluate community demand for version switching feature
2. Assess infrastructure costs for hosting multiple WASM builds
3. Consider starting with Option 2 (host pre-built binaries) for recent major versions only
4. Implement lazy loading to minimize initial bundle size impact
5. If not feasible, document current limitations in the playground UI/README

References

• oxc-playground package source
• oxc version tags
• Playground repository

[sxzz]

This a Vue SFC project, and oxc doesn't support Vue SFC currently, right?