Next.js: Build fails when importing Firestore and using target serverless

[ferezoz]

Bug report

Describe the bug

Build fails when importing Firestore and using target: 'serverless' even after upgrading next to at least version 9.0.4 as mentioned here: https://github.com/zeit/next.js/issues/6073#issuecomment-467589586.

Module not found: Can't resolve 'memcpy' in '.../node_modules/bytebuffer/dist'

To Reproduce

1. package.json:

"dependencies": {
    "firebase": "^6.5.0",
    "next": "^9.0.5",
    "react": "^16.8.6",
    "react-dom": "^16.8.6"
  },

1. firebase.js:

import firebase from 'firebase/app';
import 'firebase/firestore';

const config = {
  ...
};

const firebaseApp = !firebase.apps.length
  ? firebase.initializeApp(config)
  : firebase.app();

const firestore = firebaseApp.firestore();

export default firebaseApp;

export { firestore };

1. next.config.js:

module.exports = {
  target: 'serverless',
};

Expected behavior

Build should succeed.

Screenshots

System information

• Version of Next.js: 9.0.5
• Version of firebase: 6.5.0

Additional context

It works on local next dev.

[timneutkens]

This is fixed through the experimental-serverless-trace right @Timer?

[Timer]

Yes, setting target: 'experimental-serverless-trace' should fix this issue.

FYI: @ferezoz due to the way Firebase is designed, it's not compatible with target: 'serverless' -- we introduced a new mode to fix this (experimental-serverless-trace)!

[Timer]

We should look at de-experimentalizing this (because it's no longer experimental).

[ferezoz]

@Timer Thank you it worked!
Whats the difference between experimental-serverless-trace and serverless? Because I see the build emits lambdas as well. Should I need to consider something?

Edit: I see from https://github.com/zeit/next.js/pull/8246 that experimental-serverless-trace has a smaller bundle size than serverless?

[Timer]

The difference is that serverless bundles node_modules and experimental-serverless-trace does not!

Bundling node_modules is very problematic for server-side code, as it may rely on compiled binaries (like gRPC for Firestore) or reading certain files from the file-system (fs.readFileSync()).
Bundling these modules means the files they're looking for no longer exist at the same path -- so it's generally not safe to do so.

This problem doesn't exist for client-side code because there's no concept of external files in the browser.

All things considered (ready-to-go .zip lambdas), experimental-serverless-trace output size should be identical or slightly smaller than a functioning-equivalent serverless output.

---

Should I need to consider something?

If you're deploying to ZEIT Now: Nope! We automatically handle and optimize lambda size for you.

If you're self-hosting via next start: Don't delete the node_modules folder! It'll be required by your lambdas. Optimizing for a minimal node_modules folder will require additional work, but is handled automatically on ZEIT Now.

[ferezoz]

Thank you for the explanation! 🙂 I'm using ZEIT Now so I don't need anything else.
The issue is fixed for me, should I close the ticket or maybe you want it open to track the de-experimentalization?

[timneutkens]

This is tracked somewhere else right now, so let's close this issue 👍