@@ -2,7 +2,6 @@ install-strategy = "linked"
 engine-strict = true
 strict-peer-deps = true
 prefer-dedupe = true
-lockfile-version = 3
 min-release-age = 1
 # fail the install on any dependency script not covered by allowScripts in package.json
 strict-allow-scripts = true
 
@@ -5,10 +5,17 @@ The following guide is for setting up your local environment to contribute to th
 ## Prerequisites
 
 -   Node.js
-    Gutenberg is a JavaScript project that requires [Node.js](https://nodejs.org/). The project is currently built using Node.js v24 and npm v11. Though best efforts are made to always use the Active LTS version of Node.js, this will not always be the case. For more details, please refer to the [Node.js release schedule](https://github.com/nodejs/Release#release-schedule).
+    Gutenberg is a JavaScript project that requires [Node.js](https://nodejs.org/). The project is currently built using Node.js v24 and npm v12. Though best efforts are made to always use the Active LTS version of Node.js, this will not always be the case. For more details, please refer to the [Node.js release schedule](https://github.com/nodejs/Release#release-schedule).
 
 We recommend using the [Node Version Manager](https://github.com/nvm-sh/nvm) (nvm) since it is the easiest way to install and manage node for macOS, Linux, and Windows 10 using WSL2. See [our Development Tools guide](/docs/getting-started/devenv/README.md#node-js-development-tools) or the Nodejs site for additional installation instructions.
 
+-   npm
+    Install npm explicitly rather than relying on the version Node.js bundles:
+
+    ```bash
+    npm install --global npm@^12
+    ```
+
 -   Git
     Gutenberg is using git for source control. Make sure you have an updated version of git installed on your computer, as well as a GitHub account. You can read the [Git Workflow](/docs/contributors/code/git-workflow.md) to learn more about using git and GitHub with Gutenberg
 
 
@@ -16,7 +16,7 @@ The repository also contains internal workspaces under `tools/` and `test/` for
 
 Install scripts are opt-in: every dependency that ships one is recorded in `allowScripts` in the root `package.json`, and `strict-allow-scripts` fails the install with `ESTRICTALLOWSCRIPTS` on anything missing from that list. Every entry is `false`, so nothing compiles on install. `test/ai-development` installs with `--prefix`, so it carries its own copy of the policy.
 
-`allowScripts` covers dependencies only, so workspace lifecycle scripts such as the `@wordpress/icons` `prepare` still run. npm v12 skips them under `install-strategy=linked` with no error ([npm/cli#9982](https://github.com/npm/cli/issues/9982)), so moving to npm v12 means invoking them from the root `postinstall` instead.
+`allowScripts` covers dependencies only on npm v11, so workspace lifecycle scripts such as the `@wordpress/icons` `prepare` ran unguarded. npm v12 holds them to the same policy under `install-strategy=linked`, and skips an unlisted one with no error ([npm/cli#9982](https://github.com/npm/cli/issues/9982)), so a workspace that needs its script is approved by its `file:` spec rather than its name: `"file:packages/icons": true`.
 
 When an install fails that way, read the script, then edit `allowScripts` by hand and commit the `package.json` change. Use the package name on its own to cover every version, or `name@version` to pin an approval to the version you reviewed:
 
 
@@ -16,7 +16,7 @@
 	},
 	"engines": {
 		"node": ">=24.18.0",
-		"npm": ">=11.18.0"
+		"npm": ">=12.0.2"
 	},
 	"devEngines": {
 		"runtime": {
@@ -25,7 +25,7 @@
 		},
 		"packageManager": {
 			"name": "npm",
-			"version": ">=11.18.0",
+			"version": ">=12.0.2",
 			"onFail": "error"
 		}
 	},
@@ -241,6 +241,7 @@
 		"core-js": false,
 		"core-js-pure": false,
 		"esbuild": false,
+		"file:packages/icons": true,
 		"fs-ext-extra-prebuilt": false,
 		"fsevents": false,
 		"nx": false,