Repo guidance: Avoid bundler-specific assumptions

Historically many repos standardized on Webpack. Over time this encourages patterns that implicitly assume "Webpack is the bundler" ("webpackisms"). Cloudpack abstracts the bundler so that we can switch to faster or more capable alternatives (Ori, Rspack, Rollup). Code that relies on Webpack-only features becomes fragile or non‑portable.

Anti-patterns and alternatives

Pattern	Problem	Alternative
Calling globals like setWebpackPublicPath() unguarded	Breaks when using another bundler which doesn't inject this function	Feature-detect: if (typeof setWebpackPublicPath === 'function') { setWebpackPublicPath(...); }
Relying on Webpack magic comments for chunk naming for correctness	Other bundlers ignore them (they are only hints)	Avoid reliance on chunk name shapes; treat names as opaque.
Depending on loader side effects (e.g. CSS-in-JS transforms, custom file loaders) directly in source	Other bundlers may not run those proprietary loaders	Pre-bundle transform step: Convert .ejs, .graphql, proprietary formats to .ts/.js before bundling.
Importing from loader-specific virtual modules	Not portable; fails resolution elsewhere

When you need a custom transformation

Option: Pre-build script

1. Add a pre-build script that writes generated .ts files.
2. Commit or cache them (ensure deterministic generation).
3. Consume the generated plain TypeScript from application code.

This keeps bundler configuration minimal and portable.

Option: Use bundler capabilities (built‑in or custom)

If a transformation can be expressed as config mutation, consider a bundler capability:

• Built-in capabilities: alias, asset-inline, define, resolve-web-extensions
• Custom capability: register a capability in bundlerCapabilitiesRegistry that injects a plugin / transform for the bundlers you care about