You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not uncommon for a bundler to be launched in watch mode by some higher level web framework. Sometimes these frameworks are running on runtimes that do not expose OS process control APIs for portability reasons. Speaking for BEAM VM that powers Phoenix web framework e.g., if Bun is launched by Phoenix and then Phoenix dies, that just leaves a dangling Bun process.
It would be nice to have Bun itself monitor its own stdin in the Bundler and Watch mode and exit itself when stdin closes, because that's the only conventional and cross-platform way of knowing that parent process died.
What is the feature you are proposing to solve the problem?
To be minimally obtrusive, we can only enact this behaviour when stdin is not a TTY. This is what esbuild does.
Currently the workaround is to use a wrapper program/script with child process control capability to do this on behalf of Phoenix. It can even be another Bun program, which is how one integration with Phoenix does it. But if we can avoid an extra process, I think we should.
The text was updated successfully, but these errors were encountered:
What is the problem this feature would solve?
It's not uncommon for a bundler to be launched in watch mode by some higher level web framework. Sometimes these frameworks are running on runtimes that do not expose OS process control APIs for portability reasons. Speaking for BEAM VM that powers Phoenix web framework e.g., if Bun is launched by Phoenix and then Phoenix dies, that just leaves a dangling Bun process.
It would be nice to have Bun itself monitor its own stdin in the Bundler and Watch mode and exit itself when stdin closes, because that's the only conventional and cross-platform way of knowing that parent process died.
What is the feature you are proposing to solve the problem?
To be minimally obtrusive, we can only enact this behaviour when stdin is not a TTY. This is what esbuild does.
This seems to be a good survey on what many tools does with regard to this behaviour: tailwindlabs/tailwindcss#9264 (comment)
What alternatives have you considered?
Currently the workaround is to use a wrapper program/script with child process control capability to do this on behalf of Phoenix. It can even be another Bun program, which is how one integration with Phoenix does it. But if we can avoid an extra process, I think we should.
The text was updated successfully, but these errors were encountered: