chore(deps): trivial major-version dependency migrations - #3294
Open
ByronDWall wants to merge 5 commits into
Open
chore(deps): trivial major-version dependency migrations#3294ByronDWall wants to merge 5 commits into
ByronDWall wants to merge 5 commits into
Conversation
findRootSync now returns a MonorepoRoot object ({ rootDir, tool })
instead of a plain root-path string (breaking change since v3.0.0).
Update the sole call site in generators/package-json/src/index.ts to
read .rootDir.
No call-site changes needed: both consumers (generators/package-json and generators/readme) only read the .packages array from getPackagesSync(), never .root/.rootPackage/.tool, so the v2.0 root->rootPackage rename and other API changes don't affect this repo.
No call-site changes needed. Verified require('commander') still works
under Node 24 (commander v15 is ESM-only internally but Node's
synchronous require()-of-ESM support handles it), and all 3 call sites
(scripts/version.js via CJS require, generators/package-json and
generators/readme bin scripts via ESM import compiled through
ts-node's commonjs mode) run without ERR_REQUIRE_ESM or similar
errors. None of the 3 call sites declare paired --no-* boolean
negation options, so the v15 default-value behavior change for those
does not apply here.
No call sites in this repo (git grep for "execa" across *.js/*.ts/*.mjs/*.cjs
outside node_modules returns nothing) — it's a bare devDependency
catalog entry only. Verified 'pnpm install' succeeds and both
require('execa') and import('execa') resolve without error under
Node 24.
…M deps in generator tests
Two real, previously-unverified regressions surfaced by running the
generators' Jest test suite (jest.ts-test.config.js) after the
@manypkg/find-root and @manypkg/get-packages major bumps:
1. babel-plugin-package-version.js does `require('find-up')` but
find-up was never a declared dependency anywhere in this repo -- it
only resolved by accident via Jest's haste-map fallback landing on
whichever find-up version happened to be reachable in the .pnpm
store. Before this change that happened to be the CJS find-up@4.1.0
pulled in by some other package; after regenerating the lockfile
for the 4 dep bumps in this branch, the phantom resolution shifted
to the ESM-only find-up@7.0.0, which Jest's CJS module runtime
can't require (`SyntaxError: Cannot use import statement outside a
module`), breaking generators/readme's test suite (it invokes
react-docgen -> @babel/core -> babel.config.js ->
babel-plugin-package-version.js). Declaring find-up@5.0.0 (already
present in the lockfile, CJS, has the .sync API this file uses) as
an explicit devDependency makes the resolution deterministic and
fixes the test.
2. generators/package-json and generators/readme's Jest specs import
'../src', which unconditionally imports @manypkg/find-root /
@manypkg/get-packages at module-eval time. Both packages are pure
ESM since their v3 majors. Jest's CJS runtime can't require ESM
packages directly (unlike Node's native require(), which has
supported this since Node 22.12 -- which is why the CLI smoke tests
for these generators were unaffected). Neither spec file actually
exercises findRootSync/getPackagesSync (only transformDocument is
under test), so jest.mock() stubs for both packages avoid the
module-load-time SyntaxError without touching the shared root Jest
config used by the rest of the monorepo's test suites.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
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.
Context
Split out from #3293, which batch-consolidated safe Renovate updates and explicitly excluded all 28 genuine major-version dependency bumps for later handling. This PR picks up the subset of those excluded majors that are trivial ecosystem churn and are genuinely present in this repo (this repo's Renovate dependency dashboard is known to be heavily contaminated with items from a different repo's dependency graph).
Included (4)
@manypkg/find-root1.1.0 → 3.1.0 — pure ESM since v3.0.0, consumed viats-node --compiler-options '{"module":"commonjs"}'ingenerators/package-json. Breaking change found during migration:findRootSyncnow returns aMonorepoRootobject ({ rootDir, tool }) instead of a plain path string. Fixed the one call site to read.rootDir. Verified: CLI smoke test (generate-package-json --dry-run), Jest unit tests, andpnpm typecheckall pass.@manypkg/get-packages1.1.3 → 3.1.0 — pure ESM since v3.0.0. Both consumers (generators/package-json,generators/readme) only read.packagesfromgetPackagesSync(), never.root/.rootPackage/.tool, so the v2.0 API rename doesn't affect this repo. Verified: CLI smoke tests (--dry-runand--all-workspace-packages --dry-run), Jest unit tests.commander^13.1.0 → 15.0.0 — ESM-only internals since v15, requires Node ≥22.12 (this repo runs Node 24). No call-site changes needed; verified all 3 call sites (scripts/version.jsvia CJSrequire, and the two generator bin scripts via ESMimportcompiled through ts-node's commonjs mode) run withoutERR_REQUIRE_ESM. None of the 3 sites declare paired--no-*boolean negation options, so v15's default-value behavior change for those doesn't apply.execa9.6.1 → 10.0.1 — zero call sites anywhere in this repo's source (only a bare devDependency catalog entry). Verifiedpnpm installsucceeds and bothrequire('execa')andimport('execa')resolve under Node 24.Also fixed: a real, previously-unverified regression the dashboard's research didn't catch
Running the generators' Jest suite after the
@manypkg/*bumps surfaced two real problems, both fixed in a dedicated follow-up commit:babel-plugin-package-version.jsdoesrequire('find-up'), butfind-upwas never a declared dependency anywhere in this repo — it only resolved by accident via Jest's haste-map fallback landing on whicheverfind-upversion happened to be reachable in the pnpm store. Regenerating the lockfile for the 4 bumps in this PR shifted that phantom resolution from a CJSfind-up@4.1.0to the ESM-onlyfind-up@7.0.0, which Jest's CJS module runtime can'trequire()(SyntaxError: Cannot use import statement outside a module), breakinggenerators/readme's test suite. Fixed by declaringfind-up@5.0.0(already present in the lockfile, CJS, has the.syncAPI this file uses) as an explicit devDependency, making the resolution deterministic.generators/package-jsonandgenerators/readmeimport../src, which unconditionally imports the now-ESM-only@manypkg/find-root/@manypkg/get-packagesat module-eval time. Jest's CJS runtime can't require ESM packages directly (unlike Node's nativerequire(), which has supported this since Node 22.12 — why the CLI smoke tests were unaffected). Neither spec actually exercisesfindRootSync/getPackagesSync, so added narrowjest.mock()stubs in the two spec files, without touching the shared root Jest config used by the rest of the monorepo's tests.Explicitly excluded (out of scope for this trivial-churn batch)
All non-trivial majors, reason: "non-trivial major, out of scope for this trivial-churn batch, left for dedicated follow-up":
babel packages, git workflow tools, i18n/formatjs, jest packages, linting major group (incl. eslint v10), node.js updates, svgr, typescript packages,
@testing-library/jest-dom,@vitejs/plugin-react(-swc),babel-plugin-formatjs,jsdom,prettier,puppeteer,stylelint*,vite.Verified-but-already-current (no-op, nothing to commit)
cross-env— already10.1.0downshift— already9.4.0(catalogs.react)glob— already13.0.6Dropped as not actually present/real in this repo (dashboard contamination)
flat-cache>rimraf—flat-cacheis present (both4.0.1and6.1.22resolved in the lockfile), but neither resolved version depends onrimraf(they depend onflatted/keyvandcacheable/hookifiedrespectively). This transitive relationship doesn't exist in this repo's dependency graph.webpack-dev-server>rimraf—webpack-dev-serverdoesn't appear anywhere inpnpm-lock.yaml; not a dependency of this repo at all.This is consistent with #3293's own findings about dashboard contamination.
Build/test verification
pnpm typecheck— 20 pre-existing errors in 5 unrelated files (icon-button/card/spacings/data-table typings), confirmed present on a pristineorigin/maincheckout too; no new errors introduced by this PR.npx jest --config jest.ts-test.config.js(generators + all other ts-test-node specs) — 3 suites / 7 tests pass.pnpm test(full monorepo suite, afterpnpm compile-intl) — 124/125 suites, 1402/1403 tests pass. The one flaky test (generators/readme's "Justice League" inline snapshot) is a pre-existing, order-dependent race unrelated to this PR:generators/package-jsonandgenerators/readmetest suites both copy fixtures into the same sharedos.tmpdir()/packages/justice-leaguepath, and their fixturepackage.jsonfiles have differentdescriptiontext, so whichever suite'sbeforeAllcopy runs last wins. Reproduced the identical flake on a pristineorigin/maincheckout (failed in 1 of 3 runs there too) — confirmed pre-existing, not introduced by this PR, and left unfixed as out of scope.pnpm build— passes fully (exit code 0).Changeset
Not needed. All 4 deps (
@manypkg/find-root,@manypkg/get-packages,commander,execa) plus the addedfind-upare devDependencies / repo-tooling-only — confirmed none are a runtimedependenciesentry of any published@commercetools-uikit/*or@commercetools-frontend/*package (the generators themselves are"private": true). This matches the precedent for pure tooling deps.Not merging or closing PR #3293 or any original Renovate PRs.