ci: breakdown wasm CI build

[ematipico]

Summary

This PR breaks down the WASM build using the matrix strategy. This should speed up our releases.

I wrote the initial refactor manually, then I asked Claude Code to validate them, which then found a small bug and fixed.

Test Plan

CI green. Then merge it. I will then trigger a preview release to validate the changes

Docs

[changeset-bot]

⚠️ No Changeset found

Latest commit: f3f0fa9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

This pull request refactors two GitHub Actions workflow files to use matrix strategies. The Build WASM jobs in both preview.yml and release.yml are updated to consolidate three separate build steps (for bundler, nodejs, and web targets) into a single parameterised step that runs across matrix configurations. Static artifact upload paths are replaced with dynamic paths that reference the matrix target value, eliminating code duplication.

Suggested reviewers

• siketyan
• dyc3
• arendjr

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: refactoring WASM CI builds using a matrix strategy to parallelise builds across multiple targets.
Description check	✅ Passed	The description is clearly related to the changeset, explaining the motivation (speeding up releases), approach (matrix strategy), and test plan (CI validation then preview release).
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ci/break-down-wasm-build

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8e97b89 and f3f0fa9.

📒 Files selected for processing (2)

• .github/workflows/preview.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)

🔇 Additional comments (6)

.github/workflows/preview.yml (3)

157-165: Matrix strategy consolidates three build targets cleanly.

The matrix approach is well-structured and aligns with the pattern used in parallel CLI builds elsewhere in the workflow.

---

173-174: Verify build output path matches artifact upload path.

The build step uses --out-dir ../../packages/@biomejs/${{ matrix.target }}, but the artifact upload (line 181) expects files at ./packages/@biomejs/${{ matrix.target }}. From the repository root (where steps execute), the path ../../packages would traverse up two levels, which seems incorrect.

Please verify that wasm-pack creates files in the expected location. If the artifact upload step fails with if-no-files-found: error, the paths are misaligned.

You can verify this by:

1. Checking the directory structure to confirm the relative path is correct
2. Running a test workflow and confirming the WASM artifacts upload successfully

---

179-181: Artifact naming and pattern look correct.

Using wasm-${{ matrix.target }} for the artifact name ensures each matrix instance produces uniquely named artifacts, and the glob pattern used during download (wasm-*) will match all of them.

.github/workflows/release.yml (3)

245-253: Matrix configuration is consistent with preview.yml.

Identical matrix structure across both workflows is good for maintainability and clarity.

---

261-262: Verify build output path matches artifact upload path.

Same concern as preview.yml (line 173-174): the build command uses ../../packages/@biomejs/${{ matrix.target }} whilst the artifact upload expects ./packages/@biomejs/${{ matrix.target }}.

Please confirm the paths align and the artifacts upload successfully during your test run.

---

264-270: Job dependencies are correctly configured.

The publish-cli job depends on build-wasm via needs: (line 328), which automatically ensures all three matrix instances complete before publishing. Artefact download pattern (wasm-*) with merge-multiple: true will correctly consolidate outputs from all matrix runs.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}