Make `ssr.noExternal` shallow

Description

Current behavior in v2: when an SSR dependency some-library is noExternal, then Vite will as well noExternal all some-library’s dependencies.

Current behavior in v3 (beta): slightly better because it only noExternal dependencies of some-libraries that cannot be resolved. (Correct me if I’m wrong.)

Suggested solution

Externalize all some-library’s dependencies. I.e. only make some-library noExternal.

Priority

Low. (Because AFAICT this doesn’t cause the same problems than noExternalize too many SSR user dependencies.)

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

[brillout]

It is the other way around. IIUC, in v2 sub-dependencies of some-library will end up being external

I just tried and it does seem to be as I described. (The VikePress dependency tweemoji is living in dist/.)

this is broken if we also don’t rewrite imports to resolved node_modules paths that may also break in prod, no?

Yes exactly, see my previous reply.

[brillout]

It’s the reason why we split dependencies and devDependencies in the first place, so I think it’s fairly common.

I see, that makes sense.

Lock files won’t help unless vikepress is a “dependency” which npm install --prod would only then install. If it’s a “devDependency”, we can’t access twemoji even if we resolved to a deep path because it’s not installed.

Vite only needs to resolve twemoji If it occurs somewhere in the code. If it occurs somewhere in the code then it’s not a devDependency to start with.

So I still think a lock file works (as long as the package manager produces a node_modules file structure that is stable given a specific lock file).