Split long-running CJS workflow into typecheck + sharded test jobs

[Copilot]

cjs.yml currently runs JS typecheck and all tests in a single long-running job, creating a bottleneck for CI latency and failure triage. This change separates concerns and parallelizes the slow path by sharding tests across matrix jobs.

• Workflow restructuring

  • Replaced the single js job with:
    • js-typecheck for standalone TypeScript validation
    • js-tests as a 4-way matrix (shard: [1,2,3,4]) for parallel test execution
  • Kept existing lint-js behavior and triggers intact.

• Execution model

  • js-tests now runs Vitest with explicit shard selection per matrix entry.
  • Retained --no-file-parallelism to keep shard scheduling deterministic.

• Concurrency isolation

  • Introduced per-job concurrency groups (js-typecheck, js-tests-<shard>) to reduce cancellation contention and avoid cross-job interference.

js-tests:
  strategy:
    matrix:
      shard: [1, 2, 3, 4]
  steps:
    - name: Run tests
      run: cd actions/setup/js && npm run test:js -- --no-file-parallelism --shard=${{ matrix.shard }}/4

[Copilot]

Pull request overview

This PR restructures the cjs.yml GitHub Actions workflow to reduce CI latency and improve test parallelism by separating TypeScript typechecking from test execution and sharding JS tests across a matrix.

Changes:

• Replaced the single js job with a dedicated js-typecheck job.
• Added a js-tests job that runs tests in a 4-way shard matrix using Vitest sharding flags.
• Introduced per-job/per-shard concurrency groups to reduce cancellation contention.

Show a summary per file

File	Description
.github/workflows/cjs.yml	Splits typecheck from tests and runs JS tests in a 4-shard matrix with per-shard concurrency grouping.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 2

[Copilot]

The matrix strategy defaults to fail-fast: true, which will cancel the other test shards as soon as one shard fails. That undermines the stated goal of improving failure triage with sharded execution; consider setting strategy.fail-fast: false so all shards complete and report their failures.

Suggested change

	strategy:
	strategy:
	fail-fast: false

[Copilot]

The shard total (4) is hard-coded in multiple places (job name, --shard=…/4). This can drift if the matrix size changes; consider defining a single source of truth (e.g., an env var for total shards) and referencing it in the test command (and job name) to avoid mismatches.