Option to pack workspace instead of link it？

[shrinktofit]

• I'd be willing to implement this feature (contributing guide)

Describe the user story

A common case is that people want to organize the repo in workspace form ie into many packages. But they do not need to version some(even all) of them since the packages always stay locally and privately.

Currently, pnpm link or local dependecy may help. But the problem is, when deploy the root package, all files in the linked packages folder are deployed. Usually we only want lib, dist... but not src source... right?

Describe the solution you'd like

So can we have an option, when it's toggled, pnpm install firstly pnpm pack all local dependencies, and then extract, link the tarballs into node_modules/.pnpm as if they were downloaded from an install-time-registry. Since pnpm pack is performed. The tarballs only contain files filtered by .npmignore.

Describe the drawbacks of your solution

The main drawback of the proposed solution is that when this option is toggled, the install process is slow. But as far as I considered, this option would be only toggled in CI. During normal development, the dependecies still link.

Describe alternatives you've considered

[shrinktofit]

related: https://npm.community/t/npm-needs-a-more-robust-story-for-local-multi-module-development/1059

[defjosiah]

We have the same use-case for a large monorepo. We’ve written a lot of custom tooling that fakes this workflow (we have a script that replaces monorepo dependencies with published npm versions, and publishes them if they don’t exist yet).
We have too many divergent versions for some of the other fixes for bad resolves because of dev dependencies, peerDependencies etc.

None of the workspace implementations handle this case, they just symlink the whole node_modules.

We’re currently considering writing a lerna variant that publishes “bare” packages to npm (which will have only the dependencies in them with no built files) and then manually symlinking based on the package.json “files” field. This wouldn’t be needed if something like this issue asks for exists.

I think this is a pretty big caveat that almost all workspace implementations have (yarn v2 portals sort of addresses it, but yarn v2 is such a different approach that we haven’t been able to make it work with our monorepo).

[defjosiah]

A super strict mode for workspaces, where the “files” property is respected and the only thing that is symlinked (and the dependencies are resolved as if they came from a registry) would be great for local development and CI.
Some of our biggest monorepo pain points come from the symlinking/dependency behavior of workspace implementations. (I.e. we have to use webpack alias features, etc. extensively).

[magne4000]

This would fix an issue that I have:

packages/
  repo-a/
    package.json
      "devDependencies": {
        "abc": "0.0.1"
      }
      "peerDependencies": {
        "abc": "0.0.1"
      },
      "peerDependenciesMeta": {
        "abc": {
          "optional": true
        }
      }
  repo-b/
    package.json
      "dependencies": {
        "repo-a": "workspace:*"
      }

Here repo-b locally has abc in its dependency tree, which does not reflect what a user installing repo-b would have.
abc would only be installed in a project using repo-b if it was manually added to its dependencies or devDependencies.

Should https://pnpm.io/package_json#dependenciesmetainjected be the solution?
It doesn't seem to work properly if it's the case.
With this config, I see that my project using repo-b does not deeply have abc anymore in its node_modules, but an await import('abc') present in repo-a still work. (abc is properly considered as an external dep, I do not have it bundled in repo-a on build)

If someone is willing to take a look at this, I will make a reproduction repository in place.