agentleFS
Sign inStart free
rstackjsrstackjs/agent-skills/skills/rspack-best-practices/SKILL.md

rspack-best-practices

Skill97 starsChanged 3 months agoMITView on GitHub

Configure, review, or troubleshoot Rspack builds, including loaders, CSS, assets, type checking, bundle optimization, and profiling.

  • Reads credentials

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 2 are distinctive, and 18 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 18

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use rspack.config.ts and defineConfig

    line 12
  2. Very specific:

    Keep one main config and branch by process.env.NODE_ENV only when needed

    line 14
  3. Very specific:

    Keep rule conditions narrow and explicit (test, include, exclude, resourceQuery)

    line 15
  4. Distinctive:

    Prefer built-in Rspack plugins/loaders over community JS alternatives when equivalent features exist

    line 16
  5. Very specific:

    If @rspack/cli is installed:

    line 20
  6. Very specific:

    Use rspack dev for local development

    line 22
  7. Very specific:

    Use rspack build for production build

    line 23
  8. Very specific:

    Use rspack preview only for local production preview

    line 24
  9. Very specific:

    Use ts-checker-rspack-plugin for integrated dev/build type checks

    line 28
  10. Very specific:

    Use builtin:lightningcss-loader when goals are syntax downgrade + vendor prefixing

    line 41
  11. Very specific:

    Use sass-loader/less-loader for preprocessing Sass/Less files

    line 42
  12. Very specific:

    Use @tailwindcss/webpack for Tailwind CSS integration

    line 43
  13. Very specific:

    Prefer dynamic import() for non-critical code paths

    line 47
  14. Distinctive:

    Prefer lightweight libraries where possible

    line 48
  15. Very specific:

    Keep target aligned with real compatibility requirements

    line 49
  16. Very specific:

    Import source-managed assets from project source directories, not from public

    line 53
  17. Very specific:

    Prefer asset modules (asset, asset/resource, asset/inline, asset/source) over legacy file-loader/url-loader/raw-loader

    line 55
  18. Very specific:

    Use Node CPU profiling (--cpu-prof) when JavaScript-side overhead is suspected

    line 59
  19. Very specific:

    Use RSPACK_PROFILE=OVERVIEW and analyze trace output for compiler-phase bottlenecks

    line 60
  20. Very specific:

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

    line 65

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free