installing only Vitest is ending up installing Vite@5.x by default with lots of CVE

[ghiscoding]

I'm not sure if I should open a new issue for this or not, but basically in Lerna-Lite, I only use Vitest since Vite isn't required at all. However the latest version of Vitest accepts both Vite v5 or v6 and because of that pnpm detects and installs the minimum which is Vite v5 instead of what most users would expect to be on the latest versions of everything.

The fact that pnpm installs Vite v5 by default is causing GitHub to open a lot of Dependabot security issues. I just enabled Dependabot (on top of Snyk) and it came up with 14 vunerabilities. So I had to add a pnpm.overrides (in this PR) to upgrade Vite to v6 even though I'm not using Vite at all in the project and now I'm down from 14 to 6 vulnerabilities...

So why didn't Vitest upgrade to Vite v6 and drop v5? This is causing unexpected installation behind the scene and makes vulnerabilities linger a lot longer

vitest/packages/vitest/package.json

Lines 174 to 175 in 1d9a6f4

	"vite": "^5.0.0 || ^6.0.0",
	"vite-node": "workspace:*",

[AriPerkkio]

Vite updated most of their previous majors with the security patches. It's completely fine to use latest v5 with Vitest v3. https://github.com/vitejs/vite/blob/v5.4.14/packages/vite/CHANGELOG.md

[ghiscoding]

Sure but my Dependabot count still went down quite a lot (down by 8, you can see them here) by upgrading to Vite 6 even if I do know the Vite team does patch security issues on both versions.

I guess my next question would be, will Vitest always have 2 allowed Vite dependencies? If so, then I guess I should really keep my pnpm override to avoid this kind of situation to happen again. I just was unexpected for me to see it use Vite 5 when I only install Vitest

[AriPerkkio]

In your case, wouldn't you end up with vulnerable 6.0.0 if Vite 5 was dropped? You'll need to check how your package manager allows updating transitive dependencies.

The idea behind semver's dependency ranges (^) is that whole ecosystem doesn't need to update their deps when one package in the chain publishes new release.

Usually I update lockfiles directly, or configure dependebot/renovate to do lockfile maintenance. You don't need overrides.

I guess my next question would be, will Vitest always have 2 allowed Vite dependencies?

Ideally we would support all Vite versions. Now only 5 and 6 are supported for Vitest v3.

[ghiscoding]

Usually I update lockfiles directly, or configure dependebot/renovate to do lockfile maintenance. You don't need overrides.

I do use Renovate on a schedule but typically Renovate can't do anything in this case because Vite was never part of package.json (at least not before I added a pnpm override). So there's no way that Renovate could detect or advise the user that latest major isn't used (Renovate would open PR for major versions only when the feature is enabled and the dependency is part of your package deps but it wasn't in my case so). I'm fine with the pnpm override but I'm mentioning this because I'm pretty sure it happens to other users and most users will never open their lock file and inspect it to find if an older versions of Vite is being used or not.

In other words, most users that only install Vitest (like me) will probably encounter the same problem. If you guys intend to keep it has is, then that's fine, I'll keep my override (I could go without the override if I manually update my lock file to use Vite latest, but I prefer to make it more explicit with an override).

Thanks for the quick reply :)

[AriPerkkio]

but typically Renovate can't do anything in this case because Vite was never part of package.json
...
So there's no way that Renovate could detect or advise the user that latest major isn't used

You need https://docs.renovatebot.com/configuration-options/#lockfilemaintenance, so that Renovate updates your lockfiles. It's able to read and update lockfiles.

In other words, most users that only install Vitest (like me) will probably encounter the same problem

All package managers should automatically use the latest Vite they encounted when "vite": "^5.0.0 | ^6.0.0" is seen. Maybe in your case there is some other depedency locking the Vite version, or the package manager has a bug. At least for me it always installs latest:

# pnpm
$ mkdir transitive-vite-example && cd transitive-vite-example && pnpm init && pnpm i vitest && pnpm why vite

dependencies:
vitest 3.0.6
├─┬ @vitest/mocker 3.0.6
│ └── vite 6.1.0 peer
├── vite 6.1.0
└─┬ vite-node 3.0.6
  └── vite 6.1.0

# npm
$ mkdir transitive-vite-example && cd transitive-vite-example && npm init -y && npm i vitest && npm why vite

vite@6.1.0
node_modules/vite
  peerOptional vite@"^5.0.0 || ^6.0.0" from @vitest/mocker@3.0.6
  node_modules/@vitest/mocker
    @vitest/mocker@"3.0.6" from vitest@3.0.6
    node_modules/vitest
      vitest@"^3.0.6" from the root project
  vite@"^5.0.0 || ^6.0.0" from vite-node@3.0.6
  node_modules/vite-node
    vite-node@"3.0.6" from vitest@3.0.6
    node_modules/vitest
      vitest@"^3.0.6" from the root project
  vite@"^5.0.0 || ^6.0.0" from vitest@3.0.6
  node_modules/vitest
    vitest@"^3.0.6" from the root project

[ghiscoding]

ok thanks for the verification, I'm assuming it's probably because I was on Vitest since v2 and so it probably didn't update Vite when I switched Vitest to v3 because it already had Vite 5 in the lock file. I guess it would probably have used latest Vite 6 if I came empty (or if I delete my pnpm lock file), I'm going to try that next. I'm also giving a try to that flag you mentioned which I didn't know about, Renovate has so many flags and features :)

Thanks for all, I think we can close the subject :)

EDIT

Yup it was caused by the fact that I already had a lock file when switching from Vitest v2 to v3. I tried out the lock file maintenance flag and it's great to update the lock file but I might not leave it enabled all the time (I guess it's ok to enable every few months)... and now my Dependabot security count is down to only 1 (esbuild vulnerability which isn't an issue in my project since I'm not using its dev server). Thanks again for all the great info you've put it, that was very useful. Cheers 🍺 🚀