firebase/firestore breaks Next.js builds due to grpc limitations

[ctavan]

[REQUIRED] Describe your environment

• Operating System version: macOS 10.14.6 (18G103)
• Browser version: any
• Firebase SDK version: 7.1.0
• Firebase Product: firestore

[REQUIRED] Describe the problem

Using firebase/firestore in Next.js apps currently breaks serverside builds (next build command), see vercel/next.js#7894.

next build uses node worker_thread's to pre-render/optimize SSR pages. If there are multiple pages that import 'firebase/firestore';§ the build fails with:

Error: Failed to load /node_modules/grpc/src/node/extension_binary/node-v72-darwin-x64-unknown/grpc_node.node. Module did not self-register.

The underlying issue seems to be that grpc (native) does not support multiple threads: grpc/grpc-node#778

At first I thought #2010 (comment) was a similar issue and I tried fiddling around with webpack externals config as suggested in #1455 (comment) but to no success.

An obvious "fix" would be to finally migrate to @grpc/grpc-js as suggested in #1783

Any other idea on how to work around this issue?

Steps to reproduce:

See vercel/next.js#7894 (comment)

[thebrianchen]

@ctavan Thanks for reporting! Migrating to @grpc/grpc-js results in a breaking change due to the higher node version requirement, and we will reassess if the migration is acceptable. It should be released with the next major version bump, but that date is currently not yet set. We're also looking into adding support for using custom implementations of grpc, similar to the functionality on the server SDKs, but that would be a more substantial task.

In the meantime, the best workaround is to use a custom version of the Firebase SDK with the PR introducing @grpc/grpc-js rebased on top.

[ctavan]

Thanks for your feedback!

For the time being this was resolved in Next.js (vercel/next.js#9199) by disabling worker_threads by default and therefore avoiding the lack of multithreading support in grpc.

So while this is no longer urgent to me I personally believe that the SDK would generally benefit (interoperability-wise) from migrating away from the native grpc bindings to a pure JS implementation.