- Home
- Skills
- Rstackjs
- Agent Skills
- Rsbuild Best Practices
rsbuild-best-practices_skill
- JavaScript
36
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill rstackjs/agent-skills --skill rsbuild-best-practices- SKILL.md1.9 KB
Overview
This skill captures Rsbuild best practices for config, CLI workflow, type checking, bundle optimization, asset handling, debugging, and profiling. It is intended to guide engineers writing, reviewing, or troubleshooting Rsbuild projects. The content focuses on concrete, actionable rules that reduce build errors, shrink bundles, and speed up iteration cycles.
How this skill works
The skill summarizes recommended patterns for rsbuild.config.ts usage, CLI commands, and TypeScript integration so teams adopt consistent workflows. It highlights where to prefer first-class Rsbuild options versus lower-level rspack/bundlerChain hooks and explains debugging and profiling steps to diagnose config and compile issues. Practical rules on assets, public files, source maps, and runtime imports help maintain security and optimize bundle size.
When to use it
- When starting a new Rsbuild project or converting an existing build to Rsbuild
- During code reviews to validate config and CLI usage
- While troubleshooting build failures, unexpected bundle size, or runtime asset problems
- When adding TypeScript or optimizing production bundles
- When preparing production deployments and verifying source map/security settings
Best practices
- Centralize config in rsbuild.config.ts and export via defineConfig for predictable resolution
- Prefer first-class Rsbuild options; use tools.rspack or tools.bundlerChain only if no native option exists
- Declare explicit source.entry values for multi-page apps to avoid ambiguous bundling
- Integrate type checks either with @rsbuild/plugin-type-check or via tsc/vue-tsc --noEmit scripts
- Use dynamic import() for non-critical code, choose lightweight libraries, and align browserslist with real target browsers
- Import source-managed assets from src; reference static files in public by absolute URL and avoid publishing .map files publicly
Example use cases
- Create rsbuild.config.ts with defineConfig, explicit entries, and path alias precedence from tsconfig.json
- Run rsbuild dev for local iteration, rsbuild build for production, and rsbuild preview only to locally validate the production output
- Add @rsbuild/plugin-type-check in CI for build-time type validation or run tsc --noEmit in a prebuild step
- Refactor large synchronous modules to dynamic import() to reduce initial bundle cost
- Enable DEBUG=rsbuild to trace plugin resolution and inspect dist/.rsbuild for computed final config
FAQ
No. Use first-class Rsbuild options when available. Resort to tools.rspack or tools.bundlerChain only when no native option supports your need.
How do I avoid shipping source maps publicly?
Disable publishing .map files to public servers or CDNs for production builds. Keep source maps in private artifact storage or restrict access.