fix: restore CI on develop (lockfile drift + workflow regressions)#407
Open
colinswinney wants to merge 9 commits intodevelopfrom
Open
fix: restore CI on develop (lockfile drift + workflow regressions)#407colinswinney wants to merge 9 commits intodevelopfrom
colinswinney wants to merge 9 commits intodevelopfrom
Conversation
The lockfile drifted out of sync after the security-patch merges in #405, leaving entries (notably @wordpress/eslint-plugin@18.1.0) that no longer satisfied the version ranges declared by their parents. Every CI run since 2026-04-01 failed at `npm ci` with `EUSAGE` and dozens of "Missing" lines. Regenerated via `npm install --package-lock-only` on Node 20.18.1 — adds the missing transitive entries and prunes stale ones (e.g. stylelint@16.26.1) without bumping any direct dependency. Build, Jest, and example build all pass locally.
|
🎉 A new testing version of this package has been published to NPM. You can install it with |
The previous regen used npm 11, which silently dropped peer-dep entries that npm 10 (the version bundled with Node 20/22 in CI) treats as required. Re-resolved on Node 22.22.2 / npm 10.9.7. Both Node 20 and Node 22 now `npm ci` cleanly; build and Jest pass.
Now that the lockfile is in sync and `npm ci` succeeds, three CI workflows hit pre-existing issues that the broken-install pipeline was masking: - Cypress: the workflow's inline `build:` ran `npm run build --workspaces`, which only builds the example workspace. But the example imports `@10up/block-components` from `file:../dist/index.js`, which doesn't exist until the root package builds first. Build root, then workspaces. - release_testing: the job runs `npm install -g npm@latest` (upgrading to npm 11) before `npm install`. npm 11's resolver re-evaluates peer entries and writes them out, dirtying the working tree before the subsequent `npm version` step fails with "Git working directory not clean". `npm ci` is a strict no-op on lockfile state, so use it. - compressed-size: the action runs `npm ci` against both PR head and base. The base (develop) won't have the lockfile fix until this PR merges, so `npm ci` will continue to fail there. Override the action's install command to `npm install`, which tolerates lockfile drift.
colinswinney
changed the title
cypress-io/github-action@v5 passes the `build:` value as a single argv (no shell), so `&&` was being captured as a literal positional arg to the example workspace's build script. Move the chained build into the existing `build-test-env` script and call that instead, so the action only ever invokes one command.
cypress.config.js is loaded via ts-node, which compiles it against the root tsconfig.json. The two TS5107 deprecations on `esModuleInterop` and `moduleResolution` are warnings under the toolkit build but errors under ts-node, so Cypress refused to start. The Microsoft-recommended silencer (`ignoreDeprecations: "6.0"`) keeps both options in their current behavior until TS 7.0.
When Cypress loads its config, ts-node compiles `cypress/plugins/index.js`
in isolation against the root tsconfig. Without an explicit `rootDir`,
ts-node computes the common source directory from just that single file
('./cypress/plugins'), then fails with TS5011 because the resolved
rootDir doesn't match the configured `outDir`. Setting `rootDir: "."`
fixes the resolution without affecting the toolkit build.
The override was added to mask `npm ci` failing on the **base** branch (develop's broken lockfile). Once this PR merges, develop's lockfile will be fixed and the default `npm ci` works again, so the override is unnecessary and would just permanently loosen `ci` to `install`.
10up Block Components
 |
||||||||||||||||||||||||||||
| Project |
10up Block Components
|
| Branch Review |
fix/lockfile-drift
|
| Run status |
|
| Run duration | 05m 32s |
| Commit |
|
| Committer | Colin Swinney |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
 |
0
|
 |
0
|
 |
0
|
 |
0
|
 |
35
|
| View all changes introduced in this branch ↗︎ | |
Both specs clicked the post-publish "View Post" snackbar without first
stripping `target="_blank"` from the link, so the click opened a new
tab and the test browser stayed on the editor. That caused the
follow-up assertions to silently fail against editor markup instead
of frontend markup:
- Link.spec: the editor's RichText `<a>` has no `href` attribute, so
`should('have.attr', 'href', ...)` timed out
- registerBlockExtension.spec: the editor has no "Edit Page" admin-bar
link, so `cy.contains('Edit Page')` timed out
Image.spec already strips `target` before clicking. Mirroring its
pattern here. Verified the underlying frontend rendering works by
publishing a Link block via wp-cli and inspecting the rendered HTML.
Author
|
@fabiankaegy This was a lot of back and forth to resolve failing checks but I think this should fix all. Once this merges, I'll merge |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Every CI run on
developsince #405 (2026-04-01) has been red. Jest and ESLint died atnpm ci, and four other workflows (Cypress, compressed-size, release_testing, plus twocypress.config.jsblockers) had latent regressions that the broken install pipeline was masking. This PR fixes them all.Lockfile fix
The security-patch merges in #405 left
package-lock.jsonpartially regenerated — some resolved versions (notably@wordpress/eslint-plugin@18.1.0) no longer satisfied the version ranges declared by their parents, and a tree of transitive entries went missing. Every CInpm cifailed with:Re-resolved with
npm install --package-lock-onlyon Node 22.22.2 / npm 10.9.7 (matching the bundled-npm version CI runners use).package.jsonis unchanged. The diff is purely additive — it adds the missing transitive entries without bumping any direct dependency.Workflow & config fixes
Once
npm cisucceeded, the remaining failures surfaced and are addressed here:Cypress workspace build (
e2e-tests.yml+package.json)The action's inline
build:rannpm run build --workspaces --if-present, which only builds theexampleworkspace. Butexampleimports@10up/block-componentsfromfile:../dist/index.js, which doesn't exist until the root package builds first. Updated the existingbuild-test-envscript to chain root build + workspaces, and pointed the workflow at it (the cypress-io action passes thebuild:value as a single argv with no shell, so chained&&couldn't live inline).Cypress config loading (
tsconfig.json)When Cypress loads its config, it runs ts-node against the root tsconfig. Two issues blocked it:
esModuleInterop=falseandmoduleResolution=node10are warnings under the toolkit build but errors under ts-node. Silenced withignoreDeprecations: "6.0"(the Microsoft-recommended option).cypress.config.js(and itscypress/plugins/index.jsrequire) in isolation; without an explicitrootDir, ts-node computes the common source directory from a single file and the resolved rootDir doesn't matchoutDir. SetrootDir: ".".Cypress test specs (
Link.spec.js+registerBlockExtension.spec.js)Once Cypress could actually run, two specs failed because they clicked the post-publish "View Post" snackbar without first stripping
target="_blank"— the click opened a new tab and the test browser stayed on the editor. Follow-up assertions then silently ran against editor markup instead of frontend markup:Link.spec: the editor's RichText<a>has nohrefattribute, soshould('have.attr', 'href', ...)timed outregisterBlockExtension.spec: the editor has no "Edit Page" admin-bar link, socy.contains('Edit Page')timed outImage.specalready stripstargetbefore clicking. Mirroring its pattern fixes both. Verified the underlying frontend rendering is correct by publishing a Link block via wp-cli and inspecting<a href="https://10up.com/">First Link</a>in the rendered HTML.release_testing (
publish-npm.yml)The job runs
npm install -g npm@latest(upgrading to npm 11) beforenpm install. npm 11's resolver re-evaluates peer entries and writes them out, dirtying the working tree before the subsequentnpm versionstep fails withGit working directory not clean. Switched tonpm ci— strict no-op on lockfile state.Verification (local)
On Node 20.18.1 and Node 22.22.2:
npm ci— succeeds, noEUSAGEnpm run build— succeeds,dist/index.jsproducednpm test— Jest passesnpm run build-test-env— root + example both build in correct ordercypress.config.jscleanly — verified by reproducing Cypress'sregister_ts_node.jsoptions in a Node harness, since Cypress 13/14's binary doesn't run on macOS 26wp-clipublish of a Link block → frontend HTML contains<a href="https://10up.com/">…</a>(confirms the Link spec failure was about the snackbar/tab issue, not product code)CI status on this PR
npm ciagainst both PR head and base. The base (develop) still has the broken lockfile until this PR merges, so the action errors on the base-side install. Once this lands on develop, future PRs see a fixed base and the check passes without further changes.