next.config.js bundle timeout deploys a broken build

[rasendubi]

https://github.com/firebase/firebase-tools/pull/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 https://github.com/firebase/firebase-tools/commit/e5981f2e0f40ff87139039cb5ac5004231f2e69f (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

[leoortizz]

Hey @rasendubi, thanks for reporting. I discussed this with @alexastrum and we decided to increase the timeout to 60 seconds to workaround the network issues. It will be available in the next release.

[rasendubi]

Hey @leoortizz. Increasing the timeout doesn't sound like a solution.

It surely decreases the chance of failure but I still don't like that there is a 0.1% chance that it will silently deploy crap instead of my app. I would like to reopen the issue to get it fixed.

What are the downsides to removing the timeout completely or adding esbuild as dependency? I know timeouts were introduced to prevent hang-up, but I would rather enjoy CI hang-up than production outage.

[leoortizz]

@rasendubi I understand, I'll follow up with @alexastrum for a long-term solution for this issue

[rasendubi]

Thank you! Could you please reopen the issue meanwhile?

[rasendubi]

@leoortizz could you reopen or should I open a new issue?

[leoortizz]

Hey @rasendubi, are you still having this issue?

[google-oss-bot]

Hey @rasendubi. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[rasendubi]

I have applied the workaround locally (added esbuild to my dependencies), so I cannot comment on whether the issue has been fixed or not.

[chalosalvador]

@rasendubi this issue should have been fixed by #7395 would you mind trying it out with the latest version of Firebase CLI and confirm if the issue has been resolved?

[rasendubi]

I no longer work on that project, so I cannot test.

I looked through #7395 and it looks like it fixes the issue by removing timeout. The worrying catch1 that proceeds to deploy broken build is still in place though.