trunk serve can get caught in a build loop when compiling web workers

[gilescope]

If I make a change and trunk serve detects it and rebuilds my code and the web worker, it occasionally will go into a loop. I guess the building of one can sometimes trigger the rebuilding of the other and so on and so on... a restart fixes it and then it's well behaved for a while. Does the webworker generat a js file that re-triggers the build or something?

[simbleau]

I've noticed this happens when I sometimes git pull or bring in new files. Still trying to find the root cause.

My theory is that (without looking at the code) It probably rebuilds once per new file introduced, so if a lot of new code gets introduced at once, it may be re-compiling for a while, and seem like an infinite loop.

[Mubelotix]

This happens to me all the time, trunk spends 100% of the time rebuilding useless stuff

[DimitriTimoz]

I'm also affected it's also maybe a duplicate of #382

[gilescope]

Most of the time it does eventually settle down and stop rebuilding… mostly… to be honest I am so thankful to trunk for making web workers work so nicely that I almost don’t want to bring it up!

On Sat, 27 Aug 2022 at 19:17, DimitriTimoz @.***> wrote:

I'm also affected it's also maybe a duplicate of #382 https://github.com/thedodd/trunk/issues/382

— Reply to this email directly, view it on GitHub https://github.com/thedodd/trunk/issues/422#issuecomment-1229240000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGEJCDOXV35R3BIT2NAJGLV3JLS7ANCNFSM57ZKKSHA . You are receiving this because you authored the thread.Message ID: @.***>

[webbertakken]

It probably rebuilds once per new file introduced, so if a lot of new code gets introduced at once, it may be re-compiling f

Having witnessed this quite a few times by now, this seems to be accurate.

Another example is that when using cargo clippy as an external linter in WebStorm, it'll compile 2 to 3 times more than normal when saving, because the file actually changes multiple times.

It looks like each change queues a rebuild, where for most cases it's probably fine to just do the current and last rebuild.

[thedodd]

@gilescope that's it ... we're removing support for web workers in Trunk! Too much maintenance overhead!

JK JK, hopefully we can get this issue pinned down soon.

[thedodd]

@gilescope @webbertakken @Mubelotix if folks don't mind running trunk with verbose logging, it will tell you where the changes were detected. EG: trunk -v serve

So, if you are certain that this is not a config issue, then this is probably the next best thing to look into. Find out which files are changing which are causing trunk to re-build, then we can determine the root cause.

You should see a log line similar to:

2022-11-28T17:11:25.541456Z DEBUG change detected in "{base_path}/src/bin/worker.rs"

[rlane]

This happens to me often when switching branches. When running trunk with the -v flag I see it's doing a rebuild for each changed file. This is with trunk 0.16.0.

[ctron]

I guess this is another variation which might be fixed by either #516 or #569

[thedodd]

Ok, looks like this is a known issue which folks are seeing: https://github.com/notify-rs/notify/issues/259

As it turns out, this is not due to a library we are using, but comes from std::fs::copy, which I have verified. I don't know how broadly this applies across platforms; however, it is broad enough that it has impacted a lot of folks.

I've implemented a solution to address this. A cooldown period following a build. All events will be ignored following a build completion for the cooldown period, which I will hardcode to 1s for now. That should be enough without impacting the development flow.