Framework: Switch from hoisted to isolated dependencies by manzoorwanijk · Pull Request #83847 · WordPress/gutenberg

manzoorwanijk · 2026-09-30T07:20:20Z

What?

Closes #76195
Alternative to #74689

Sets install-strategy = "linked" in .npmrc to isolate dependencies so every workspace resolves only the dependencies it actually declares.

Why?

We couldn't change the package manager, so I changed npm!

In January I proposed switching to pnpm (#74689). Not for novelty. Gutenberg publishes 80+ packages, and npm's hoisted layout lets any of them import a module they never declared. It works in the monorepo, CI stays green, the package ships, and then it breaks in somebody else's project. Cataloguing that failure turned up 60+ issues spanning six years, all the same shape: missing react, missing @babel/runtime, missing peers, missing siblings.

The community pushed back, and it was right to. Switching package managers needs coordination across repositories, older release branches would need updating too, and it asks every contributor to install and juggle a second package manager for two WordPress projects. Those are real costs, and a Make Core proposal was the correct bar to set. The proposal never moved beyond community review.

So instead of pushing a migration uphill, I took the pushback as the brief: get npm itself to do the thing pnpm was wanted for.

npm already had an isolated install strategy. It had simply never been run in anger against a monorepo this size, and it showed. Fixing it took 70+ PRs and 60+ bug reports in npm/cli, and 3 accepted RFCs, alongside 40+ merged PRs here untangling this repo's own root dependencies. The strategy graduated from experimental to stable in npm v11.18 (npm/cli#9674), and npm's own documentation now recommends it to package authors for precisely our problem:

We recommend that package authors use --install-strategy=linked during development to catch undeclared ("phantom") dependencies before publishing.

Then #82370 brought Node 24 and npm 11, and the last blocker in #76195 went with it.

That is why this is a config change rather than a migration. The hard part is upstream, shipped, and stable, and every npm user benefits from it rather than just this repo.

The exploration was done in #75814.

How?

.npmrc sets install-strategy = "linked". Dependencies land in node_modules/.store/ and are symlinked to exactly the packages that declare them.
patch-package is left as trunk has it. The repo has no patches left, and with none to apply it runs clean under this layout. It could not work if that changed (Support npm install-strategy=linked (.store directory layout) ds300/patch-package#595): it resolves packages at nested node_modules/ paths the linked strategy never creates, and refuses to diff a package directory containing symlinks into the store. A replacement that does work, with patch apply on postinstall and patch create <package> to author one, plus tests, sits in Explore using npm install-strategy=linked #75814 under tools/monorepo/patching and can be copied across if a patch is ever needed before npm v12's native npm patch lands (Framework: Update npm to v12 #82328).
typeRoots drops its repo-root @types fallback, so a package using types it never declared fails instead of borrowing them. Storybook roots Vite at its own workspace rather than the repo root.
CI skips the node_modules cache on Windows, whose tar cannot restore the isolated layout's links.
Contributor docs gain the VS Code settings that point at the workspace copies of TypeScript, ESLint, Prettier and Stylelint.

Testing Instructions

nvm use && rm -rf node_modules && npm ci. Confirm node_modules/.store/ exists and each dependency under it is symlinked from the packages that declare it.
npm run build, npm run typecheck, npm run test:unit:vitest, npm run storybook:build.
Import an undeclared dependency in any package and confirm it now fails instead of resolving by accident.

Use of AI Tools

Claude Code was used to validate this branch against Node 24 / npm 11 and to draft this description. All changes were reviewed by me.

github-actions · 2026-09-30T07:27:46Z

🤖 PR meta 🤖

🎉 Props

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +586 B (+0.01%)

Total Size: 8.25 MB

📦 View Changed

Filename	Size	Change
`build/modules/video-conversion/worker.min.js`	84.1 kB	+348 B (+0.42%)
`build/modules/vips/worker.min.js`	3.69 MB	+238 B (+0.01%)

_{4564123 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	`0aefcd8`	trunk	% Change
timeToFirstByte	62.65 ms +5.11% -2.23%	63.65 ms +5.81% -4.16%	-1.57%
largestContentfulPaint	108 ms +7.41% -5.56%	106 ms +3.77% -5.66%	1.89%
lcpMinusTtfb	42.25 ms +11.95% -9.94%	39 ms +18.08% -2.56%	8.33%
wpBeforeTemplate	32.02 ms +8.84% -1.19%	32.66 ms +7.65% -3.89%	-1.96%
wpTemplate	26.03 ms +2.8% -3.15%	25.88 ms +4.02% -4.68%	0.58%
wpTotal	57.98 ms +6.14% -1.74%	59.1 ms +6.38% -3.81%	-1.9%
wpMemoryUsage	7.62 MB +0% -0%	7.59 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	`0aefcd8`	trunk	% Change
timeToFirstByte	53.3 ms +9.85% -2.53%	51.85 ms +9.35% -0.87%	2.8%
largestContentfulPaint	114 ms +3.51% -1.75%	112 ms +3.57% -3.57%	1.79%
lcpMinusTtfb	60 ms +3.42% -1.75%	57.2 ms +4.55% -1.22%	4.9%
wpBeforeTemplate	30.05 ms +11.61% -1.7%	29.42 ms +12.2% -1.33%	2.14%
wpTemplate	19.33 ms +4.45% -2.9%	19.1 ms +3.93% -0.94%	1.2%
wpTotal	49.19 ms +11.08% -1.61%	48.38 ms +9.32% -0.79%	1.67%
wpMemoryUsage	6.25 MB +0% -0%	6.20 MB +0% -0%	0.71%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	`0aefcd8`	trunk	% Change
mediaProcessingJpeg	412.49 ms +1.73% -1.41%	412.04 ms +1.2% -0.23%	0.11%
mediaProcessingAvif	6145.69 ms +0.23% -0.37%	6115.61 ms +0.16% -0.13%	0.49%
mediaProcessingJpegToAvif	4239.53 ms +0.75% -0.62%	4229.37 ms +0.24% -0.05%	0.24%

media-upload

Metric	`0aefcd8`	trunk	% Change
jpegUploadProcessing	2005.83 ms +1.88% -1.86%	1970.98 ms +0.59% -0.7%	1.77%
pngUploadProcessing	216.05 ms +17.07% -1.18%	225.65 ms +29.17% -3.67%	-4.25%
largeJpegUploadProcessing	1973.4 ms +0.65% -0.43%	1969.41 ms +0.98% -0.29%	0.2%
multipleImageUploadProcessing	2095.88 ms +1.74% -0.66%	2131.92 ms +0.84% -3.29%	-1.69%

post-editor

Metric	`0aefcd8`	trunk	% Change
serverResponse	278.4 ms +1.44% -7.64%	256.98 ms +2.51% -7.72%	8.34%
firstPaint	180.5 ms +12.89% -4.12%	125.66 ms +30.49% -7.35%	43.64%
domContentLoaded	711.68 ms +0.44% -0.65%	658.1 ms +2.94% -2.47%	8.14%
loaded	712.75 ms +0.44% -0.66%	658.99 ms +2.97% -2.45%	8.16%
firstContentfulPaint	314.03 ms +3.2% -2.46%	291.1 ms +3.26% -4.16%	7.88%
firstBlock	2065.96 ms +1.16% -1.13%	1888.2 ms +1.13% -0.85%	9.41%
type	15.14 ms +5.09% -7.4%	13.55 ms +6.72% -5.24%	11.73%
typeWithoutInspector	13.69 ms +3.58% -1.9%	12.69 ms +5.2% -3.23%	7.88%
typeWithTopToolbar	16.35 ms +1.96% -2.57%	16.1 ms +8.7% -4.72%	1.55%
typeContainer	6.23 ms +5.3% -9.15%	6.1 ms +9.34% -8.36%	2.13%
focus	48.9 ms +12.97% -4.48%	45.62 ms +6.38% -6.12%	7.19%
firstFocus	123.76 ms +0% -0%	159.11 ms +0% -0%	-22.22%
selectAll	316.52 ms +16.7% -4.05%	313.97 ms +2.68% -0.86%	0.81%
listViewOpen	33.95 ms +17.61% -4.15%	36.38 ms +6.51% -6.76%	-6.68%
inserterOpen	16.37 ms +7.09% -5.31%	15.01 ms +7.06% -7.26%	9.06%
inserterHover	1.51 ms +19.87% -4.64%	1.53 ms +11.76% -8.5%	-1.31%
inserterSearch	6.14 ms +7.65% -3.09%	6.05 ms +6.61% -3.31%	1.49%
loadPatterns	418.21 ms +4.16% -3.95%	437.01 ms +4.49% -6.11%	-4.3%
wpTotal	271.4 ms +1.51% -7.86%	249.92 ms +2.55% -7.87%	8.59%
wpMemoryUsage	13.17 MB +0% -0%	13.13 MB +0% -0%	0.25%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	`0aefcd8`	trunk	% Change
serverResponse	475.49 ms +5.09% -3.36%	504.53 ms +2.9% -8.04%	-5.76%
firstPaint	238.29 ms +7.03% -10.63%	228.31 ms +27.52% -2.49%	4.37%
domContentLoaded	1145.65 ms +1.15% -2.67%	1149.54 ms +0.72% -0.79%	-0.34%
loaded	1146.87 ms +1.15% -2.66%	1150.82 ms +0.7% -0.79%	-0.34%
firstContentfulPaint	456.51 ms +2.19% -6.73%	457.28 ms +2.67% -1.27%	-0.17%
firstBlock	4162.41 ms +0.71% -0.88%	4158.65 ms +0.82% -0.58%	0.09%
type	17.93 ms +3.23% -5.91%	18.12 ms +4.86% -4.08%	-1.05%
navigate	115.36 ms +16.49% -5.22%	112.65 ms +15.99% -2.47%	2.41%
loadPatterns	1343.17 ms +2.16% -3.06%	1250.05 ms +8.92% -3.51%	7.45%
loadPages	1064.21 ms +2.28% -0.97%	1067.64 ms +2.98% -2.07%	-0.32%
wpTotal	465.77 ms +4.97% -3.42%	494.71 ms +2.93% -8.23%	-5.85%
wpMemoryUsage	12.14 MB +0% -0%	12.11 MB +0% -0%	0.3%
wpDbQueries	43.5 +1.15% -1.15%	43 +2.33% -0%	1.16%

_{4564123 Run}

🏁 Flaky tests

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

three users concurrently edit a large post with diverse blocks in /test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts, passed after 1 failed attempt.

TimeoutError: locator.waitFor: Timeout 17500ms exceeded.
Call log:
  - waiting for getByRole('button', { name: /Collaborators list/ }) to be visible

    at map (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/fixtures/collaboration-utils.ts:193:7)
    at CollaborationUtils.waitForMutualDiscovery (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/fixtures/collaboration-utils.ts:188:10)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts:416:28

_{4564123 Run}

ciampo · 2026-09-30T09:30:00Z

@@ -1,3 +1,4 @@
+install-strategy = "linked"


npm 11.16 is still allowed, but its linked installation leaves webpack unable to find the installed webpack-cli and breaks the documented webpack command. Could we raise both npm minimum entries to >=11.18.0 and verify that minimum in CI?

Yeah, that makes sense. The expectation, though, is that everyone uses the latest npm version, which the CI already does.

Done in f4d31be

We're technically not checking on CI that the min required version works well (since it installs latest version), but I think that's ok and not a blocker

Dependencies are installed into node_modules/.store/ and symlinked to the packages that declare them, so a package can no longer resolve a dependency it never declared.

typeRoots drops its repo-root @types fallback, so a package using types it never declared fails instead of borrowing them. Jest transforms through .store/, and test-create-block gives wp-scripts a NODE_PATH fallback for the bins it shells out to. Storybook roots Vite at the repository root by default, which under the isolated layout owns none of the dependencies its smoke tests resolve. CI skips the node_modules cache on Windows, whose tar cannot restore the isolated layout's links.

The linked install strategy is stable from v11.18, so the engine range no longer accepts the versions that shipped it as experimental.

The lockfile is identical under either layout and the installed-deps check reduces paths to name@version, so a tree installed with the other strategy satisfied every comparison and the mtime fast path skipped the check entirely. Compare npm's configured install-strategy against the tree on disk first, so switching strategies without a lockfile change still asks for a reinstall.

Rooting Vite at the Storybook workspace left the docgen plugin's default glob stopping at that root, so prop tables covered 298 components instead of 1079. Naming the documented sources restores them; excluding stories would drop the components they define. The root now derives from each config's own directory, so the Playwright config no longer inherits this workspace as its root. Its docgen globs move with it, matching the story globs beside them.

The fallback worked around `@wordpress/scripts` resolving its default browserslist config from the consumer's cwd, which #83902 fixes in the package itself by passing the preset's queries to webpack.

ciampo

LGTM 🚀

Congratulations for working all the way to this moment 🎉

aduth · 2026-10-01T15:00:44Z

I'm sure @manzoorwanijk is also relieved to no longer have to track down conflicts that folks have added over the past several months 😂

Great work here! 🎉

manzoorwanijk · 2026-10-01T15:18:23Z

I'm sure @manzoorwanijk is also relieved to no longer have to track down conflicts that folks have added over the past several months 😂

Definitely 😁

Great work here! 🎉

Thanks

…ode (#588) ## Why Installing a new Gutenberg site fails at the npm install step with `Error: Digest method not supported`. Gutenberg set `install-strategy = "linked"` in its `.npmrc` (WordPress/gutenberg#83847), so npm now uses its isolated installer, which names every `node_modules/.store` directory with `crypto.createHash('shake256')`. The app runs npm on Electron's Node, whose BoringSSL has no SHAKE256, so the install throws before it writes anything. ## What changes - `src/electron-node-compat.js` gets a pure-JS SHAKE256 (FIPS 202) and `provideShake256()`, which routes `createHash('shake256')` to it **only when the runtime lacks it**. Every other algorithm, and plain Node, is untouched. - The shim preload applies it, which covers any `npm`/`npx` reached through the shims, including the Windows spawn-patch route. - `src/install-runner.js` applies it before requiring npm. This is the route the bug hit: the runner loads npm in-process and never gets the preload. It is the real hash, not a stand-in, so the `.store` names match what a contributor gets on plain Node. ## How to test this Platforms: any. Build: the Buildkite artifact for the current head. **Starting state:** no Gutenberg site in the app. 1. Create a new Gutenberg site. 2. Let the npm install step run. - Expected: it finishes without `Digest method not supported`, and `node_modules/.store` exists in the site folder. 3. On an existing `wordpress-develop` site (not linked), run npm install again. - Expected: it succeeds as before. **What must not have happened:** the `wordpress-develop` install changing behaviour. It does not use the linked strategy, so it never asks for SHAKE256. Covered by `a linked install succeeds on the runtime the app runs npm on` in `tests/unit/npm-install.integration.test.cjs`. Under `npm run test:electron` it fails with the old `install-runner.js` and passes with this change (checked). Run from the repository root. ## Risks and limitations - Only `createHash('shake256')` is filled in: `update()` and one `digest()`, which is all npm uses. `copy()`, stream use and `crypto.hash()` are not, and SHA-3 is not. - Separate from this fix: npm 11.20 skipped the install scripts for `esbuild`, `fsevents`, `nx` and others on a full Gutenberg install (`npm install-scripts approve`). Not investigated here. ## Related Fixes #586 --- <details> <summary>Design decisions and alternatives considered</summary> Forcing `npm_config_install_strategy=hoisted` in the child environment was a one-line alternative. Rejected because it overrides the layout Gutenberg chose on purpose, so the app's `node_modules` would differ from Gutenberg's CI. The hash is applied only after probing the runtime, so a future Electron that gains SHAKE256 uses its own. </details> <details> <summary>Review outcome (required, see AGENTS.md)</summary> 1 [fix here] · 0 [follow-up]: fixed. - **Review:** completed. Separate-context subagent against `.github/instructions/code-review.instructions.md`; `npm run lint` and `npm test` clean, `npm run test:electron` clean. - Fixed: the install-runner route had no test that would fail without the fix. Added the `linked-install` fixture and the integration test above. - Also taken: the capability probe passes `outputLength`, so it does not lean on Node's default output length. - The review also caught that the branch had first been cut from the wrong base. It was rebuilt from `trunk` before committing; this PR contains one commit. - **Since review:** the fixes above, re-verified with lint and both test runtimes. </details> <details> <summary>Implementation notes</summary> - Checked against native `crypto.createHash('shake256')` on Node 20 for inputs and outputs on both sides of every 136-byte block boundary, with input split across `update()` calls: no mismatches. - Keccak-f[1600] works on 32-bit lane halves, because BigInt is too slow. About 40 MB/s on Electron, far beyond what npm hashes. - `no-bitwise` is disabled for the Keccak block only, with a reason. - Verified end to end: the real install runner on Electron 43.6.0 installs a current Gutenberg checkout (1886 `.store` entries). </details> Nothing on screen changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

) * Framework: Switch to npm install-strategy=linked Dependencies are installed into node_modules/.store/ and symlinked to the packages that declare them, so a package can no longer resolve a dependency it never declared. * Framework: Adapt tooling to the isolated install layout typeRoots drops its repo-root @types fallback, so a package using types it never declared fails instead of borrowing them. Jest transforms through .store/, and test-create-block gives wp-scripts a NODE_PATH fallback for the bins it shells out to. Storybook roots Vite at the repository root by default, which under the isolated layout owns none of the dependencies its smoke tests resolve. CI skips the node_modules cache on Windows, whose tar cannot restore the isolated layout's links. * Framework: Require npm v11.18 The linked install strategy is stable from v11.18, so the engine range no longer accepts the versions that shipped it as experimental. * Build: Detect a node_modules installed with the other strategy The lockfile is identical under either layout and the installed-deps check reduces paths to name@version, so a tree installed with the other strategy satisfied every comparison and the mtime fast path skipped the check entirely. Compare npm's configured install-strategy against the tree on disk first, so switching strategies without a lockfile change still asks for a reinstall. * Storybook: Restore docgen coverage under the isolated layout Rooting Vite at the Storybook workspace left the docgen plugin's default glob stopping at that root, so prop tables covered 298 components instead of 1079. Naming the documented sources restores them; excluding stories would drop the components they define. The root now derives from each config's own directory, so the Playwright config no longer inherits this workspace as its root. Its docgen globs move with it, matching the story globs beside them. * Framework: Drop the NODE_PATH fallback in create-block validation The fallback worked around `@wordpress/scripts` resolving its default browserslist config from the consumer's cwd, which WordPress#83902 fixes in the package itself by passing the preset's queries to webpack. Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org> Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: tyxla <tyxla@git.wordpress.org>

aduth · 2026-10-06T20:42:27Z

I had a conversation with an agent today while working on a pull request, and it said something that stood out to me in relation to isolated dependencies:

The changes are uncommitted. I could not build or test them, because node_modules is still mostly empty. Please run npm install, then npm run build.

Further prompting confirmed that it got tripped up by the isolated dependencies, compounded by my own agent guidance to manually install dependencies:

I checked ls node_modules | wc -l, which hides dotfiles and so did not show .store. I also checked for node_modules/typescript and node_modules/.bin/tsc at the root. Both checks assume hoisting. The fact that would have corrected me was in .npmrc, which I never read, because nothing pointed me to it. The four review agents made the same mistake on their own ("TypeScript is not installed in this checkout"). That makes this a systematic error, not a one-off, which is exactly the kind of scar tissue AGENTS.md is for.

My saved memory that you run npm install yourself made it worse. It gave me an easy way to hand the problem back to you instead of looking into it.

Might be worth a blurb in AGENTS.md ?

manzoorwanijk · 2026-10-07T03:32:04Z

Thanks @aduth, that is a useful catch. #84141 adds a pitfall to AGENTS.md explaining that the near-empty root node_modules is expected under the linked strategy, and how to check an install via node_modules/.store/. It also updates the outdated hoisting note in the workspace development guide.

github-actions Bot added the [Tool] Dependency Extraction Webpack Plugin /packages/dependency-extraction-webpack-plugin label Sep 30, 2026

manzoorwanijk added the [Type] Build Tooling Issues or PRs related to build tooling label Sep 30, 2026

manzoorwanijk requested review from Mamaduka, aduth, ciampo, jsnajdr and tyxla September 30, 2026 07:56

manzoorwanijk marked this pull request as ready for review September 30, 2026 07:56

manzoorwanijk requested review from desrosj, fabiankaegy and juanmaguitar as code owners September 30, 2026 07:56

manzoorwanijk mentioned this pull request Sep 30, 2026

Explore using npm install-strategy=linked #75814

Closed

manzoorwanijk linked an issue Sep 30, 2026 that may be closed by this pull request

Switch to npm install-strategy=linked #76195

Closed

manzoorwanijk changed the title ~~Framework: We couldn't change the package manager, so I changed npm~~ Framework: Switch from hoisted to isolated dependencies Sep 30, 2026

manzoorwanijk added the Require PR update Forces open PRs to update from trunk label Sep 30, 2026

manzoorwanijk force-pushed the update/npm-install-strategy-linked branch 2 times, most recently from e1e508d to 3de7c68 Compare September 30, 2026 09:16

ciampo reviewed Sep 30, 2026

View reviewed changes

tyxla reviewed Sep 30, 2026

View reviewed changes

Comment thread storybook/main.ts Outdated

Comment thread storybook/main.ts Outdated

Comment thread tools/validation/test-create-block.mjs Outdated

Comment thread .npmrc

manzoorwanijk force-pushed the update/npm-install-strategy-linked branch 2 times, most recently from 87702b4 to ead4f75 Compare October 1, 2026 04:16

manzoorwanijk requested review from ciampo and tyxla October 1, 2026 04:39

manzoorwanijk mentioned this pull request Oct 1, 2026

Scripts: Resolve default configs without hoisted dependencies #83902

Merged

manzoorwanijk added 5 commits October 1, 2026 12:25

Framework: Switch to npm install-strategy=linked

55239ed

Dependencies are installed into node_modules/.store/ and symlinked to the packages that declare them, so a package can no longer resolve a dependency it never declared.

Framework: Require npm v11.18

d086108

The linked install strategy is stable from v11.18, so the engine range no longer accepts the versions that shipped it as experimental.

Framework: Drop the NODE_PATH fallback in create-block validation

4564123

The fallback worked around `@wordpress/scripts` resolving its default browserslist config from the consumer's cwd, which #83902 fixes in the package itself by passing the preset's queries to webpack.

manzoorwanijk force-pushed the update/npm-install-strategy-linked branch from ccdc909 to 4564123 Compare October 1, 2026 06:57

ciampo approved these changes Oct 1, 2026

View reviewed changes

manzoorwanijk merged commit e1b6b62 into trunk Oct 1, 2026
96 of 101 checks passed

manzoorwanijk deleted the update/npm-install-strategy-linked branch October 1, 2026 10:53

github-actions Bot added this to the Gutenberg 24.2 milestone Oct 1, 2026

manzoorwanijk mentioned this pull request Oct 1, 2026

Build: Remove patch-package #83982

Merged

ryanwelcher mentioned this pull request Oct 1, 2026

npm install fails with "Digest method not supported" on Gutenberg sites WordPress/contributor-toolkit#586

Closed

ryanwelcher mentioned this pull request Oct 1, 2026

Fix npm install on Gutenberg sites by adding SHAKE256 to Electron's Node WordPress/contributor-toolkit#588

Merged

jsnajdr mentioned this pull request Oct 2, 2026

Add prettier, eslint and stylelint to the root package.json #84017

Merged

manzoorwanijk mentioned this pull request Oct 2, 2026

VS Code: Add managed workspace config #84025

Merged

This was referenced Oct 5, 2026

npm install fails as .nvmrc references a node version that doesn't include a compatible npm version. #84057

Closed

chore: Use v24 in .nvmrc #84061

Merged

manzoorwanijk mentioned this pull request Oct 5, 2026

Fix check type declarations errors when running npm run dev #84070

Merged

manzoorwanijk mentioned this pull request Oct 7, 2026

Docs: Describe isolated dependencies for agents #84141

Merged

Navigation Menu

Repository navigation

Framework: Switch from hoisted to isolated dependencies - #83847

Framework: Switch from hoisted to isolated dependencies#83847
manzoorwanijk merged 6 commits into
trunkfrom
update/npm-install-strategy-linked

manzoorwanijk commented Sep 30, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 30, 2026 •

edited

Loading

Uh oh!

ciampo Sep 30, 2026

Uh oh!

manzoorwanijk Sep 30, 2026

Uh oh!

manzoorwanijk Sep 30, 2026

Uh oh!

ciampo Oct 1, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ciampo left a comment

Uh oh!

Uh oh!

aduth commented Oct 1, 2026

Uh oh!

manzoorwanijk commented Oct 1, 2026

Uh oh!

aduth commented Oct 6, 2026

Uh oh!

manzoorwanijk commented Oct 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

manzoorwanijk commented Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Use of AI Tools

Uh oh!

github-actions Bot commented Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🤖 PR meta 🤖

🎉 Props

📦 Bundle size

⚡ Performance

🏁 Flaky tests

Uh oh!

ciampo Sep 30, 2026

Choose a reason for hiding this comment

Uh oh!

manzoorwanijk Sep 30, 2026

Choose a reason for hiding this comment

Uh oh!

manzoorwanijk Sep 30, 2026

Choose a reason for hiding this comment

Uh oh!

ciampo Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ciampo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aduth commented Oct 1, 2026

Uh oh!

manzoorwanijk commented Oct 1, 2026

Uh oh!

aduth commented Oct 6, 2026

Uh oh!

manzoorwanijk commented Oct 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

manzoorwanijk commented Sep 30, 2026 •

edited

Loading

github-actions Bot commented Sep 30, 2026 •

edited

Loading