Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
36476
c87a7752 Merge branch 'master' into fix/e2e-rspack-npm-esm
by Jason Jean
Failed
36476
Environment issue→
b624b9ec cleanup(rspack): trim comments in create-compiler and load-rspack-core Condense multi-paragraph comments explaining the ESM lazy-load workaround down to short one-line why-comments.
by Claude
Failed
36476
Flaky task→
3989ae92 chore: retrigger ci The e2e-release failure is unrelated to this PR's rspack change: verdaccio fails to start with ERR_PACKAGE_PATH_NOT_EXPORTED for './bin/verdaccio' (packages/js/src/executors/verdaccio/verdaccio.impl.ts), a pre-existing environment/dependency issue outside packages/rspack. Retriggering CI.
by Claude
Canceled
36476
fc0c0769 fix(rspack): lazy-load @rspack/core in create-compiler to avoid eager ESM resolution PR #35682 (feat(rspack): support @rspack/core@2 and @rsbuild/core@2) added lazy `require('@rspack/core')` calls in apply-base-config.ts and apply-web-config.ts to avoid resolving the pure-ESM `@rspack/core@2` entry at module parse time, but missed create-compiler.ts, which still had a top-level value import (`import { rspack, ... } from '@rspack/core'`). That file is imported at the top of the `@nx/rspack:rspack` and `@nx/rspack:dev-server` executors, so simply loading either executor forced Node to resolve `@rspack/core` immediately, before any build ran and before a `Compiler` instance (with its own already-resolved `compiler.rspack`) existed to reuse. This is consistent with the nightly E2E matrix failures in `e2e-rspack` on Linux/npm and MacOS/npm since 2026-06-19 (yarn/pnpm resolve `node_modules` more strictly and didn't hit this). Extracts the existing `compiler.rspack ?? require('@rspack/core')` pattern into a shared `loadRspackCore()` helper and uses it consistently across apply-base-config.ts, apply-web-config.ts, and now create-compiler.ts, so there is exactly one lazy resolution path instead of ad-hoc duplicates. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XC8aq1sMkkbhjCChXcvZzh
by Claude
Failed
36476
Environment issue→
fc0c0769 fix(rspack): lazy-load @rspack/core in create-compiler to avoid eager ESM resolution PR #35682 (feat(rspack): support @rspack/core@2 and @rsbuild/core@2) added lazy `require('@rspack/core')` calls in apply-base-config.ts and apply-web-config.ts to avoid resolving the pure-ESM `@rspack/core@2` entry at module parse time, but missed create-compiler.ts, which still had a top-level value import (`import { rspack, ... } from '@rspack/core'`). That file is imported at the top of the `@nx/rspack:rspack` and `@nx/rspack:dev-server` executors, so simply loading either executor forced Node to resolve `@rspack/core` immediately, before any build ran and before a `Compiler` instance (with its own already-resolved `compiler.rspack`) existed to reuse. This is consistent with the nightly E2E matrix failures in `e2e-rspack` on Linux/npm and MacOS/npm since 2026-06-19 (yarn/pnpm resolve `node_modules` more strictly and didn't hit this). Extracts the existing `compiler.rspack ?? require('@rspack/core')` pattern into a shared `loadRspackCore()` helper and uses it consistently across apply-base-config.ts, apply-web-config.ts, and now create-compiler.ts, so there is exactly one lazy resolution path instead of ad-hoc duplicates. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XC8aq1sMkkbhjCChXcvZzh
by Claude
Failed
36476
Flaky task→
fc0c0769 fix(rspack): lazy-load @rspack/core in create-compiler to avoid eager ESM resolution PR #35682 (feat(rspack): support @rspack/core@2 and @rsbuild/core@2) added lazy `require('@rspack/core')` calls in apply-base-config.ts and apply-web-config.ts to avoid resolving the pure-ESM `@rspack/core@2` entry at module parse time, but missed create-compiler.ts, which still had a top-level value import (`import { rspack, ... } from '@rspack/core'`). That file is imported at the top of the `@nx/rspack:rspack` and `@nx/rspack:dev-server` executors, so simply loading either executor forced Node to resolve `@rspack/core` immediately, before any build ran and before a `Compiler` instance (with its own already-resolved `compiler.rspack`) existed to reuse. This is consistent with the nightly E2E matrix failures in `e2e-rspack` on Linux/npm and MacOS/npm since 2026-06-19 (yarn/pnpm resolve `node_modules` more strictly and didn't hit this). Extracts the existing `compiler.rspack ?? require('@rspack/core')` pattern into a shared `loadRspackCore()` helper and uses it consistently across apply-base-config.ts, apply-web-config.ts, and now create-compiler.ts, so there is exactly one lazy resolution path instead of ad-hoc duplicates. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XC8aq1sMkkbhjCChXcvZzh
by Claude