Zoltan Kochan
Zoltan Kochan
Maybe this should improve it: https://github.com/pnpm/pnpm/pull/4701
Why were you removing PNPM_HOME from `.zshrc`? Did you have a bad path there? I guess we need to update `pnpm setup`, so that it can update PNPM_HOME, if it...
> ... which is sort of true, but the directory that resolves to is definitely in the PATH: this we can fix.
What about the `$PNPM_HOME` env variable? Is it set?
> we need to ensure other app subgraphs aren't affected `@pg1/copper-plate 1.1.0` in scope of one lockfile may have only one set of dependencies. So, you will either get `@pg1/copper-ore...
I believe we already have preferred versions https://github.com/pnpm/pnpm/blob/56cf04cb36a47181f0921a9c746f02ed376d88fa/packages/resolve-dependencies/src/resolveDependencies.ts#L239 which are versions that are present in the lockfile. During resolution, pnpm prefers to pick one of the versions that is already...
> Could it look something like an .npmrc setting like preferrExistingVersions to essentially instruct pnpm to favor versions that are already present in the lockfile (and which are semver compliant)?...
I see. I think this case can be fixed.
I don't see a good solution for this. If we don't upgrade `@pg1/copper-ore` in the dependencies of `@pg/copper-plate`, then `app-with-changes` will have two versions of `@pg1/copper-ore`. One as a direct...