You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/languages-frameworks/javascript.section.md
+11-45Lines changed: 11 additions & 45 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -305,19 +305,26 @@ This package puts the corepack wrappers for pnpm and yarn in your PATH, and they
305
305
306
306
### pnpm {#javascript-pnpm}
307
307
308
-
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8`, `pnpm_9`and `pnpm_10`, which support different sets of lock file versions.
308
+
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8`, `pnpm_9`, `pnpm_10`, `pnpm_10_29_2`and `pnpm_11`, which support different sets of lock file versions.
309
309
310
310
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The function `fetchPnpmDeps` can create this pnpm store derivation. In conjunction, the setup hook `pnpmConfigHook` will prepare the build environment to install the pre-fetched dependencies store. Here is an example for a package that contains `package.json` and a `pnpm-lock.yaml` files using the fetcher and setup hook above:
311
311
312
312
```nix
313
313
{
314
314
fetchPnpmDeps,
315
315
nodejs,
316
-
pnpm,
316
+
pnpm_11,
317
317
pnpmConfigHook,
318
318
stdenv,
319
319
}:
320
-
320
+
let
321
+
# It is recommended to pin pnpm to a major version, due to regular breaking changes in the store format
322
+
# The latest major version is always available under `pkgs.pnpm`
323
+
# Optionally override pnpm to use a custom nodejs version
324
+
# Make sure that the same nodejs version is referenced in nativeBuildInputs
It is highly recommended to use a pinned version of pnpm (i.e., `pnpm_9` or `pnpm_10`), to increase future reproducibility. It might also be required to use an older version if the package needs support for a certain lock file version. To do so, you can pass the `pnpm` argument to `fetchPnpmDeps` and override the `pnpm` arg in `pnpmConfigHook`. Here are the changes in the example above to use a pinned pnpm version:
344
-
345
-
<!-- TODO: Does splicing still work when overriding in nativeBuildInputs here? -->
346
-
347
-
```diff
348
-
{
349
-
fetchPnpmDeps,
350
-
nodejs,
351
-
- pnpm,
352
-
+ pnpm_10,
353
-
pnpmConfigHook,
354
-
stdenv,
355
-
}:
356
-
+let
357
-
+ # Optionally override pnpm to use a custom nodejs version
358
-
+ # Make sure that the same nodejs version is referenced in nativeBuildInputs
nodejs # in case scripts are run outside of a pnpm call
371
-
pnpmConfigHook
372
-
- pnpm # At least required by pnpmConfigHook, if not other (custom) phases
373
-
+ pnpm_10 # At least required by pnpmConfigHook, if not other (custom) phases
374
-
];
375
-
376
-
pnpmDeps = fetchPnpmDeps {
377
-
inherit (finalAttrs) pname version src;
378
-
+ pnpm = pnpm_10;
379
-
fetcherVersion = 3;
380
-
hash = "...";
381
-
};
382
-
})
383
-
```
384
-
385
351
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e., `inherit (finalAttrs) patches`.
386
352
387
353
`pnpmConfigHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array:
0 commit comments