pnpm: pnpm install in workspace at windows doesn't install workspace dependenciess
pnpm version:
7.13.14
Code to reproduce the issue:
I just tried with the all examples https://github.com/Saul-Mirone/milkdown
Expected behavior:

Detects workspaces automatically. Scope: all * workspaces
Actual behavior:
Doesn’t detects workspaces unless they defined in the root package.json as dependeny
Additional information:
node -v
prints: 16.18.0- Windows, macOS, or Linux?: Working is on macos, not working is on Windows.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 13
- Comments: 17
@NavidK0 in our case, it’s because
pnpm install
in windows is changing the path-separator in the lock file.Before:
'@myorg/i18n': link:packages/i18n
After:
'@myorg/i18n': link:packages\i18n
And when this lock file is used in our pipelines, which run in Linux, the workspaces are not installed/linked correctly resulting in build errors.
So, maybe the lock file created in windows is incompatible when used in linux?
@ayZagen I was finally able to replicate your issue by making a new test package inside our monorepo and changing our
pnpm-workspace.yaml
to match yours. I copied your package.json files exactly.I was able to fix your issue by changing the
pnpm-workspace.yaml
file to this:Perhaps give that a try? No idea why the
apps/*
glob doesn’t work overapps/**
, but it seemed to fix the issue on my end. Definitely seems like a bug otherwise.The problem I faced happens when you don’t reference the workspace package from any other package/root.
I have attached a screenshot. no matter what you set in
.npmrc
if the package is not referenced its dependencies are not installed.In my case when I put
"@docs/site": "workspace:*"
in the rootpackage.json
dependencies it works. This behavior somehow makes sense, but it is incorrect because we may just want to use root dependencies in our packages.@Metehan-Altuntekin Also, pnpm symlinks will be broken when trying to access them from windows (Related issue: https://github.com/microsoft/WSL/issues/5118). You have to use remote development to work with the project from windows.
I don’t exactly know why only some of the windows users experience this bug. we can’t use pnpm workspaces on windows while this bug exists.
i can confirm this is issue is still valid with
v7.26.3
.@Metehan-Altuntekin WSL won’t solve your problem when working with windows binaries.
It is really annoying that pnpm doesn’t work with good with windows. Even if you handle this problem with adding dependencies to the root, it sometimes gets stack while running scripts at the cashing process.
I have created a project as fast as i can. Check it out from here
@GiancarlosIO Oddly enough, when I do
pnpm i
my path separators are all forward slashes despite using Windows. I’m not entirely sure what we are doing differently that isn’t reproducing the same behavior. I even tried deleting and making a new lockfile with Windows. We useworkspace: *
for our local packages.Our devs use a mix of Windows, Linux, and macOS for their systems, with all of our CI in Linux, but we all use
git config core.eol "lf"
, so perhaps that could be why? (You could trygit config core.eol "lf"
as a workaround since this definitely feels like a bug.)I think you’re definitely onto something with the back slashes in the lockfile, however. I wonder if it is based on the line endings of the package.json files themselves.
EDIT: Converted entire project to CRLF, tried regenerating lockfile, still unable to get back slashes nor replicate the issue. This is really weird.
Just in case it helps: npm version: 8.15.0 (just for installing pnpm) pnpm version: 7.13.6 node version: v16.17.0 git version: 2.37.3.windows.1