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
We used rsbuild as a batteries included build tool during our prototyping phase, but now we're building things out and looking to have more control over our build output, it seems to be getting in the way of certain things. Examples of what we've encountered so far:
there seems to be no way of outputting ES modules: we can override the rspack config from within rsbuild to do this, but it breaks, presumably because rsbuild has assumptions around cjs baked in
we have to use a plugin to reset the SVG loader config so we can then redefine them our way: we may end up having to do this with all the assets we import, and there's no guarantee future rsbuild updates won't change existing behaviour we rely on
We don't want to end up in the create-react-app hell that we found ourselves with in yari, with defaults we don't use or understand, combined with hacky overrides.
I still need to look into the behaviour of rspack's dev server: it's a different codebase to rsbuild's, so we may have to change how we do a few things internally.
This isn't super high priority: how we write our components should be pretty agnostic to how we bundle them, so I'm thinking I'll do this a little later on once we've fully finishing setting up our scaffolding and are burning down the migration of components.
The text was updated successfully, but these errors were encountered:
Thank you for sharing your concerns about Rsbuild! I'd like to clarify some important distinctions and address the specific points you've raised.
Rsbuild is fundamentally different from CRA:
Rsbuild is developed by the Rspack team, includes default behaviors that we encourage, and is designed to address webpack's DX challenges.
Unlike CRA, Rsbuild's philosophy emphasizes being both out-of-the-box and maintaining transparency and extensibility. For example, Rsbuild provides a debug mode to inspect the generated Rspack configuration, along with tools.rspack and tools.bundlerChain for modifying any Rspack configuration.
Regarding the specific issues mentioned:
ESM support: Rsbuild is not built around CJS. It supports outputting ESM bundles (although this currently requires manual Rspack configuration changes - we're considering providing more out-of-the-box approach). Both Rslib and rsbuild-plugin-react-router use Rsbuild to emit ESM bundles.
Asset rules: Rsbuild's built-in rules have reached relative stability, and we avoid making minor changes to these rules. The default rules typically satisfy most use cases. If needed, removing built-in rules through tools.bundlerChain is quite easy:
exportdefault{tools: {bundlerChain(chain,{CHAIN_ID}){// Remove the built-in SVG rulechain.module.rules.delete(CHAIN_ID.RULE.SVG);},},};
Additionally, if fred encounters any challenges while customizing Rsbuild, I would be more than happy to participate in discussions and help find solutions. 😄
We used rsbuild as a batteries included build tool during our prototyping phase, but now we're building things out and looking to have more control over our build output, it seems to be getting in the way of certain things. Examples of what we've encountered so far:
there seems to be no way of outputting ES modules: we can override the rspack config from within rsbuild to do this, but it breaks, presumably because rsbuild has assumptions around cjs baked in
we have to use a plugin to reset the SVG loader config so we can then redefine them our way: we may end up having to do this with all the assets we import, and there's no guarantee future rsbuild updates won't change existing behaviour we rely on
We don't want to end up in the create-react-app hell that we found ourselves with in yari, with defaults we don't use or understand, combined with hacky overrides.
I still need to look into the behaviour of rspack's dev server: it's a different codebase to rsbuild's, so we may have to change how we do a few things internally.
This isn't super high priority: how we write our components should be pretty agnostic to how we bundle them, so I'm thinking I'll do this a little later on once we've fully finishing setting up our scaffolding and are burning down the migration of components.
The text was updated successfully, but these errors were encountered: