mcpField
R
rspack-best-practices

rspack-best-practices

github.com/rstackjsDevelopment97676 installsUpdated 6d ago
Repository

About rspack-best-practices

A skill for configuring, building, and reviewing projects that use Rspack. It provides guidance on CSS, assets, type checking, bundle optimization, profiling, and security.

Key features

  1. 01Configuration and CLI guidance
  2. 02CSS strategy recommendations
  3. 03Asset handling practices
  4. 04Type-checking options
  5. 05Bundle optimization and profiling
  6. 06Source map security guidance

Use cases

  1. 01Setting up an Rspack project configuration
  2. 02Choosing CSS and asset handling approaches
  3. 03Investigating build performance or output

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rstackjs/agent-skills --skill rspack-best-practices

After installing, type/rspack-best-practicesin Claude Code to confirm it loaded.

Details

From the project README

Rspack best practices

Apply these rules when writing or reviewing Rspack projects.

Configuration

  • Use rspack.config.ts and defineConfig
  • Define explicit entry values for multi-page applications
  • Keep one main config and branch by process.env.NODE_ENV only when needed
  • Keep rule conditions narrow and explicit (test, include, exclude, resourceQuery)
  • Prefer built-in Rspack plugins/loaders over community JS alternatives when equivalent features exist

CLI

If @rspack/cli is installed:

  • Use rspack dev for local development
  • Use rspack build for production build
  • Use rspack preview only for local production preview

Type checking

  • Use ts-checker-rspack-plugin for integrated dev/build type checks
  • Or run tsc --noEmit/vue-tsc --noEmit as an explicit script step

CSS

Choose one strategy:

  • Built-in CSS (type: 'css' | 'css/auto' | 'css/module') for modern setups
  • css-loader + CssExtractRspackPlugin for webpack migration compatibility
  • style-loader for pure style-in-JS runtime injection scenarios

Optional:

  • Use builtin:lightningcss-loader when goals are syntax downgrade + vendor prefixing
  • Use sass-loader/less-loader for preprocessing Sass/Less files
  • Use @tailwindcss/webpack for Tailwind CSS integration

Bundle size optimization

  • Prefer dynamic import() for non-critical code paths
  • Prefer lightweight libraries where possible
  • Keep target aligned with real compatibility requirements

Asset management

  • Import source-managed assets from project source directories, not from public
  • Reference public files by absolute URL path
  • Prefer asset modules (asset, asset/resource, asset/inline, asset/source) over legacy file-loader/url-loader/raw-loader

Profiling

  • Use Node CPU profiling (--cpu-prof) when JavaScript-side overhead is suspected
  • Use RSPACK_PROFILE=OVERVIEW and analyze trace output for compiler-phase bottlenecks
  • Replace known slow stacks first (babel-loader, PostCSS, terser) with Rspack built-ins when feasible

Security

  • Do not publish .map files to public servers/CDNs when production source maps are enabled

Documentation

Comments

Markdown supported