Is there an option to prevent pnpm from using a pnpm-workspace.yaml file?

[leonsilicon]

Use case: When testing my packages, I have folders for mini-projects which each contain a package.json file which contain the project to test as one of the package.json dependencies:

File structure:

project-monorepo/
  - packages/
    - my-project/
      - src/
      - test/
        - fixtures/
          - my-project-test/
            - package.json // Contains `"my-project": "link:../../../my-project"`
            - test.js // import myProject from 'my-project'; myProject.functionToTest()
  - pnpm-workspace.yaml // packages: ['package/*']

When running pnpm install from within one of these mini-projects (e.g. project-monorepo/packages/test/fixtures/my-project-test), pnpm currently tries to install all the workspace dependencies based on the pnpm-workspace.yaml file. I'm looking for an option to force pnpm to only install the mini-package's dependencies and ignore the pnpm-workspace.yaml file in the root of project-monorepo (i.e. to install the dependencies of the mini-project as if the pnpm-workspace.yaml didn't exist). I tried browsing through pnpm install --help but couldn't find an option for this.

Currently, my workaround is to specify the fixtures path in my pnpm-workspace.yaml file and use pnpm install --filter ., but it would be optimal to not have to specify these fixture folders in my pnpm-workspace.yaml file.

[leonsilicon]

After browsing through the source code, I think I've found the option I'm looking for: --ignore-workspace (e.g. pnpm --ignore-workspace install)

Perhaps it might be a good idea to make this more visible in the documentation/help commands? (since pnpm install --help didn't make any mention of this command)

[astahmer]

thank you for this. I spent lots of hours trying to replicate that behaviour (tried yarn, bun, and finally by removing node_modules / re-installing with npm which kinda worked but was so slow) but this is so much easier.

context:
my use-case was publishing a VSCode extension while keeping the package inside a pnpm workspace AND being able to bundle some dependencies (= can't use the --no-dependencies vsce flag). Basically had to fork the vsce CLI, then having a bundledDepdendencies field in the VSCode extension package.json and finally replace workspace:* dependencies with link:/path/to/workspace/package right before building the extension .
Here's the complete github CI workflow for reference: https://github.com/chakra-ui/panda/blob/386e5098b338e22cb2d1236f08d7ef3973a07c01/.github/workflows/release.yml#L115-L148

[samzuercher]

Would be nice to have this in .npmrc (ignore-workspace=true)

[zkochan]

pnpm will stop reading settings from .npmrc because npm CLI doesn't allow anymore third party settings in .npmrc. All pnpm-related settings except auth settings should be moved to pnpm-workspace.yaml.

[samzuercher]

ok. but could pnpm-workspace.yaml filtering be extended? e.g.

packages:
  - "lib/**"
  - !"lib/*package1*/**.*"

to exclude certain packages? this package.json

"scripts": {
    "i": "pnpm --ignore-workspace i",

would also be nice, but does not work.

[zkochan]

Excluding works. But ! should probably be in the quotes:

packages:
  - "lib/**"
  - "!lib/*package1*/**.*"

[raulfdm]

I was having a similar issue: I had a published library and an app that consume this package from the registry (not using workspace: protocol) and I realized when I installed the dependencies, pnpm was linking the package anyways.

While reading the docks to understand why the hack is that, I found this option:

link-workspace-packages

• Default: true
• Type: true, false, deep

If this is enabled, locally available packages are linked to node_modules instead of being downloaded from the registry. This is very convenient in a monorepo. If you need local packages to also be linked to subdependencies, you can use the deep setting.

Else, packages are downloaded and installed from the registry. However, workspace packages can still be linked by using the workspace: range protocol.

source: https://pnpm.io/npmrc#link-workspace-packages

In other words, if the app and the package is in the same repository, pnpm will link the package in the app no matter if we're using the workspace protocol or not.

When I set --link-workspace-packages=false in my .npmrc, I finally was able to get it from registry.

@zkochan please don't get me wrong for what I'm about to say. I do understand the idea behind doing this automatically but IHMO (nobody asked but here we're), this is a terrible default behavior. I'd rather to explicitly inform pnpm about if I want the packages being linked or not using the workspace protocol explicitly instead having both workspace protocol AND versioned behaving the same.

[zkochan]

This will be changed in the next major version.

[johndunderhill]

@zkochan Please don't do that. You will break dozens of our production workflows in monorepos. We rely on this behavior to use packages in a monorepo, and also publish them, under exactly the same name.

If we're relying on the documented default, so are thousands of others. This is out there. It can be overriden (and I will do that if I have to), but if you change this now, you're going to break a lot of things. That would be a disaster, IMHO, or else there aren't nearly as many pnpm users as I think there are.

pnpm has a learning curve. We think it's worth it, so we learned.

[raulfdm]

@johndunderhill don't you pin the pnpm version? 🤔

[johndunderhill]

@raulfdm Yes, but we generally upgrade our dev tools fairly agressively. Sometimes they break if we don't upgrade them. We're much more conservative about our runtime dependencies.

Moreover, I can't be stuck on the current version forever. I will manage but I think this change will cause more harm than good, unless you know that it's already causing more confusion for others than changing the default after the fact will. I don't actually have a good impression of how many people are relying on this setting. I'm relying on it. There are a lot of pnpm users.