Skip to content

chore(axe-core): .npmrc supply-chain hardening + esbuild 0.19 upgrade (AXE-3444)#238

Open
rajathmr2000 wants to merge 4 commits into
mainfrom
AXE-3444-npmrc-hardening-esbuild-0.19
Open

chore(axe-core): .npmrc supply-chain hardening + esbuild 0.19 upgrade (AXE-3444)#238
rajathmr2000 wants to merge 4 commits into
mainfrom
AXE-3444-npmrc-hardening-esbuild-0.19

Conversation

@rajathmr2000

Copy link
Copy Markdown
Collaborator

Test/combined branch. This bundles the AXE-3444 .npmrc hardening (same as #236) plus an esbuild upgrade that makes the hardened build pass. If CI/validation is green here, we adopt this branch/PR instead of #236.

Why

The AXE-3444 supply-chain hardening adds ignore-scripts=true to .npmrc. But axe-core builds with esbuild 0.10.2, an old version that downloads its native binary via a postinstall script — which ignore-scripts=true blocks. Result: npm run build fails with:

esbuild: Failed to install correctly
Make sure you don't have "ignore-scripts" set to true.

This broke the A11yEngineProductionPackagePublish pipeline at the Build DOM-Forge-Core stage.

What

  1. .npmrc hardening (from chore: harden .npmrc for supply-chain audit (AXE-3444) #236): ignore-scripts, strict-ssl, save-exact, audit-level=high, engine-strict, legacy-peer-deps=false + the CI esbuild-rebuild commits.
  2. esbuild 0.10.20.19.12 (this PR's addition). esbuild 0.16+ ships its binary as @esbuild/* optionalDependencies with no install script, so ignore-scripts=true no longer breaks the build — and no npm rebuild esbuild workaround is needed anywhere.

Net: hardening stays fully in force (audit-compliant) and the build works, with zero install-script execution for any package.

Validation so far

  • npm install under ignore-scripts=true — esbuild binary present via 23 @esbuild/* packages
  • npm run build on Node 22 — full pipeline Done., produces axe.js / axe.min.js
  • Build-order / memoize (#1433) checkaxe.run under jsdom executes end-to-end; memoized commons resolve; image-alt + link-name correctly detected
  • ⬜ Full Karma test suite — pending
  • ⬜ Real-browser color-contrast (jsdom can't run canvas) — pending
  • ⬜ Scan smoke test on live pages — pending

Notes

Relates to AXE-3444.

🤖 Generated with Claude Code

chikara1608 and others added 4 commits June 3, 2026 16:48
The weekly Enigma supply-chain audit (SC-12282) flagged this repo: the
committed .npmrc was missing the required hardening directives. Add
ignore-scripts, strict-ssl, save-exact, audit-level, engine-strict and
legacy-peer-deps. access=restricted is omitted intentionally — this is
a public repository, so the restricted-access directive does not apply.

ignore-scripts=true blocks dependency lifecycle scripts on install,
including esbuild's postinstall that downloads its native bundler
binary. Rebuild esbuild explicitly in the dependencies_unix job (the
only CI job that runs `npm ci`) so the cached node_modules carries the
binary to build_unix. chromedriver is unaffected — CI fetches it via
browser-driver-manager, not the npm install script. patch-package still
applies because build_unix runs `npm run prepare` explicitly, and
ignore-scripts only suppresses pre/post hooks around an explicit
`npm run`, not the invoked script itself.

Document the local-dev post-install steps in the developer guide.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The .npmrc supply-chain hardening sets ignore-scripts=true, which skips
esbuild's postinstall that fetches its native bundler binary. Every path
that installs deps and then builds (grunt -> esbuild) therefore broke:

- GitHub Actions `build` job (test.yml) failed with
  "esbuild: Failed to install correctly" at the esbuild:core grunt task.
- The standard-version `postbump` hook re-runs `npm ci` (wiping the binary)
  before `sri-update` -> `grunt build`, breaking the release / next_release
  pipelines (CircleCI release jobs and GitHub release.yml).
- The nightly `npm install w3c/...` steps re-resolve the whole dependency
  tree under ignore-scripts, skipping native postinstalls.

Fixes, keeping all six audit-required directives intact (access=restricted
is omitted because this is a public repo):

- test.yml: `npm rebuild esbuild --ignore-scripts=false` between ci and build
- package.json postbump: rebuild esbuild after its inner `npm ci`
- nightly jobs: `--ignore-scripts=false` on the trusted w3c installs
- .npmrc: drop internal tool/ticket reference from the comment

Verified: under ignore-scripts=true esbuild installs broken, and
`npm rebuild esbuild --ignore-scripts=false` runs install.js and restores
the working native binary.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nightly jobs used `npm install w3c/...#main --ignore-scripts=false`, which
re-enabled lifecycle scripts for the whole re-resolved dependency tree and
the untrusted w3c/*#main installs — defeating the ignore-scripts=true
hardening. Those jobs only consume the prebuilt artifact (test:act/test:apg
are mocha), so esbuild isn't needed there; drop the flag.

Also remove the verbose AXE-3444 comment blocks from the CI configs per
review feedback. The targeted `npm rebuild esbuild --ignore-scripts=false`
steps (single trusted package) stay, matching the tech spec's sanctioned
approach.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The AXE-3444 .npmrc hardening sets ignore-scripts=true, which suppressed
esbuild 0.10.2's postinstall that downloads its native binary, breaking
`npm run build` ("esbuild: Failed to install correctly"). esbuild 0.16+
ships its binary as @esbuild/* optionalDependencies with no install
script, so ignore-scripts=true no longer breaks the build and no
`npm rebuild esbuild` workaround is needed.

[a11y-critical]: build tooling for axe.js bundle; affects all packages.

Build verified on Node 22; axe.run smoke under jsdom passes (memoize/#1433
ordering OK, image-alt + link-name detected). Full Karma suite and
real-browser color-contrast validation still pending.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants