For organizations that need help

[zkochan]

If your company tries to migrate to pnpm but you have some blockers, add a post here and reference the issues that you have created. We will try to prioritize bug fixes/feature requests that are coming from big teams/companies.

The post should contain the name of the company and the size of the team.

Feel free to use this discussion also if you already migrated to pnpm but really need help with some issues.

[TeChn4K]

For us, the most challenging thing is being able to export/dockerise one workspace/package and its (internals AND externals) dependencies without packing the whole repository.
make-dedicated-lockfile is unusable because of #3442
pnpm-isolate-workspace is externally maintained and also has some (less problematic) issues.

A lot of discussions about this topic, but no mature solution yet : #3114 #1637 #2198

small company / few IT members

[zkochan]

Track this issue: #4378

[EscapeB]

For us, we are using pnpm to manage dependencies for our big monorepo (200+projects and 100+developers).

The problems we are facing are:

1. Workspace single lock file
Cause we are using pnpm workspace, single lock file was generated by default. After migrate lots of projects into monorepo, the lockfile became unstable and always get git conflict because there are many developers doing their work at same time.

We plan to turn off this option shared-workspace-lockfile, but still have some blockers. I have already list them.

#4247

2. Lockfile update

Lockfile not updated after run pnpm install if we change pnpm option or modify pnpfile.cjs. The recommend way is to regenerate
a new lockfile, but we want to keep the lock version for packages.

Bytedance / (100+ developers)

[zkochan]

2. Lockfile update

We can fix this. However, what do you need the pnpmfile for? We have lot's of other ways not to change the dependencies: overrides, packageExtensions, peerDependencyRules.

[EscapeB]

Really appreciate for your support !

We need use pnpmfile to do some resolution work and fix flaw package which has some phantom or incorrect dependencies. Some of them needs to be calculated dynamically so we can't put them in package.json.

[erango]

Hi! We're having trouble with unlinking. Our use case: we have a ton of packages in a monorepo, and they have some interdependencies. Sometimes two levels of dependency. To work more efficiently, if we don't need local code from the dependencies, we use repo versions instead. That way, you don't have to install the entire dependency tree just to work on one package.

We have two unlink-related bugs that create havoc on a daily basis for us as there are 70+ developers making changes in that repo every day.

Thanks so much for your attention! ❤️

#4294
#4295

[tgroutars]

Hi!

We are trying to migrate our monorepo to pnpm from yarn + lerna, but we're stuck importing because pnpm doesn't respect the versions specified in our nested yarn.locks.

Explanation + minimal repro in #4385

Thanks a lot in advance 🙏

Maze / 35+ engineers

[tgroutars]

I managed to tweak the code to make it work for my usecase, although my code is not memory efficient, very ugly and definitely breaks other parts of the package.

I'm not opening a PR on this repo for that reason, but you can have a look at the one I created on my fork if you want some inspiration tgroutars#1

Thanks a lot for what you do for pnpm, and I hope you're safe 🙏

[EscapeB]

I successfully used .pnpmfile.cjs to lock the dependencies version in migration process of our monorepo, may helps you without changing pnpm source code.

Here are my steps:

1. Parse previous lock file generated by (yarn / npm / pnpm). You can use some useful libs in community to parse different kinds of lock file. I used this
2. Generate a temp .pnpmfile.cjs in monorepo root (or in each project's folder if you are using separated lock file). In .pnpmfile.cjs, we can do resolution logic in readPackage hooks based on lock version data collected from step1.

module.exports = {
  hooks: {
    readPackage,
  },
};
// data struct injected in step1
const resolutions = {
  pkg1: {
    version: '1.0.0',
    dependencies: {
      dep1: '1.0.0',
      dep2: '1.0.0',
    },
    devDependencies: {
      dep3: '1.0.0',
      dep4: '1.0.0',
    },
  },
};

function readPackage(packageJson, context) {
  //  do your specific logic to modify packageJson based on const "resolutions"
  return packageJson;
}

3. Run pnpm install to see if it works.

[tgroutars]

Thanks! I managed to make pnpm import work for my usecase, though. I need to do it once, so I'm good now!

[zkochan]

Great! I am happy it worked for you!

[raygesualdo]

We've migrated to env vars for private registry credentials and when a teammate doesn't have the env var set, pnpm is exhibiting unexpected behavior: #4806.

We're a team of ~150 devs at @SalesLoft.

[joscalv]

Hi,

We are migrating to pnpm in Siemens Gamesa in a team of 100 dev aprox, but we found this issue:

We have a library with common utilities to develop and with many peer-dependencies to be installed by every teams.
The option "auto-install-peers=true" is very convenient for us, because the peer dependencies of that library are installed automatically without doing anything by every team.

The problem is that pnpm only installs that peer dependencies when pnpm-lock.yaml don't exists. If we delete node_modules after or in the CI/CD system, that dependencies are not installed.

Thanks for your help.

[jerrychen4git]

hi,
we have cyclic workspace dependencies but don't show any detail info about cycle, it's hard to check cycle manually , please fix this issue
#5059

bytedance/100+ team

[apaniel]

hi,
we have a monorepo in a company with 30+ developers working on it at the same time, we are having some unexpected updates in the lockfile that as side effect are producing not needed redeployment of different containers

#5108

[stefan-toubia]

Inconsistent/buggy behavior when shared-workspace-lockfile is disabled has been the main blocker migrating our repo. Shared lock file is not an option, monorepo contains multiple independent projects. From what I've seen it's not a hard blocker per se, biggest issue we're seeing so far has popped up in multiple issues like #4245 and #4868. We can likely work around this issue for some time since it just causes install times to be slower.

The main concern right now is uncertainty about how well shared-workspace-lockfile=false will be supported going forward. The docs mention nothing about this, but I've seen a number of comments recommending people not use this setting and that its buggy/not well tested. It would ease our concerns a bit if the pnpm team can comment on whether theres any plan to address these issues.

I should really also mention that from what we've seen so far, pnpm is a huge improvement over yarn and we're seeing a huge speed up in local and CI install times, so big shout out to the pnpm team.

Details on our monorepo:
100+ engineers, multiple independent teams, mixed langauges. Just a subset of those teams are working with Node. Currently using yarn v1.

[zkochan]

The main concern right now is uncertainty about how well shared-workspace-lockfile=false will be supported going forward.

I don't have an answer about it now. I don't plan to remove it but I also don't have anything related to it in priority. Maintaining this many settings is hard and ideally I want to reduce the amount of variations when possible.

[ProTip]

I would like to echo these sentiments. Biggest issue I'm running into is brining packages into a workspace that have patches and override rules that should only apply to that package.

If the overrides, patchedDependencies, and packageExtensions could be scoped to individual workspaces packages it would solve a lot of headaches for me.

[giancarlosisasi]

omg, I didn't know that overrides don't apply to individual workspace packages 😱 . I'm going to review my package.jsons right now 🏃🏼‍♂️

[ProTip]

It appears overrides can be used to override a specific dependency at the top level of a workspace package.

They can also be used to drill into a workspace package's dependencies and override a single occurrence there.

However, it can't be used to override every occurrence of a dependency recursively within a workspace package. This turns into a huge fiasco when you want to override a dependency that's part of a suite of packages from a project which gets depended on numerous times. You basically have to locate every package that requires it and add a separate overrides entry :|

[JamesSeymour]

We are attempting to migrate from yarn to pnpm. We have a monorepo with 200+ packages, but we are seeing an issue when some of the packages have different versions of the same dependency. - #5176

We would appreciate any help in understanding the issue more, so we can migrate our codebase!

Caplin/50+ team

[JamesSeymour]

Just thought I would update this. We moved our full codebase over to PNPM in September after a few minor workarounds and fixes on our side. It has been flawless ever since, our developers love working with it, and it really has increased our efficiency working on a large monorepo. Great work!

[lefreet]

is there a plan to auto version like lerna verion ？

we have some package depend on each other. for our project with workspace，the pnpm provide a link like "foo": "workspace:*" so that they all right when runtime. but when we want to publish them, pnpm publish, they published immediate with my admin role in out pravite registry. so, packages be overwrited :( .

so, there area some way to increase the packages's version by git tag check like lerna. with the vue | vite resolve these with custom scripts/release.js . -> https://github.com/vuejs/core/blob/main/scripts/release.js

[zkochan]

No, you should use changesets or rush for versioning.

[d4mr]

We are using using Turborepo with pnpm workspaces. We have already migrated over to pnpm, but are facing issues with package duplication.

Detailed issue: #5351
Company: Realto
Team Size: 15

[soundstep]

We are building a new CI tool, we are going to use the npm publish command until the pnpm one is fixed.

Issue: #5396
Company: ITV UK
Team Size: 100+

[lfloyd117]

We cannot upgrade PNPM from v8 to v9 due to pnpm dedupe hanging in v9. I have made an issue here: #8446

Medium/large company, 200+ developers

[lfloyd117]

Feature request for an issue with PNPM's resolution that has been causing us a lot of issues as of late:
#8502

Medium/large company, 200+ developers

[andschub-ms]

Cannot upgrade to v9.10.0 due to error printing in the console after install
#8538

#8538

[lfloyd117]

We are having an issue with pnpm install hanging on the latest release when changing package versions.
#8720

Medium/large company, 200+ developers

[andschub-ms]

Microsoft: hundreds of devs
Ran into a pnpm-cache corruption bug, and we still can't upgrade to latest from 9.9.0 due to PNPM install crashing.
Cache Corruption
#8734
Install crashing
#8538

[fpapado]

We have a large monorepo with shared-workspace-lockfile=false. We want to delegate auditConfig to each workspace package manifest, but currently pnpm audit only consults the root manifest.

Full details at: #8736

Large company, ~100 contributors in the relevant monorepo.

[haines]

Hi, I'm from Cerbos. We've run into a few issues with using pnpm deploy to build Docker images:

• ERR_PNPM_NO_OFFLINE_META when using pnpm deploy --offline #5315
• pnpm fails to exclude files matching negated glob patterns with multiple leading directories #7683
• pnpm deploy --prod fails due to missing devDependencies #8778

[mdjastrzebski]

Hello, I've found an issue with publishing packages from our monorepo: #8862.

This blocks us from using pnpm to publish React Native template containing executable gradew file.

Company: Callstack
Team size: 5

[sougiovn]

I found a bug with peerDependencies not resolving alias: #9017

This block us from upgrading to v10 because our internal packages depend on aliasing peerDependencies.

Large company, hundreds of devs

[dennemark]

we are struggling with building via rollup. some packages like @lexical/core have dependencies like @lexical/mark that can be imported in a repo. when building rollup cannot resolve those imports, unless i specifiy in package.json that i want it injected. like this:

"dependenciesMeta": {
    "@lexical/core": {
      "injected": true
    },
  },

but if i do this for a patched dependency, this does not work anymore.

[jwanner83]

We are using the standalone version of pnpm companywide because it is cross platform compatible and works great. A lot of developers who used nvm-sh before, miss the possibility to set a specific node version which is only used in the current terminal session and not globally.

Issue: #9364
Discussion: https://github.com/orgs/pnpm/discussions/3434#discussioncomment-12674336

Company: clavis IT ag
Team Size: 30+

[antitoxic]

We are using --silent flag to pipe output of pnpm run and parse it, but @pnpm/log.group prints groupstart CI markers even if --silent is used inside GH actions, so our logic now breaks.

Issue: #9563

Company: Yotpo
Team Size: 100+

[jcrben]

I work for a large company and would like to take advantage of pnpm's version management feature https://pnpm.io/cli/env

I need something like NVM_NODEJS_ORG_MIRROR https://github.com/nvm-sh/nvm?tab=readme-ov-file#use-a-mirror-of-node-binaries - does that exist for pnpm?

If so, it would be worth documenting on the page

[zkochan]

Yes, there is a setting for that: https://pnpm.io/settings#node-mirror

[tkolanko]

@zkochan I am looking at using pnpm but all of our scanning tools rely on a package-lock.json. Similar requirement to https://github.com/orgs/pnpm/discussions/3367#discussioncomment-4214798

is it possible to take a pnpm lock file and auto genereate a package-lock based on it

[Exelord]

Hi @zkochan! We are using pnpm v10 (10.19.0) and noticed a discrepancy between pnpm install and pnpm install --frozen-lockfile.

In the following scenario Package 1 <- Package 2 <- tsx the pnpm install will expose tsx binary (node_modules/.bin/tsx) to the Package 1, while pnpm install --frozen-lockfile will not. This creates a few issues where we get a "random" version of tsx if several dependencies will have it as their dependencies, and a logic that works locally but not on CI (tsx being present in consumer app locally).

My expected behavior would be the pnpm install --frozen-lockfile case where sub-dependecnies bins are not exposed to consumer.

Could you please help me clarify if this is a bug and which behavior is expected?