vite: SSR fails on sub-package imports when `exports` field is defined (can't SSR Firebase v9)

Describe the bug

tryNodeResolve fails on Firebase.

It swallows this exception from _resolveExports inside resolveExports:

Missing “.” export in “firebase” package

It seems reasonable that Firebase doesn’t export this because they don’t allow you to import firebase. You have to import a sub-package like firebase/functions, etc. I don’t see anything in the Node docs that says you must export .

As a result, Firebase is not treated as external eventhough it provides a CJS build. This in turn causes SSR to fail when using Firebase

Reproduction

https://github.com/benmccann/sveltekit-firebase

System Info

Vite 2.4.4

Used Package Manager

npm

Logs

Vite doesn’t output any logs. I sent a PR to fix that: https://github.com/vitejs/vite/pull/4426

Validations

Follow our Code of Conduct
Read the Contributing Guidelines.
Read the docs.
Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 19 (9 by maintainers)

Most upvoted comments

Part of my proposal is to always externalize SSR dependencies (unless it’s added in ssr.noExternalize).

Because Firebase is externalized, the loading will be done by Node.js, not by Vite.

With my ESM Plan proposal, because all SvelteKit users have type: "module" in their package.json, Vite would leave the import statements as-is, instead of transpiling them to require. (That’s the whole point of setting type: "module" after all: using ESM instead of CJS.)

It will then be Node.js that 1. resolves the firebase import and 2. loads the firebase code. Things will then work. Why am I so confident? Because Firebase is already used by bunch of vanilla Node.js users today. Although type: "module" may break things, but that would be a Firebase problem not supporting ESM users, and certainly not a Vite problem since Vite stays out of the picture here.

The whole point of my proposal is to get Vite out of the way and let Node.js handle things.

Does that make more sense?

brillout on Jul 30, 2021

@worxto please open issue with a reproduction

Niputi on Nov 18, 2021

Are you sure it’s not already the case? Isn’t that precisely the whole point of externalizing a dep? To me “externalize” = let Node.js handle it.

Actually, I’m not so sure now. It looks like it often does work. I will have to see if I can come up with a good reproduction. Unfortunately most of the cases I’m seeing also are hitting another bug and it’s difficult to untangle

benmccann on Aug 2, 2021