Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Watch mode behavior on failed first builds #1037

Closed
padmaia opened this issue Mar 23, 2021 · 4 comments · Fixed by #2816
Closed

Watch mode behavior on failed first builds #1037

padmaia opened this issue Mar 23, 2021 · 4 comments · Fixed by #2816
Labels

Comments

@padmaia
Copy link

padmaia commented Mar 23, 2021

I've noticed that watch mode only works if the first build is successful. Is this intentional?

My use case is a large repository with many apps and a single development server that lazily builds these apps in watch mode as they are requested. The server also establishes a web socket connection so the apps reload on successful rebuilds or render an error overlay if the build failed. Ideally the server could rely on esbuild's watch mode completely to know when to send these web socket messages, but currently I would have to set up my own watcher and retry starting esbuild in watch mode in the case where the build fails on the first try.

@evanw
Copy link
Owner

evanw commented Mar 24, 2021

Just got a chance to look into this. It looks like it works with the CLI and Go APIs but not with the JavaScript API because the JavaScript API is designed to throw an exception when there are build errors. I'll need to think about how to solve this from an API design perspective.

@evanw evanw added the breaking label Mar 24, 2021
@ggoodman
Copy link

Some of the different challenges around handling the state transitions are described here: #814 (comment).

@evanw
Copy link
Owner

evanw commented Mar 26, 2021

There's an interesting problem with doing this: #1063. If the initial build fails due to a plugin throwing an error, esbuild doesn't necessarily have enough information to know what to watch. In that case allowing watch mode to progress if the initial build fails could potentially leave watch mode in a broken state. Just linking these two issues because they seem related.

threepointone added a commit to cloudflare/workers-sdk that referenced this issue Mar 31, 2022
Because of evanw/esbuild#1037, we can't recover dev if esbuild fails on first run. The workaround is to end the process if it does so, until we have a better fix.

Reported in #731
threepointone added a commit to cloudflare/workers-sdk that referenced this issue Mar 31, 2022
Because of evanw/esbuild#1037, we can't recover dev if esbuild fails on first run. The workaround is to end the process if it does so, until we have a better fix.

Reported in #731
@lydell
Copy link

lydell commented May 14, 2022

I used esbuild --watch ... but noticed my use case was too advanced for the CLI, so I looked into using the JS API. But due to this issue, esbuild.build({ watch: true, ... }) is almost useless (ok, that’s overreacting 😅 ). It’s not uncommon to start build tools with errors in your code, for example when you pick up where you left off the previous day. Would be awesome if this could be improved!

EDIT: Applying this patch with patch-package seems to do the trick for my use case!

diff --git a/node_modules/esbuild/lib/main.js b/node_modules/esbuild/lib/main.js
index 094cde7..e754aa1 100644
--- a/node_modules/esbuild/lib/main.js
+++ b/node_modules/esbuild/lib/main.js
@@ -1245,7 +1245,7 @@ function createChannel(streamIn) {
       };
       copyResponseToResult(response, result);
       runOnEndCallbacks(result, logPluginError, () => {
-        if (result.errors.length > 0) {
+        if (result.errors.length > 0 && !watch) {
           return callback2(failureErrorWithLog("Build failed", result.errors, result.warnings), null);
         }
         if (response.rebuild) {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants