Absolute paths in pnpm-lock.yml when using resolutions

[andschub-ms]

Verify latest release

• I verified that the issue exists in the latest pnpm release

pnpm version

8.15.5

Which area(s) of pnpm are affected? (leave empty if unsure)

Lockfile

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

mkdir test
cd test
pnpm init
mkdir my-package
pushd my-package
pnpm init
popd
pnpm add my-package@file:my-package
node -e "require('fs').writeFileSync('./package.json', JSON.stringify(Object.assign(require('./package.json'), { 'resolutions': { 'my-package': 'file:my-package' } }), null, 2))"
pnpm install

Describe the Bug

An absolute path is baked into the pnpm-lock.yaml:

lockfileVersion: '6.0'

settings:
  autoInstallPeers: false
  excludeLinksFromLockfile: false

overrides:
  my-package: file:my-package

dependencies:
  my-package:
    specifier: file:C:\git\test\my-package
    version: file:my-package

packages:

  file:my-package:
    resolution: {directory: my-package, type: directory}
    name: my-package
    dev: false

Expected Behavior

Adding a resolution (override) using a file: path bakes an absolute path ( specifier: file:C:\git\test\my-package ) into the pnpm-lock.yaml file. This is problematic because it makes a merge conflict every time a developer runs pnpm install on a different machine and makes it difficult to use PNPM in an organization.

Expected behavior is that there should only be relative paths from the workspace root in the lockfile. We would appreciate a workaround or bug fix for this issue. Thanks.

v9 is in alpha and does not work yet for us, so we are using the latest version of v8 as of last week.

Which Node.js version are you using?

v16.15.1

Which operating systems have you used?

• macOS
• Windows
• Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

[KSXGitHub]

The idiomatic pnpm workflow is pnpm-workspace.yaml and workspace scheme (workspace:*). Is there a reason that you must use file:?

[zkochan]

We should be able to fix this probably.

v9 is in alpha and does not work yet for us, so we are using the latest version of v8 as of last week.

What doesn't work with v9?

[andschub-ms]

We should be able to fix this probably.

v9 is in alpha and does not work yet for us, so we are using the latest version of v8 as of last week.

What doesn't work with v9?

Thank you for looking at this! To answer your question, this is the error I get trying to run 9.0.0-alpha.0. It's strange, because our node version is greater than what is listed.

ERROR: This version of pnpm requires at least Node.js v16.14
The current version of Node.js is v16.15.1
Visit https://r.pnpm.io/comp to see the list of past pnpm versions with respective Node.js version support.

The idiomatic pnpm workflow is pnpm-workspace.yaml and workspace scheme (workspace:*). Is there a reason that you must use file:?

Our build system was previously designed with --preserve-symlinks which does not work with PNPM, so we've been converting everything to work without this flag. However, some logic still relied on the old behavior, so using file: "hardlink" instead of "symlink" is helping us to work around the issue in the short term until we can update our build system. Sometimes we also want to override a package from the NPM feed with a local copy, and did this previously in yarn with no issues with the lock file (it only used relative path from workspace root), so I'm optimistic whether PNPM could support this scenario.