publishConfig.directory does not get symlinked for workspace packages

[jwarby]

pnpm version: 6.17.2

Code to reproduce the issue:

Have a workspace package that has a customised publishConfig.directory specified in package.json:

{
    "name": "package-a",
    "publishConfig": {
        "directory": "dist"
    }
}

And then use the package inside another workspace package:

{
    "name": "package-b",
    "dependencies": {
        "package-a": "workspace:*"
    }
}

Expected behavior:

pnpm creates a symlink to the publishConfig.directory within package-a instead of the top-level package-a directory, so that the local setup mirrors what would happen when somebody installs package-a. This is what Lerna does when publishConfig.directory is set.

Actual behavior:

The top-level folder for package-a is linked, thus breaking imports in projects which depend on package-a.

There is a workaround where we can use the path to the publishConfig.directory when we specify the dependency on package-a:

- "package-a": "workspace:*",
+ "package-a": "workspace:../path/to/package/dist",

However, this has a few issues:

• publishConfig.directory is effectively defined twice - if we change it in package-a's package.json, we have to change all the dependents too
• we have to make sure the publishConfig.directory is present before we try to install dependencies in any packages which depend on package-a, otherwise an error will be thrown because the directory is missing. This means our company has ended up with a kind of weird bootstrapping step where we run install for packages with a publishConfig.directory first, to allow their postinstall build commands to run, creating the target directory in the process
• running pnpm up wipes out the path specifier and replaces it with the current version of the package in the workspace, eg

- "package-a": "workspace:../path/to/package/dist",
+ "package-a": "workspace:^1.0.0",

• I will open a separate issue for this and link back as I feel it's probably related but shouldn't be bundled in with this report (edit: pnpm up replaces workspace: protocol relative paths with version range #3902)

Additional information:

• node -v prints: v14.15.1
• Windows, macOS, or Linux?: Linux

[fireairforce]

pnpm creates a symlink to the publishConfig.directory, I think this maybe a hack way... as your opinion, if the directory is empty, the case will be complicated...

[victordidenko]

Relates to #3540

[zkochan]

if the directory is empty, the case will be complicated...

symlinks may point to directories that don't yet exist, so it should not be a problem

[boyeborg]

Just wanted to pitch in that we're experiencing the same problem at my company. In our monorepo setup we have several packages that produces a new package.json during the build/package process and puts it inside the output folder. To work with the local copy of the package we have to either manually link or use relative paths as showed in the issue. We currently have a script that does all the manual linking for us when we want to work against local packages, but it would nice if it was supported out of the box.

[pedronauck]

+1

[david-plugge]

any updates on this?
is there a workaround?

[david-plugge]

@zkochan thank you so much for picking this up!

[david-plugge]

FYI currently the package version eg workspace:* within the package.json in publishConfig.directory is not replaced on publish aswell.

ERR_PNPM_CANNOT_RESOLVE_WORKSPACE_PROTOCOL  Cannot resolve workspace protocol of dependency
"@scope/package" because this dependency is not installed. Try running "pnpm install".

"dependencies": {
  "@scope/package": "workspace:*"
},

[zkochan]

We might need to make this change opt-in: #5115

[zkochan]

It was a breaking change, so I have reverted it in v7.8

To get this behavior, set linkDirectory to true in publishConfig

{
  "publishConfig": {
    "directory": "dist",
    "linkDirectory": true
  }
}

[hairyf]

publishConfig.linkDirectory should be turned off by default, which seems annoying