CodeVetter · Repo Unpack · Contributor handoff
web-infra-dev/rspack
Use this brief as a source map for the pinned commit, then recheck the exact subsystem before editing. Tests and CI were inspected, not executed, and the bounded inventory does not establish exhaustive coverage or passing behavior. Repository conventions require building consumed artifacts before validation and reusing existing test harnesses. Cache ownership, native lifetimes, and hook ordering deserve focused attention because changes cross runtime boundaries.
- For future authorized validation, build JS changes with build:js, Rust changes with build:binding:dev, or both with build:cli:dev before running tests that consume those artifacts.
- Focused integration validation uses pnpm --dir tests/rspack-test run test -t followed by a case pattern; base, HMR, E2E, type, and Rust checks have separate documented commands.
- Add JavaScript cases beneath existing case directories and reuse runners; AGENTS.md forbids ordinary new inline/crate-local Rust tests despite the testing guide's older inline-test example.
- Before binding changes, account for both conversion directions, native-backed wrapper access windows, stale-target policies, and compiler-scoped thread-safe callback release.
- Cache edits must preserve independence from incremental recovery: cache:false cannot clear IncrementalPasses, incremental:false cannot disable cache lookup/storage, and prior compilations belong to IncrementalArtifacts.
- Scheduling edits should follow the documented preference for Rayon for synchronous CPU work and rspack_parallel for async orchestration; asset emission already uses a semaphore-limited parallel scope.
- Public behavior changes require relevant English and Chinese documentation and the PR template; compatibility policy permits documented limitations, and the support table explicitly records partial plugin support.
- Use the pinned nightly toolchain and pnpm version, and check Clone/error-handling conventions before Rust edits; inspected test scripts and CI definitions are validation instructions, not evidence that checks passed.