Improve hot-reloading building only the necessary files (now is building all the app again)

[aralroca]

Currently, our build process has several workarounds that make it difficult to have an optimized hot reloading.

Instead of doing 2 parallel server-client builds, we are doing the following:

1. We are making a build of all the server entry points, this, during this build also serves as an analysis to know which web components and actions consume each entry point to later make the client builds.
2. After the server build, in a sequential way, a build of the actions is generated, already with the entry point bundled.
3. For each page (entry-point), a separate build is generated with all the web components it needs. This is a current workaround since IIFE Bun build is not supported at the moment, and it is the way we found to support it. It is not efficient at all, because if you have 100 pages, it is 100 builds and they will not be parallelized because Bun blocks the thread.

All this workaround makes the current hot-reloading very bad. For each change, a build of the whole app is performed: server + actions + each client page.

People say it goes fast, but if it goes fast it is because Bun is fast and the parser and generator we use is fast (meriyah + astring), but not because of our implementation.

Now Bun is optimizing this part in Bun Kit (or Bun Bake), to support a server build alongside a client build and work with hot-reloading, and also supporting IIFE (finally). I wonder, to what extent it is intended for all JSX-runtimes and how feasible it is to make this migration from the current system to the new tool offered by Bun.

• Tweet

@paperdave Could you please provide us with feedback on whether it is actually possible to migrate with the canary branch of Bun? Better to wait? Or is it not compatible with what you are doing? As a note, since Brisa framework is now in an experimental stage, if you want to collaborate in Brisa to test Bun Kit beyond React, it would be totally welcome 🤗

Note

We use Bun for all the tooling part. For the output we support both Bun and Node.js.

[paperdave]

i expect most of your bundling code to be replaced by Bake. current canary branch is still very very experimental, and it's marked experimental because the shape of the api is not fully decided. for example, the way it specifies routes isnt really great.

the way bake is designed is the framework is responsible for (non-exhastive)

• determining list of routes
• providing bundler configuration
• implementing the request handler (given the route's module as input)
• client entry point (rendering and client side routing, currently there is only one of these)
• providing implementations for some Server Components apis such as createClientReference

in return, Bake gives

• all bundling and asset handling, from the fast HMR dev server to production builds
• http server and server side routing
• server components, react fast refresh, etc

[aralroca]

This will definitely fix our hotreload and build time. I wonder how feasible it will be to touch the AST in the same way we are doing with Bun.build, both for analysis and some modifications, if we already have this, it would surely be fully compatible.

[paperdave]

i havent added plugin support to bake yet but it shouldnt be a huge problem, it mostly waits on some minor cleanup i need to do

[aralroca]

@paperdave I’ve submitted a Bun issue proposing a feature that could greatly improve entrypoint analysis for both Bake and Bun.build. In Brisa we use it for detecting which i18n keys are consumed in the web components, so that each page loads later during Bun.serve the i18n keys that the page needs according to the language.

However, now we can do it because until recently IIFE was not supported, and for each client page we were doing a different build with a single entrypoint as IIFE workaround (which makes it take a long time to build for large codebase projects).