fix(license): resolve wrong version and missing license text

[btea]

fix #23355

[bluwy]

We use findNearestMainPackageData in many places to get a dependency's main package.json, so I don't think fixing only in the license plugin is right here.

We could put the fix directly in the findNearestMainPackageData, but will need to consider the possible breaking change of this in some setups, eg local workspace packages without version somehow.

But also, is putting the name in a nested package.json correct? Maybe it's harmless but worth checking if this is covered by the spec.

[btea]

We use findNearestMainPackageData in many places to get a dependency's main package.json, so I don't think fixing only in the license plugin is right here.

We could put the fix directly in the findNearestMainPackageData, but will need to consider the possible breaking change of this in some setups, eg local workspace packages without version somehow.

Yes, we use findNearestMainPackageData in multiple places, so to avoid causing unpredictable damage, I only handled the license call separately.

But also, is putting the name in a nested package.json correct? Maybe it's harmless but worth checking if this is covered by the spec.

A nested package.json starts a new package scope, but Node only reads type/main/exports/imports from it—name only matters to Node for self-reference via exports, which markers don't have. So a nested name is a community convention with no spec-defined semantics, making name + version a fair heuristic for the real package root.

https://nodejs.org/api/packages.html#introduction
https://nodejs.org/api/packages.html#nodejs-packagejson-field-definitions
https://nodejs.org/api/packages.html#name

[bluwy]

Node only reads type/main for nested package.json from nodejs/node#58827. I also tested and pnpm seems to allow workspace packages without version to be linked, e.g. via "pkg-a": "workspace:*".

So if we want to check both name + version, I think this might affect some workspace setups. Also, name + version doesn't necessarily match the root if you encounter packages like these (don't know why they publish that way).

So I think the solution to this comes down to tradeoffs. Checking by name before works ok-ish but in this case isn't always correct. Maybe the only sure way is to check the path for patterns like node_modules/{pkg}/package.json, but this could be problematic for yarn pnp, might need to check if pnpapi have any utils to help.

I'd prefer investigating if we can fix for findNearestMainPackageData directly instead of only the license. I don't think it's very urgent to get the license case fixed first. But this work might be a bit more involved.

[btea]

That makes sense. Let's verify and proceed step by step.

[btea]

/ecosystem-ci run

[pkg-pr-new]

Open in StackBlitz

@vitejs/plugin-legacy

pnpm add https://pkg.pr.new/@vitejs/plugin-legacy@23356 -D

npm i https://pkg.pr.new/@vitejs/plugin-legacy@23356 -D

yarn add https://pkg.pr.new/@vitejs/plugin-legacy@23356.tgz -D

vite

pnpm add https://pkg.pr.new/vite@23356 -D

npm i https://pkg.pr.new/vite@23356 -D

yarn add https://pkg.pr.new/vite@23356.tgz -D

commit: fcb7821

[vite-ecosystem-ci]

📝 Ran ecosystem CI on df9641e: Open

suite	result	latest scheduled
react-router	❌ failure	❌ failure
sveltekit	❌ failure	❌ failure
vite-environment-examples	❌ failure	❌ failure
vite-plugin-rsc	❌ failure	❌ failure
qwik	✅ success	❌ failure
storybook	❌ failure	❌ failure
vitest	❌ failure	❌ failure
waku	❌ failure	❌ failure

✅ nitro, analogjs, astro, laravel, marko, vike, quasar, vite-plugin-pwa, module-federation, unocss, vite-setup-catalogue, tanstack-start, vite-plugin-vue, nuxt, vite-plugin-svelte, vite-plugin-cloudflare, vinext, vitepress, vuepress, vite-plugin-react