chore: upgrade packageManager to pnpm@11.9.0#504
Open
panish16 wants to merge 22 commits into
Open
Conversation
panish16
force-pushed
the
feat/upgrade-pnpm-v11
branch
2 times, most recently
from
89e3682 to
ffa3656
Compare
panish16
requested review from
kialj876,
pwei1018 and
thorwolpert
as code owners
…y pnpm v11
pnpm v11 stopped reading package.json's "pnpm" key, silently dropping
business-registry-dashboard's @nuxt/icon override (installing a buggy
version) and build-script approvals. Move both to pnpm-workspace.yaml,
with an explicit empty packages list since the production lint job's
older pnpm still requires that field to be present. Also fix the root
pnpm-workspace.yaml's allowBuilds map, which had literal placeholder
text ("set this to true or false") instead of real booleans, and a
stale onlyBuiltDependencies list left over from before pnpm v11's
config format change.
…/upgrade-pnpm-v11 # Conflicts: # web/business-registry-dashboard/package.json
The shared bcregistry-sre/frontend-ci.yaml workflow defaults pnpm_version to "9" when unset, and pnpm/action-setup doesn't defer to packageManager for that bare default. Pin pnpm_version to 11.9.0 explicitly, matching packageManager, as a stopgap until bcgov/bcregistry-sre#369 lands.
Under genuine pnpm v11 installs, the real Keycloak plugin now initializes during Nuxt test-environment setup (previously masked by broken/partial pnpm 9-10 installs), pushing component-mount tests past the default 5000ms vitest timeout.
The layer's real Keycloak plugin (01.keycloak.client.ts) awaits init() on every app boot, including mountSuspended() in tests. Its SSO iframe check never resolves in the test environment, hanging every component-mount test indefinitely. Previously masked by broken pnpm 9/10 installs not actually wiring up this dependency.
Applies the pnpm v11 portion of PR bcgov#488 (closed, unmerged) to these three apps, which were still pinned to pnpm 10.0.0/10.13.1. Also bumps actions/checkout, actions/setup-node, pnpm/action-setup, and upload/download-artifact to their current major versions in the e2e-tests and merge-reports jobs, matching that PR. Excludes its unrelated @sbc-connect/nuxt-pay pkg.pr.new preview-package swap, which is out of scope for this upgrade.
panish16
requested review from
deetz99,
doug-lovett,
eve-git and
vysakh-menon-aot
as code owners
…lution The extended layer (@daxiom/nuxt-core-layer-test) declares its own @nuxt/ui@^2.20.0 dependency, correctly resolved in its own pnpm scope. But Nuxt loads modules relative to the app's rootDir, which climbed past this app's node_modules (no local @nuxt/ui) up to the monorepo root's hoisted @nuxt/ui@4.7.1 (needed by the corps/ person-roles/registry-home apps, which use Nuxt UI v4). v4 requires Nuxt >=4.1.0, so it silently disabled itself on this Nuxt 3 app, breaking #components auto-imports (UIcon, UInput, etc.) used by mountSuspended() in component tests, hanging them indefinitely. Declaring @nuxt/ui directly in this app's own dependencies gives it priority in Node's resolution before the hoisted v4 is ever reached, without touching the other apps that genuinely need v4.
Instruments fetch and dumps active handles/requests on an 8s marker to identify what's actually blocking mountSuspended(). Will be removed once the root cause is confirmed.
# Conflicts: # .github/workflows/registry-home-ci.yaml # pnpm-workspace.yaml
The ^2.2.2 override was a workaround from before @nuxt/ui's own module-resolution bug (fixed in bd56c02) was understood: @nuxt/ui 2.22.3 declares @nuxt/icon ^1.15.0 internally, so forcing 2.2.2+ created a live major-version mismatch between @nuxt/ui's internals and the icon module it actually loads. Diagnostic instrumentation in mountSuspended() traced the resulting test hangs to an infinite recursive Vue render loop (renderComponentRoot -> patch -> processComponent -> mountComponent -> ...), consistent with a broken icon-resolution fallback. Removing the override lets it resolve to 1.15.0, matching what @nuxt/ui actually expects.
@nuxt/icon's local bundle mode needs @iconify-json/mdi to fetch icon SVG data at build time. The extended layer declares this dependency in its own package.json, but pnpm's per-package resolution scope doesn't make it visible to @nuxt/icon's own resolution context, causing "Nuxt Icon could not fetch icon data" build failures. Declaring it directly in this app's own dependencies (same pattern as the earlier @nuxt/ui and pnpm-icon-override fixes) makes it resolvable.
…ectly Same fix as the @iconify-json/mdi one: @nuxt/ui's own default icons (chevrons, close buttons, spinners) come from the heroicons set, declared as @nuxt/ui's own dependency but not visible in this app's resolution scope. This was the last icon set still failing to fetch after the mdi fix.
This was an early ad-hoc validation workflow, added before the real reusable-workflow CI was properly fixed to run on pnpm 11. It builds each app in isolation without the full workspace context the #business layer alias needs, causing a known false-positive build failure for corps/person-roles unrelated to their actual CI (which is fully green). No longer needed now that the real CI is verified across all four apps.
2 tasks
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.
Sets
packageManagertopnpm@11.9.0inweb/registry-home/package.jsonas part of the pnpm v11 upgrade (ticket #33875).The Cloud Build CI trigger has already been updated to use
pnpm@11.9.0.