pnpm 10 deploy requires inject-workspace-packages, which makes monorepo life harder

[AdriVanHoudt]

Can someone explain a bit why deploy now requires inject-workspace-packages?
I saw #8857 but it doesn't have much context.
I also don't understand why it would be a requirement to generate a correct lockfile when using deploy. (This is expected as I don't know the internals and details of how pnpm does things internally)

Enabling inject-workspace-packages in a monorepo (using nx in this case) is quite the annoyance.
If I understood it correctly, when building an app it basically requires an pnpm install after each package in the graph (nx builds a graph of dependencies and tasks to run/build to get to build task of the app). Before it was all symlinks so any build output is immediately picked up but now it is basically required to run pnpm install after each package is build to make sure that the next package or app in the build process has it node_module actually pointing to the correct folder and the new/updated files.

[craig-feldman]

I see there is a discussion around this here as well. We are in a similar situation and also use a monorepo with shared workspace packages. Not too sure what effect enabling this will have for us, but when testing with inject-workspace-packages set to true, it causes a bunch of issues with us using catalog versioning in shared packages and pnpm install no longer works (An external package outside of the pnpm workspace declared a dependency using the catalog protocol.).

A bit of additional documentation or clarification around this new requirement would be great.

[zkochan]

If you don't want to use inject-workspace-packages=true, then set the force-legacy-deploy setting to true or run pnpm deploy --legacy. This works from pnpm v10.2.1.

[craig-feldman]

Thanks @zkochan - I was trying the legacy flag with using 10.2.0 😅 . Glad to see that has been patched 👍

[AdriVanHoudt]

ah nice, thanks for the workaround option 👍