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+

[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?

[adamdehaven]

We've noticed an issue with pnpm.overrides utilizing references (with $) are reset to an actual version after running pnpm audit --fix even if the dependency is not impacted by the audit: #10325

[kweij]

The instruction on how to use pnpm on CI/CD are all based on first installing corepack using ... npm. We're piloting using pnpm for security reasons, because running npm install [...] has it's risks (insert recent supply chain attacks here).

Is there al alternative best practice to installing pnpm (consistently for a certain version) for CI/CD without using npm?

[ronjouch]

Dependabot is partially broken with pnpm (v10, haven’t tried earlier versions): although their support matrix says Security updates are supported, PR creation fails with this error:

Dependabot doesn't support the 'updating transitive dependencies' feature for pnpm package_manager

Dependabot attempted to update your dependencies but encountered an unsupported feature: 'updating transitive dependencies' for pnpm package_manager. Currently, this feature is not supported by Dependabot.

Dependabot issue, with 25 upvotes as of writing: dependabot/dependabot-core#13177

[sresch4b]

We're struggling with the supply-chain checks that pnpm offers in combination with Azure Artifacts, because it manipulates the meta data of packages from upstreams like npm.

#11720

Large company
Teamsize ~20 developers, but I guess everyone who is using pnpm in combination with Azure Artifacts feels the same pain.

[ajeetdsouza]

pnpm 11.4.0+ breaks installs for the Buf Schema Registry. This issue affects not only our company but also several of our customers, many of whom are large enterprises.

#12145

[kj800x]

HubSpot is in early phases for migrating away from an in-house custom package manager to pnpm. So far we have had strong success. We're making heavy use of the config plugin and custom resolver features of pnpm 11 to help bridge between our legacy custom package manager and standard modern packages that we host on an internal verdaccio server.

Organizational context: HubSpot currently has about 2k engineers, with about ~800 engineers that do some form of JavaScript / TypeScript development. We have 4064 packages in our custom package manager. We use a micro-frontend SPA app architecture with library packages for shared logic. Our repos typically have around 1-10 packages configured together in a workspace.

Generally the migration has been going smoothly. One feature so far would make it easier for us to use our config plugin in all the contexts we need it: #12180

[RomanHotsiy]

• Issue: pnpm install shrinks pnpm-lock.yaml and re-resolves transitive dependencies (v11) #11859
• Company: Redocly
• Team Size: 60+

[astegmaier]

All Microsoft engineers are currently blocked from using pnpm's self-update feature with versions of pnpm > 11.5.3. (i.e. if you have pnpm>=11.5.3 installed globally and you run pnpm in a repo that has "packageManager": "pnpm@X", pnpm will fail to auto install version X).

This is caused by:

1. Two issues in pnpm@11.5.3:
   a. packageManager version switch fails on registries that serve tarballs from a different host than the packument #13619 (introduced by fix: harden package-manager bootstrap metadata #12296)
   b. Registries without signatures cannot be used #13147 (introduced by fix(security): verify npm registry signature before spawning a package-manager binary #12292)
2. A central security team recently started blocking public npm registry access on all developer machines at the Microsoft, and forcing all traffic to go through a feed proxy that centrally controls quarantining and auditing packages for vulnerabilities.

A reproduction and detailed explanation is available at https://github.com/astegmaier/playground-pnpm-package-proxy

This affects >200 monorepos and >4k engineers.

[zkochan]

ok, I will look into it.

[astegmaier]

Thanks so much! I tested out 11.21.0 (which contains #13728), and it works great :-)

[tw-blue]

I created a discussion on the topic of potentially insecure packages being downloaded Here
Which prevents us from migrating to pnpm right now

I work at domeba GmbH which has about 140 Employees

[ByronDWall]

Issue: #13715
This issue affects multiple monorepos in our organization, and roughly 200 engineers.