#5691 introduced a 10s timeout for bundling next.config.js. This bundling uses npx esbuild next.config.js command and it may timeout for a variety of reasons (most likely, network-related).

When this happens, the code fallbacks to copying next.config.js to the output. However, if next.config.js imports any other local file, copying next.config.js is not enough (as the other file needs to be copied as well).

This led to our CI silently deploying a broken build to production (sometimes) which then failed with hard to understand errors.

There are a couple of possible fixes, and I'm not sure which one is better:

• remove timeout for esbuild
• add esbuild to firebase-tools' dependencies, so bundling does not depend on network speed
• in fallback, copy all source files to output
• in fallback, stop the build

cc @jamesdaniels @leoortizz

[REQUIRED] Environment info

firebase-tools: anything after e5981f2 (11.30.0+)

Platform: any

[REQUIRED] Test case

next.config.js:

require('./other');

module.exports = {};

other.js:

[REQUIRED] Steps to reproduce

• flush npm/npx cache: rm -rf "$(npm config get cache)/_npx"
• run env FIREBASE_CLI_EXPERIMENTS=webframeworks firebase deploy
• loop until fails

[REQUIRED] Expected behavior

It works

[REQUIRED] Actual behavior

SSR is deployed but fails at runtime.

Workaround

The simplest workaround is to add esbuild to your project's dependencies. This will cause npx to use project-installed version, so it can't timeout due to network