fix: work-around for pnpm catalog support

[AriPerkkio]

• Latest run: https://github.com/AriPerkkio/vitest-ecosystem-ci/actions/runs/13751231941

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[AriPerkkio]

Using link: instead of file: almost works. Only browser mode fails, as it's unable to load other linked packages. This happens locally too when using linked packages. 🤷‍♂️

[hi-ogawa]

How about using packed .tgz as override with pnpm pack? for example, overrides: { vitest: "/xxx/packages/vitest/vitest.tar.tgz" }. If it complicates things, I'm fine with a simple revert though.

[AriPerkkio]

At least locally that seems to work. Though there are some peer dep warnings, but it should be fine.

 WARN  Issues with peer dependencies found
.
├─┬ vitest 3.0.8
│ ├── ✕ unmet peer @vitest/browser@file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/browser/vitest-browser-3.0.8.tgz: found 3.0.8
│ └── ✕ unmet peer @vitest/ui@file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/ui/vitest-ui-3.0.8.tg

[AriPerkkio]

The getCommand from @antfu/ni didn't support this so hardcoding the command here.

[gluxon]

Agree with @hi-ogawa's suggestion to use pnpm pack! 🥳

Here's my explanation before I saw @hi-ogawa's message.

• chore: revert "chore: use pnpm catalog (#7590)" vitest#7636 (comment)

Running a pnpm pack to test vitest in other repositories locally is good for other reasons. You get a portable .tgz file that's closer to what would be published to the NPM registry. Linking in the source directory of the vitest would cause a bunch of other side-effects I suspect aren't desirable.

[AriPerkkio]

Using pnpm pack here indeed fixed the issue. I first tried using link: instead of file:, but that has some weird monorepo package resolving issues in Vitest's browser imports.

With pnpm pack we end up with following changes in tested projects' package.json's devDependencies and pnpm.overrides:

{
-  vitest: 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/vitest',
-  'vite-node': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/vite-node',
-  '@vitest/browser': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/browser',
-  '@vitest/coverage-istanbul': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/coverage-istanbul',
-  '@vitest/expect': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/expect',
-  '@vitest/snapshot': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/snapshot',
-  '@vitest/ui': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/ui',
-  '@vitest/web-worker': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/web-worker',
-  '@vitest/coverage-v8': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/coverage-v8',
-  '@vitest/runner': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/runner',
-  '@vitest/spy': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/spy',
-  '@vitest/utils': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/utils',
-  '@vitest/ws-client': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/ws-client',
-  '@vitest/pretty-format': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/pretty-format',
-  '@vitest/mocker': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/mocker'
+  vitest: 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/vitest/vitest-3.0.8.tgz',
+  'vite-node': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/vite-node/vite-node-3.0.8.tgz',
+  '@vitest/browser': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/browser/vitest-browser-3.0.8.tgz',
+  '@vitest/coverage-istanbul': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/coverage-istanbul/vitest-coverage-istanbul-3.0.8.tgz',
+  '@vitest/expect': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/expect/vitest-expect-3.0.8.tgz',
+  '@vitest/snapshot': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/snapshot/vitest-snapshot-3.0.8.tgz',
+  '@vitest/ui': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/ui/vitest-ui-3.0.8.tgz',
+  '@vitest/web-worker': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/web-worker/vitest-web-worker-3.0.8.tgz',
+  '@vitest/coverage-v8': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/coverage-v8/vitest-coverage-v8-3.0.8.tgz',
+  '@vitest/runner': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/runner/vitest-runner-3.0.8.tgz',
+  '@vitest/spy': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/spy/vitest-spy-3.0.8.tgz',
+  '@vitest/utils': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/utils/vitest-utils-3.0.8.tgz',
+  '@vitest/ws-client': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/ws-client/vitest-ws-client-3.0.8.tgz',
+  '@vitest/pretty-format': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/pretty-format/vitest-pretty-format-3.0.8.tgz',
+  '@vitest/mocker': 'file:/Users/x/vitest-ecosystem-ci/workspace/vitest/packages/mocker/vitest-mocker-3.0.8.tgz'
}

[gluxon]

Using pnpm pack here indeed fixed the issue. I first tried using link: instead of file:, but that has some weird monorepo package resolving issues in Vitest's browser imports.

Gotcha. The browser issues aren't too surprising when using link:. The link: protocol simply creates a symlink to the target repository, which then forces anything that performs node_modules resolution to use the node_modules directory of the other monorepo, rather than node_modules of the current repo. It basically "jumps" and uses the other repo's dependencies.

I think you're trying to simulate what would happen if someone depended on vitest packages that would be downloaded through the NPM registry. The link: protocol does something very different than that. I'm glad everyone here ended up with using the file: protocol with pnpm pack instead.

[hi-ogawa]

How about other package managers? I'd assume they should also break when seeing catalog:, but it's probably not tested right now?

[gluxon]

Right. Other packages managers would break when seeing catalog:. I'd note that's not unique to the catalog: protocol or pnpm. The file:, link:, and workspace: protocols are also meant to be "local-only" and don't work across different repos. There's a requirement for a "portability" step (e.g. publish or pack) to remove protocols like workspace: and catalog:.

pnpm itself throws when encountering the catalog: protocol in NPM packages since we don't want to encourage non-portable specifiers being published to the NPM registry.

[AriPerkkio]

I guess the test setup doesn't contain other package managers. Otherwise we should already have run into issues with workspace: protocol. 🤔

I think proper solution would be to use released packages from https://pkg.pr.new - I think Vite already has that kind of workflow.

[hi-ogawa]

Approving this to unblock CI 👍
I think I prefer this than reverting catalog entirely. Vite integrated https://pkg.pr.new, but I'm seeing quite a bit of flakiness there due to package download failure, so I'm not sure we should go setting up the same right now.