DEV Community: Krzysztof Sordyl

Part 4: Migration to RsBuild

Krzysztof Sordyl — Sun, 07 Sep 2025 06:08:33 +0000

Recap of Part 3. In the previous episode, we added:

Jest test runner
CSS with PostCSS
asset handling
bundle-size observability

As the boilerplate grows, so do:

setup code
configuration surface
plugin/tool dependencies

You could ship this as an npm package (like react-scripts / next-scripts) to hide bundler complexity—but that requires:

ongoing maintenance and versioning
an internal abstraction for bundler setup

Alternative

If we proceed with Webpack in this part, we’ll most likely:

migrate Babel → SWC for faster transforms
migrate Jest → Vitest
enable source maps
tune chunk splitting
explore SSR support

Instead, this part migrates the boilerplate to Rsbuild and evaluates the trade-offs.

Why Rsbuild?

Powered by Rspack (Webpack-compatible APIs) with a “batteries-included” DX similar to Vite.
It’s faster than Webpack and needs less boilerplate.

Vite

Vite is a go-to modern build tool. It isn’t part of this comparison because an apples-to-apples (Rust vs Rust) test would use Vite + Rolldown, which isn’t fully stabilized yet.
Also, Rspack (the bundler inside Rsbuild) exposes Webpack-compatible APIs, so migrating from Webpack to Rsbuild is typically smoother than switching to Vite.

You can see direct benchmarks here: Rspack benchmarks.

Establishing comparison metrics

To compare two tools we need a set of metrics:

bundle size
build time (local and CI)
dev-server readiness time
package.json dependency count
overall project size on the machine
install time of the project dependencies (with existing node_modules)
boilerplate lines of code (without node_modules, package-lock.json)

Environment controls

Hardware: MacBook Air M1 (local), GitHub Actions free tier (CI)
Node & package manager: Node 22 LTS (22.19.0), installs with existing node_modules
Sampling: 5 runs for time-related metrics
Tooling:
- timing: time
- bundle: stat size and gzipped bundle
- size: du -sh (project); jq for .dependencies and devDependencies
- dev-server readiness: time printed by the bundler when the server is ready

ℹ️ I’ll create another post with comparisons on larger, real-world apps.

Webpack results

bundle size: 199.96 KB (52.2 KB gzipped)
build time (local and CI):
- local: AVG 3.614s, MED 3.574s
- CI: AVG 6.418s, MED 6.387s
dev-server readiness time: AVG 1.024s, MED 1.023s
package.json dependency count:
- dependencies: 3
- devDependencies: 31
overall project size on the machine: 212 MB
install time of project dependencies (with existing node_modules):
- local: AVG 1.556s, MED 1.527s
- CI: AVG 10.981s, MED 11.890s
boilerplate lines of code: 285 overall

Rsbuild results

bundle size: 143.62 KB (45.62 KB gzipped) — smaller due to dropping unused core-js polyfills
build time (local and CI):
- local: AVG 0.865s, MED 0.932s
- CI: AVG 1.246s, MED 1.242s
dev-server readiness time: AVG: 0.038s, MED: 0.040s
package.json dependency count:
- dependencies: 3
- devDependencies: 16 (15 fewer)
overall project size on the machine: 216 MB (higher due to Rsbuild cache/binaries)
install time of project dependencies (with existing node_modules):
- local: AVG 1.358s, MED 1.308s
- CI: AVG 8.527s, MED 8.622s
boilerplate lines of code: 256 overall

Summary

It’s expected that a Webpack + Babel setup lags on raw performance.
Migration also improves business metrics, such as:

faster hotfix recovery, less downtime cost
faster releases, shorter time-to-market, ship value sooner
lower infra spend (at org scale)
fewer deps / simpler pipeline → less maintenance time, fewer failures/reruns
smaller bundles → cheaper bandwidth/CDN, faster pages → better conversion potential
faster dev server/local builds/HMR → less idle/wait time for engineers

Trade-offs

doesn’t have as large a plugin ecosystem as Webpack
Rspack’s design goal is not 100% compliance with the Webpack API
Rspack won’t create identical artifacts to Webpack
doesn’t support WASM for browser-side builds

That concludes this part. Full diff in the PR: https://github.com/Verthon/webpack-react-boilerplate/pull/6/files
Best one-line summary of the PR: removed-to-added code ratio +930 / −5,721.

Part 3: Asset Handling, Unit Testing, and Bundle Analysis

Krzysztof Sordyl — Sun, 14 Apr 2024 08:40:12 +0000

Recap of Part 2: In the previous installment, we integrated Babel and React into our Webpack setup, enhancing our modern SPA boilerplate.
We configured Babel to support the latest JavaScript features, TypeScript, and React JSX.
Additionally, we implemented environment variable management using dotenv and refined our Webpack configuration for handling .tsx files.

Unit testing setup

For unit tests we will use Jest which is one of most popular solutions on the market.

Install following dev-dependencies:

npm i -D jest @types/jest @swc/core @swc/jest

Jest configuration file Create jest.config.js in the root of the project.
Following config will tell jest to transform ts|js|tsx|jsx files with swc-jest
Note: swc-jest does not perform type checking in your tests.

// jest.config.js
/** @type {import('@jest/types').Config.InitialOptions} */
const config = {
  transform: {
    '^.+\\.(t|j)sx?$': '@swc/jest',
  },
  resetMocks: true,
  setupFilesAfterEnv: ['<rootDir>/testSetup.ts'],
  verbose: true,
}

module.exports = config

Environment Configuration for Testing
Introduce an env.test file to manage test-specific environment variables:

//.env.test

ENVIRONMENT_NAME=test

Setting Up Environment Variables: Configure a setup file to load the appropriate environment variables before all tests:

// test.setup.ts
import { loadEnvs } from './config/env'

beforeAll(() => {
  process.env.NODE_ENV = 'test'

  loadEnvs()
})

Verify Environment Configuration
In order to confirm the behaviour of loading test envs we could create a dummy test

// src/example.spec.ts
describe('example unit test', () => {
  it('should have the NODE_ENV equal to test', () => {
    expect(process.env.NODE_ENV).toBe('test')
  })
})

Commands for Running Tests: Update package.json with commands to run and clear the Jest cache:

"test:unit": "jest",
"test:unit:clear": "jest --clearCache"

Now the tests can be executed by typing: npm run test:unit in the terminal

Key points

the Jest setup is tailored for TypeScript files within the Node.js environment (Jest's default setting)
the setup can be easily extended with React Testing Library to cover component tests as well, however it is good to explore alternatives first 👇
especially tools that allow testing in the browser like:
from my experience in large applications developers often encounter performance issues with React Testing Library due to the rendering of extensive DOM trees and scanning through it.
additionally in heavy integration tests Playright or Cypress combined with msw for network call interception, tend to perform more efficiently

Asset handling

Webpack simplifies the management of static assets, all we need to do is to extend webpack.config.ts - module.rules

// webpack.config.ts
module: {
  rules: [
    // ... rest of the previous config
    {
      test: /\.(png|svg|jpg|jpeg|gif)$/i,
      type: 'asset/resource',
    },
    {
      test: /\.(woff|woff2|eot|ttf|otf)$/i,
      type: 'asset/resource',
    },
  ]
}

asset/resource will emit the file in the production bundle, this is beneficial because:

it won't bloat JavaScript bundle size
browsers can cache each asset independently
emited file will include hash and filename for cache-busting

CSS setup

Frontend applications are incomplete without styling. To efficiently manage CSS files within a Webpack build, we need to update config.

Install following dependencies:

npm i -D style-loader css-loader postcss-loader mini-css-extract-plugin css-minimizer-webpack-plugin postcss postcss-preset-env autoprefixer

style-loader: Injects CSS into the DOM via <style> tags, useful during development for hot module replacement.
css-loader: Resolves @import and url() within CSS files as module dependencies, enabling them to be bundled by Webpack.
postcss-loader: Integrates PostCSS into the build process, allowing for CSS transformations using plugins.
MiniCssExtractPlugin: Extracts CSS into separate files, ideal for production builds to leverage browser caching.
CssMinimizerPlugin: Optimizes and minifies CSS, enhancing load times and efficiency in production.
postcss: Facilitates the use of advanced CSS through plugins like autoprefixer and postcss-preset-env.
postcss-preset-env: Allows the use of future CSS features by compiling them to compatible code today.
autoprefixer: Automatically applies vendor prefixes to CSS rules, ensuring cross-browser compatibility based on "Can I Use" data.

Create dedicated file for post-css configuration to not bloat Webpack config file

/**
 * @type {import('postcss').ProcessOptions}
 */
const config = {
  plugins: [['postcss-preset-env', 'autoprefixer']],
}

module.exports = config

Lastly the webpack config has to be updated with loaders that were installed previously to handle CSS in JS files.
In module.rules add yet another loaders for css and post-css.
Note We only want to extract the CSS to dedicated files on production build.

// webpack.config.ts
module: {
  rules: [
    // ... rest of the previous config
    {
      test: /\.css$/i,
      use: [
        mode === 'production' ? MiniCssExtractPlugin.loader : 'style-loader',
        'css-loader',
        'postcss-loader',
      ],
    },
  ]
}

Additionally new plugins has to be initialized in the plugins array. Additionally we want to run those optimizations only on production builds.

// webpack.config.ts
import MiniCssExtractPlugin from "mini-css-extract-plugin";
import CssMinimizerPlugin from "css-minimizer-webpack-plugin";

plugins: [
  mode === "production" && new MiniCssExtractPlugin(),
    mode === "production" && new CssMinimizerPlugin(),
]

Bundle size observability

Applications bundle size tend to grow really fast, it is good idea to observe frequently how much our chunks weight.
Webpack offers advanced plugin to visualize bundle size in a graphical format.

Install dependencies:

npm i -D webpack-bundle-analyzer @types/webpack-bundle-analyzer

Optimize build commands:

regular build, which is faster and can run without issues in the pipelines
build-analyze for devs to check the bundle size using webpack-bundle-analyzer

Add the following command to your package.json, utilizing the ANALYZE_BUILD environment variable to toggle the analysis mode:

"build:analyze": "ANALYZE_BUILD=true npm run build",

Configure Webpack:
Modify your Webpack configuration to conditionally include the BundleAnalyzerPlugin based on the ANALYZE_BUILD flag.

// webpack.config.ts
import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";

const createBundleAnalyzerConfig = () => {
    const isAnalyzeMode = process.env.ANALYZE_BUILD === 'true';
    const config: BundleAnalyzerPlugin["opts"] = isAnalyzeMode
        ? { analyzerMode: "server" }
        : { analyzerMode: "disabled" };

    return config;
};

const bundleAnalyzerConfig = createBundleAnalyzerConfig();

// in the createWebpackConfig function
plugins: [
  //... rest of the config

  mode === "production" &&
    new BundleAnalyzerPlugin(bundleAnalyzerConfig),
]

Execution:

Run npm run build for a standard build, suitable for deployment and CI environments like GitHub Actions.
Use npm run build:analyze to launch a server that provides a detailed breakdown of the bundle, enabling developers to visually assess which parts are contributing most to the size.

This setup ensures that developers have the tools needed to maintain optimal performance and manageability of application bundles efficiently.

That concludes this part. You can review all the details in following PR: https://github.com/Verthon/webpack-react-boilerplate/pull/3/files

Thank you, any feedback is highly appreciated.

How I migrated from CRA to RSBuild

Krzysztof Sordyl — Sat, 13 Jan 2024 09:14:30 +0000

I recently revisited an old personal React project and discovered it was built using Create React App (CRA).
While considering a switch to Vite for its performance benefits, I stumbled upon RSBuild, which, according to its documentation, is even faster: RSBuild Performance.

Why RSBuild ?

Here are my key reasons for choosing RSBuild:

Performance: It's designed for speed.
CRA is Outdated: The last CRA release was on April 12, 2022
Migration Guide: RSBuild provides a detailed guide for seamless migration.
Batteries included: I don’t need to worry about additional integration, RSBuild covers what I need

Few words about RSBuild

RSBuild is based on RSPack, a Rust-written bundler optimized for web development. It's user-friendly and minimizes configuration needs.

Being framework-agnostic, RSBuild offers a robust plugin system. For React integration, I simply added plugins: [pluginReact()], in rsbuild.config.ts.

RSBuild's comprehensive documentation includes examples and detailed guides for migrating from:

Webpack
Create React App (CRA)
Vue CLI
Modern Builder

CSS

In my CRA project, I utilized css-modules. Fortunately, RSBuild supports it out of the box, so no extra effort was required on my part.

Environment Variables

My project only had two environments, and I wanted to move away from the REACT_APP prefix. RSBuild allowed me to easily switch to using PUBLIC as the prefix, treating all my environment variables as public, which suited my project's needs.

Testing

RSBuild doesn't integrate testing frameworks directly. Thus, there's no straight swap for react-scripts test. I set up Jest independently. To manage this, I used a separate .env.test file for test configurations. To avoid additional tooling with ts-node, I relied on standard CJS files:

I have stick with good old CJS files:

The first file is for loading environment variables: ```javascript

// src/config/loadEnvs.js

const dotenv = require('dotenv')
const path = require('path')

const loadEnvs = (mode) => {
const testOptions = mode === 'test' && {
path: path.resolve(process.cwd(), '.env.test'),
}

try {
return dotenv.config(testOptions)
} catch (err) {
console.log(err, 'Missing or wrong env files')
}
}

module.exports = { loadEnvs }


- The second file is used to load the appropriate environment variables and run Jest with arguments specified in package.json:

```javascript


const { loadEnvs } = require('./loadEnvs')

loadEnvs('test')

const argv = process.argv.slice(2)

const jest = require('jest')

jest.run(argv)

Finally, I updated the test commands in package.json to align with these changes.



const { loadEnvs } = require('./loadEnvs')

loadEnvs('test')

const argv = process.argv.slice(2)

const jest = require('jest')

jest.run(argv)

Results

Overall the migration took me around 30 minutes, which is quite fast in my opinion - even fact that my app is rather small one.
The docs are great I have easily found, what I needed, big shoutout to the RSBuild Team ❤️

The performance improvements with RSBuild were huge:

Local build time: Reduced to about 0.3 seconds 🔥.
GitHub CI: Reduced to about 0.8 seconds, which is incredibly fast 🔥.
Local development server readiness: Around 0.25 seconds.

In contrast, with CRA:

Local build time: Typically 7 to 9 seconds.
GitHub CI: Around 26 seconds.
Local development server readiness: Between 3 to 5 seconds.

Other migration cases

I also explored other developers' experiences with migrating to RSBuild, as shared on Twitter:

Part 2: Integrating Babel and React

Krzysztof Sordyl — Sun, 31 Dec 2023 09:43:17 +0000

Recap of Part 1: In the first installment of this series, we laid the groundwork for our modern React SPA boilerplate using Webpack 5.
We covered the basics of Webpack, including core
concepts like entry points, outputs, loaders, and plugins. We also set
up our npm environment, ensuring consistency with Node v20 LTS, and
introduced a basic TypeScript configuration.
With a foundational Webpack setup in place, we're now ready to dive into integrating Babel, Webpack Dev Server and React to enhance our SPA's capabilities.

Babel setup

In order to use latest JavaScript features, while supporting older browsers, we need to use transpiler. In this configuration step, we will use babel.

Install following dev-dependencies:

npm i -D babel-loader @babel/preset-typescript @babel/preset-react @babel/preset-env @babel/core

Since preset-env requires core-js we need to install it as well

npm install core-js@3

Additionally we need to specify what browsers need to be supported. You can create the required file with following command.

echo -e "> 0.25%\nnot dead" > .browserslistrc

Last but not least to finalize babel setup we would need to create babel.config.js file with following presets:

@babel/preset-env - simply allow to use latest JS syntax, without worry about browser support
@babel/preset-typescript - project uses TypeScript, so we need it
@babel/preset-react - allows Babel to parse JSX and other React related stuff

Final config file looks like this

//babel.config.js

/**
 * @type {import('@babel/core').TransformOptions}
 */
const config = {
    presets: [
        [
            "@babel/preset-env",
            {
                useBuiltIns: "usage",
                corejs: { version: "3.35", shippedProposals: true }
            },
        ],
        "@babel/preset-typescript",
        [
            "@babel/preset-react",
            {
                runtime: "automatic",
                development: process.env.NODE_ENV !== "production",
            },
        ],
    ],
};

module.exports = config;

Now we need to tell Webpack how to handle tsx and ts files, current Webpack config need to be extended with following rules:

module: {
            rules: [
                {
                    test: /\.(js|mjs|ts|tsx)$/,
                    include: path.resolve(process.cwd(), "src"),
                    loader: "babel-loader",
                },
            ],
        },
        resolve: {
            extensions: [".ts", ".tsx", ".js"],
        },

This allow to pass all the files (tsx, ts, js) in src directory through babel and apply changes to use it safely in the browser.

Environment variables

To clear any confusion around envs on the frontend, let's clarify one thing: every env listed in .env.prod will be publicly available. If you need a way to hide some sort of API_KEY - you need most likely a backend proxy layer.

With public nature of envs on frontend world, lets dive into implementation. The idea is to provide our envs and build time, so when application is being deployed the envs will be available in the runtime. Without it we would end up with runtime error: process is no defined as it is part of Node.js not browser runtime.

The whole mechanism is easily extendable for adding new environments (staging, test or whatever you want) - but for now we will stick with basic setup for:

production
local

With that in mind lets create 3 files:

.env.prod - envs for production
.env.local - envs for local development Note: it must be added to .gitignore to not expose it
.env.example - example envs structure that matches .env.prod - new dev can easily copy it and fill with proper values

For now we can add only one variable called for instance ENVIRONMENT_NAME for simplicity it cane be either prod or local

Next install package dotenv which will help us manage the environment variables:

npm i -D dotenv

Once we have the envs and dotenv installed, we need to tell Webpack to add envs to code at build time. We need some helpers functions so it would be good idea to defined them under config/env.ts with following content:

import dotenv from "dotenv";
import path from "path";

type EnvironmentVariable = Record<string, string>;

export const loadEnvs = (): EnvironmentVariable => {
    const environment = process.env.NODE_ENV || "prod";
    const envPath = path.resolve(process.cwd(), `.env.${environment}`);
    const result = dotenv.config({ path: envPath });

    if (result.error) {
        console.error(`Failed to load .env file: ${envPath}`, result.error);
        throw result.error;
    }

    return result.parsed || {};
};

export const mapEnvsToConfig = (envs: {
    [key: string]: string;
}): EnvironmentVariable => {
    return Object.keys(envs).reduce<EnvironmentVariable>((prev, next) => {
        prev[`process.env.${next}`] = JSON.stringify(envs[next]);
        return prev;
    }, {});
};

Function loadEnvs is getting proper env file based on NODE_ENV environment variable and creates config using dotenv package.

However we still need to provide envs to Webpack in proper format, this task is handled by mapEnvsToConfig

Last step is to import those functions to webpack config and provide NODE_ENV for build npm script:

Webpack

//...
import { loadEnvs, mapEnvsToConfig } from "./config/env";

const createWebpackConfig = (mode: Configuration["mode"]): Configuration => {
    // load envs
    const envs = loadEnvs();
    const envsConfig = mapEnvsToConfig(envs);

    return {
        mode: mode,
        entry: path.resolve(process.cwd(), "src/index.ts"),
        module: {
            rules: [
                {
                    test: /\.(js|mjs|ts|tsx)$/,
                    include: path.resolve(process.cwd(), "src"),
                    loader: "babel-loader",
                },
            ],
        },
        resolve: {
            extensions: [".ts", ".tsx", ".js"],
        },
        output: {
            path: path.resolve(process.cwd(), "dist"),
            clean: true,
        },
        // pass them to Webpack so that process.env.ENVIRONMENT_NAME won't be undefined
        plugins: [new DefinePlugin(envsConfig)],
    };
};

Build script - we still need to pass NODE_ENV

"scripts": {
        "build": "webpack --config scripts/build.ts --node-env=prod"
    },

React

Install React

npm i react react-dom

And types for React

npm i -D @types/react-dom @types/react

Since we are working on SPA add index.html inside of new folder public

Example content of the index.html can be as follow

<!-- index.html -->

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Webpack React Boilerplate</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

Additionally we need to tell TypeScript that we are using JSX, add following line to compilerOptions of tsconfig.json

"jsx": "react-jsx",

Next we need dummy react component and bootstrap to mount application in root

Dummy app

// src/App.tsx

export const App = () => {
    return <p>Hello World</p>;
};

// src/bootstrap.tsx

import { createRoot } from "react-dom/client";

import { App } from "./App";

const render = () => {
    const container = document.getElementById("root");
    if (container) {
        const root = createRoot(container);
        root.render(<App />);
    }
};

render();

Using render function allows us to have flexibility to pass some configuration to it, for instance when you switch from build-time envs to runtime.

Last we need to update the src/index.ts to address changes done in bootstrap

// src/index.ts

import('./bootstrap');

export {};

Finally we will setup the dev-server to be able spin up the development environment.

Install dev-server package and html plugin

npm i -D webpack-dev-server html-webpack-plugin

In order to include webpack bundles automatically as script tags in index.html we need to add HTML plugin with some configuration

//webpack.config.ts

plugins: [
            new DefinePlugin(envsConfig),
            // new plugin for dealing with HTML
            new HtmlWebpackPlugin({
                inject: true,
                template: path.resolve(process.cwd(), "public/index.html"),
            }),
        ],

Next we need function that encapsulate the creating dev-server setup create following file config/devServer.ts which will have that config function

import path from "path";
import { WebpackConfiguration } from "webpack-dev-server";

const defaultPort = Number(process.env.PORT) || 8080;

export const createDevServerConfig = (): WebpackConfiguration["devServer"] => ({
    historyApiFallback: {
        disableDotRule: true,
        index: "/",
    },
    client: {
        overlay: false,
        logging: "info",
    },
    static: {
        directory: path.resolve(process.cwd(), "public"),
        serveIndex: true,
        watch: true,
    },
    liveReload: false,
    hot: true,
    open: false,
  port: defaultPort,
});

You can define PORT environment variable if you need more flexibility otherwise it will use default 8080

Generate the dev-server only for dev mode in webpack config

resolve: {
            extensions: [".ts", ".tsx", ".js"],
        },
        // use it only for dev mode
        ...(mode === "development"
            ? {
                    devServer: createDevServerConfig(),
              }
            : {}),
        output: {
            path: path.resolve(process.cwd(), "dist"),
            publicPath: "/",
            clean: true,
        },

Last but not least we need new scripts/start.ts to be able to use it in npm scripts like build command.

import createWebpackConfig from "../webpack.config";

export default () => {
    return createWebpackConfig("development");
};

Additionally it has to be specified in package.json as well

"scripts": {
        "build": "webpack --config scripts/build.ts --node-env=prod",
        "start": "webpack serve --config scripts/start.ts --node-env=local"
    },

That concludes this part. You can review all the details in following PR: https://github.com/Verthon/webpack-react-boilerplate/pull/2

Currently we have setup for modern JS, dev-server and React. In upcoming next part configuration will be extended with:

providing assets handling configuration
providing test configuration with Jest
basic configuration for CSS
adding bundle analyzer to track bundle-size in each build
minimal docs in the readme

Thank you, any feedback is highly appreciated.

Part 1: Setting Up the Basics

Krzysztof Sordyl — Sun, 31 Dec 2023 09:33:10 +0000

Building a Modern React SPA Boilerplate with Webpack 5, Part 1: Setting Up the Basics

What is Webpack

Webpack is static module bundler - it basically takes your modules (needed to run your app) and turn them into one or more bundles, which are simply static assets.

Bundler starts with scanning your modules, in order to create something called dependency-graph . This way Webpack will know, which modules and libraries are needed for the entry-point for your application.

Core concepts

Entry - module, where Webpack starts building dependency-graph, in React apps it is often index.ts/js file which imports bootstrap file
Output - location where Webpack should place the final bundle
Loaders - allow Webpack to process files with extensions other than JavaScript and JSON (JSX transformations, CSS, Fonts loaders, Babel transformations)
Plugins - plugins will handle the additional performance optimizations, environment variables, Module Federation etc.
Mode - tells Webpack, if you are in dev mode or production, where bundler apply all of its environment based optimizations

Why Webpack ?

You might be wondering why to use Webpack nowadays, especially with many new bundlers emerging ? There are multiple advantages to still use Webpack:

Webpack huge ecosystem of loaders and plugins, battle-proven with big community
Highly customizable with great documentation
Framework agnostic - in this guide we use React - but bundler is completely separated from the any framework
Advanced code-splitting and lazy loading with Webpack Magic comments (https://webpack.js.org/api/module-methods/#magic-comments) fetch priorities (https://webpack.js.org/api/module-methods/#webpackfetchpriority) and many more advanced features
Module Federation - this topic is very advanced and dedicated rather for big projects - to learn more please refer to this fantastic article: https://scriptedalchemy.medium.com/understanding-webpack-module-federation-a-deep-dive-efe5c55bf366

Setting up npm

Now we need put the concepts into minimal webpack setup. We assume that repository with initialized npm setup is there. The goal for this section is to:

ensure devs working on this project will have Node v20 LTS
install needed npm packages
add basic TypeScript setup
create Webpack setup function
create build script
prepare environment variables config

Unified Node version

We always want to use Node 20 in this repository. To enforce this, create a new file named .nvmrcRun the following command to enforce the use of exact package versions within the project.

echo "v20" > .nvmrc

Whenever someone using NVM navigate to this project, it will automatically switch to Node 20.

Sometimes it may not work automatically, so it is a good practice to always use nvm use before you run npm install command.

Additional setup for npm

Run this command to enforce exact versions of packages that will be installed inside of the project.

echo engine-strict = true > .npmrc
echo save-prefix="" >> .npmrc

Additionally it is good practice to add engines to package.json to make our lives easier on CICD and deployments

"engines": {
  "node": "20"
 },

Install dependencies

To use Webpack, it is necessary to install it as a dependency in our project, along with some helper packages needed for TypeScript.

npm i -D webpack webpack-cli typescript ts-node @types/node @types/webpack

Base tsconfig.json

I strongly recommend fantastic TypeScript resources available on: https://www.totaltypescript.com

For this boilerplate, the bundler setup will do the job. Create a tsconfig.json file with the following content (Reference: TypeScript Configurations Cheat Sheet):

{
    "compilerOptions": {
        /* Base Options: */
        "esModuleInterop": true,
        "skipLibCheck": true,
        "target": "es2022",
        "allowJs": true,
        "resolveJsonModule": true,
        "moduleDetection": "force",
        "isolatedModules": true,
        /* Strictness */
        "strict": true,
        "noUncheckedIndexedAccess": true,
        "outDir": "dist",
        "sourceMap": true,
        "composite": true,
        "declarationMap": true,
        /* If NOT transpiling with TypeScript: */
        "moduleResolution": "Bundler",
        "module": "ESNext",
        "noEmit": true,
        /* If your code runs in the DOM: */
        "lib": ["es2022", "dom", "dom.iterable"],
    }
}

Add minimal Webpack build configuration

Next, create a configuration file for Webpack - webpack.config.ts - in the root of the project:

import path from "path";
import type { Configuration } from "webpack";

const createWebpackConfig = (mode: Configuration["mode"]): Configuration => {
  return {
    mode: mode,
    entry: path.resolve(process.cwd(), "src/index.js"),
        resolve: {
            extensions: ['.js'],
        },
        output: {
            path: path.resolve(process.cwd(), "dist"),
            clean: true,
        },
    };
};

export default createWebpackConfig;

We take advantage of having function as configuration over object to be able to customize our scripts later on.

mode for production will be set always to production - this allow Webpack to make its optimizations for production build
entry points to entry file index.js
output is set to the dist folder, we also pass clean property, to remove old dist folder whenever you are creating new build

Example entry file and build command

For now, we can stick with a basic index.js file to simply test the build command.

//src/index.js

export const printHelloWorld = () => {
  return "hello world";
};

console.log(printHelloWorld());

Last but not least the build command and dedicated script:

// scripts/build.ts

import createWebpackConfig from "../webpack.config";

export default () => {
  return createWebpackConfig("production");
};

Build command in package.json

"scripts": {
  "build": "webpack --config scripts/build.ts"
}

Now by running npm run build new folder dist should be created with following file in it:

//dist/main.
(()=>{"use strict";console.log("hello world")})();

That concludes this part. You can review all the details in following PR: https://github.com/Verthon/webpack-react-boilerplate/pull/1/files

We now have a minimal setup, which we will extend with useful React-based features in the next article. In upcoming part we will focus on:

setting up modern Babel configuration
adding React
creating dev-server configuration
extending Webpack plugins

Thank you, any feedback is highly appreciated.

Code Coverage - more than just a number

Krzysztof Sordyl — Sat, 04 Mar 2023 15:00:57 +0000

Code coverage

Code coverage is a set of tools, that examine the percentages of code covered by the tests.
I’m working with Jest on daily basis, in this article I will use examples from this test framework.

To run coverage report, you can use following command:

  jest --coverage

You can see the results right away in your terminal or open nicer GUI with coverage in src/coverage/lcov-report/index.html

The metrics

lines - simply how much of you code is taking part in the tests
statements - same as above but it counts only instructions
functions - how many functions were called during test
branches - all branches of if/else, switches, conditional flows

Lets look at silly example:

// Test case

describe('isErrorRoute - helper to determine if url from input is recognized as error route in routing', () => {
  it('should', () => {
    expect(isErrorRoute('https://example.com/error')).toEqual(true);
    expect(isErrorRoute('https://example.com/error/not-found')).toEqual(true);
  });
});

// Implementation

export const isErrorRoute = (url?: string) => {
  if (!url) {
    // 1. branch not covered
    // 2. both 'statements' in line 4 and 5 also not covered
    console.log('statement');
    return false;
  }

  return url.includes('/error');
};

And the test with following metrics

lines - 60% (3/5)
statements - 66.66% (4/6)
functions - 100% (1/1)
branches - 0% (0/1)

What information code coverage gives us ?

what parts of application are not covered with tests at all
acts as a general guide for further analysis, where there might a be a real need of adding tests

What information code coverage won’t give you ?

how much behaviour is covered
it tell you nothing about overall tests quality
covering code with tests ≠= covering functionality with tests

The code coverage requirements

Most of the times there is requirement of having 80% code coverage in order to add new functionality to the codebase.

While I can understand the purpose of it, there is a huge chance, that some developers may focus solely on meeting the 80% threshold, without considering the real purpose of testing.

Common gotchas to spot on for “80% threshold focused” devs:

Over-reliance on mocks and stubs
No assertions in the tests
Writing many very similar tests
Ignoring code paths that are difficult to test (which may be a crucial parts for functionality)
Testing implementation details rather than behavior

Headless UI Libraries: The Key to Flexible and Accessible User Interfaces

Krzysztof Sordyl — Sun, 18 Dec 2022 13:33:41 +0000

What are headless components ?

In general the building UI is a very custom experience based on the brand you are building. Every company has different needs. So how to achieve that ?

There are a lot of already advanced, already styled, production ready libraries out there like MUI, Mantine, Chakra, Antd etc. These libraries allow you to deliver features extremely quickly at the beginning of the project and have large and supporting community.

The headless components gives you the small building blocks for creating UI, it comes with the freedom of styling, while maintaining the accessibility, functionality and all cross browser quirks for you.

Headless components are the unstyled versions of the regular components like Select or Dropdown, that:

are fully tested on different browsers and platforms
supports keyboard navigation
supports the entire focus management for you
supports screen readers and are fully accessible
supports all that edge cases that you don't want to deal with

Example of headless component from radix-ui docs

import React from 'react';
import * as ToggleGroup from '@radix-ui/react-toggle-group';
import { TextAlignLeftIcon, TextAlignCenterIcon, TextAlignRightIcon } from '@radix-ui/react-icons';
import './styles.css';

const ToggleGroupDemo = () => (
  <ToggleGroup.Root
    className="ToggleGroup"
    type="single"
    defaultValue="center"
    aria-label="Text alignment"
  >
    <ToggleGroup.Item className="ToggleGroupItem" value="left" aria-label="Left aligned">
      <TextAlignLeftIcon />
    </ToggleGroup.Item>
    <ToggleGroup.Item className="ToggleGroupItem" value="center" aria-label="Center aligned">
      <TextAlignCenterIcon />
    </ToggleGroup.Item>
    <ToggleGroup.Item className="ToggleGroupItem" value="right" aria-label="Right aligned">
      <TextAlignRightIcon />
    </ToggleGroup.Item>
  </ToggleGroup.Root>
);

export default ToggleGroupDemo;

Now imagine how much time you will have to spent in order to support all of those features 😅 If you are still thinking “I can surely can do that on my own” - please take a look at Pedro Duarte talk So You Think You Can Build A Dropdown? (Next.js Conf 2021)

Example of headless UI libraries:

Radix-UI - low-level UI component library with a focus on accessibility, customization and developer experience that can be adopted incrementally since every component is a diffrent npm package
Headless UI - works great with TailwindCSS but has 10 components, however it supports both Vue and React
Reakit - comes with hooks and components built with composition in mind
Reach UI - created by React Router team
React Aria - created by Adobe - library of hooks that provides primitives for your custom styling

Why to even think about it ?

As mentioned briefly above the headless components comes with a lot features, which make your life easier while building custom UI.

The main reasons, that you should consider going headless for your project:

unstyled - gives you freedom how you would like to style your components (css in js, tailwind, css-modules etc.) Additionally you are not being force to follow specific library design scheme
bundle size - is not bloated with libraries code (styling, hooks, helpers, theming etc.), they are doing great job with tree shaking, but still it is bigger than headless
consistency - similar like in the regular UI libs the api of components is consistent, so your team mates won’t spot the difference in daily basis work and maintenance
incremental adoption - libraries like radix-ui serves components as standalone package which help greatly with migrating existing library step by step
typescript support - most of libraries that will mention in this article are written in TypeScript it means that DX will be great, and package will be most likely self documenting
can improve the UI layer - you can nicely decouple the ui from logic in your components
redesigns won’t be scary - since you have full control of theming and styling, it is more future-proof and easier to maintain

When to choose a headless option ?

The headless approach works best when you are building the components library for your organization or for your client.

Additionally it will be perfect case when you are build a project which has own design system, that is different than systems that popular UI libraries are using.

Given that I think most of the project should at least consider using mentioned headless libraries.

Personally in the projects that I’m working on we initially choose the mui - but right now, since we have custom design system, we are gradually removing the mui and adding the radix-ui components.

Are “traditional” UI Library obsolete then ?

Definitely not, they are still maintained and they are fantastic tools for:

Proof of Concept like projects, when time to market is crucial
Very unlikely to happen - but your design system is based on the same, that UI library uses
Projects with tight deadlines or very low budget
Personal projects

Drawbacks of headless UI

they often require more setup on the developer side
the community is not that big as traditional UI libraries
you most likely won’t find every component, that you are familiar with from mui system for example
may not be as widely used - most of FE devs are familiar with mui for instance, the headless ones are going to mainstream, but they are still unfortunately not widely adopted

Summary

In my opinion the headless component libraries will continue to gain popularity over time as more developers seek out ways to create user interfaces that are accessible, customizable, and performant.

As headless component libraries continue to evolve and improve, they may become an increasingly attractive option for developers looking to create user interfaces that meet the specific needs of their projects. It's possible that traditional component libraries will also continue to adapt and offer more customization options, such as unstyled versions of their libraries, in response to the growing popularity of headless libraries.

It's worth noting that some traditional component libraries, like Material-UI (https://mui.com/base/getting-started/overview/) and Mantine (https://mantine.dev/changelog/5-0-0/#unstyled-components), are also now offering unstyled versions of their libraries, which can allow for more customization and control over the design of your application.

This can be a good option if you want to use a traditional library but still have some of the design flexibility provided by a headless library.

Frontend test smells

Krzysztof Sordyl — Sun, 30 Oct 2022 09:10:31 +0000

Introduction

This article aims to help you find common problems in frontend testing.

Our frontend applications grows very fast, along with the addition of (more and more thoughtful 😉) features, which should be tested automatically.

I strongly encourage you to critique and also review the additional materials at the end of this article, that formed the basis for this list of "test smell's"

List of the most common problems in testing, that I have noticed in projects and libraries that I maintain in my regular job:

Test smells

Using the `fireEvent` for user interactions

If you using a React Testing Library in your tests I would suggest to switch for userEvent.

UserEvent is way better at simulating the user behaviour, fireEvent just dispatches the DOM event, when the userEvent simulates full interactions - similarly like it is in real browser.

Lack of using setup for `userEvent`

It is recommended to invoke setup method before the actual component render in test.

The UserEvent authors encourage to invoke setup always before the render. Personally I'm sticking with helper createWrapper function. It helps with managing all our providers in once place.

export const createTestWrapper = 
({ children }: React.PropsWithChildren<unknown>) => {
  return {
    user: userEvent.setup(),
    ...render(<SomeProvider>{children}</SomeProvider>),
  }
}

Lack of using await for the `user events`

Simply always await any user interaction

const { user } = 
createTestWrapper({ children: <Checkbox /> })
const checkbox = screen.getByRole('checkbox')

user.click(checkbox) 🛑

await user.click(checkbox) ✅

expect(screen.getByRole('checkbox')).toBeChecked()

The only expection from it is .type according to the docs:

"To be clear, userEvent.type always returns a promise, but you only need to await the promise it returns if you're using the delay option. Otherwise everything runs synchronously and you can ignore the promise".

Huge test cases

On the whole it is quite logical, it is definitely better to break up into several smaller cases - than to test everything in one.

There is absolutely no point in artificially limiting the number of cases.

Too many assertions in one test case

It will be problematic to find what exactly failed, while you have a lot of assertions that checks totally different things.

Some people like to have only 1 assertion per test. I think it might be problematic, since checking one behavior might need more than just one assertion. As long as you testing one thing - you should be fine.

Here it can be helpful to use these techniques:

given => when => then
prepare => act => assert

Lack of any assertions or assertion which are useless

Think of it as something like expect(true).toBe(true) or expect(MightyComponent).toBeDefined() 😉

Lack of strongly typed response mocks

In case you are using msw.
I think it is best to aim to be 100% up to date in terms of api responses structure.
By typing it all, the TypeScript compiler makes sure that these mocks are always up to date as to type.

// fixture for msw handlers
export const regionsDictionary: RegionsDictionaryResponse = [
  {
    id: 1,
    name_en: 'Bavaria',
    name_ar: 'بافاريا',
  },
  {
    id: 2,
    name_en: 'Saxony',
    name_ar: 'ساكسونيا',
  },
  {
    id: 3,
    name_en: 'Hesse',
    name_ar: 'هيس',
  },
];

Badly described test cases

I see it always in codebases: should render a component or method should return true

I found that, it is best to show our descriptions to someone else and give that person very short time to read it and then ask what this test is actually checking ?
If it is not obvious, then most likely our descriptions are misleading.

It is crucial to think, up front - what exactly I need to test. What user interaction should I check, the more our description is for humans not 🤖 the better test is.

Tests that sometimes passes, sometimes not

If it happens to your unit tests, then most likely it will be caused by some side effects. I often see the problems with time / dates.
If there is not time for such a debugging I would suggest to just delete those problematic tests

Logic in your tests

Even "simple" if statements. It is hard to determine if your logic in test failed or something is wrong with the thing that you are testing.

When someone claims, that if/else logic in test can be removed for some reason, I would try to check if it can be split into two or more test cases.

It is hard to write any tests

This usually indicates a complicated code, functions that do everything ? React Context that oversees the entire state ?

tests duplication

Sometimes it is enough to write only integration test to check user interaction and not necessarily additionally unit-test a component / function that has already been tested in the integration test

very high coverage (90% +)

Most often points to implementation testing, or worse, jacking up coverage at all costs, and no longer necessarily focusing on quality and behavioral coverage.

Very slow tests

Especially the typical unit ones, we want developers to get in the habit of running tests often.
If they are slow, no one will let them go - happily there is always CICD at the end, but it is rather poor consolation when we want to popularize testing.

mocking everything

Such a test does not work much, in addition, having in our projects setup msw - mocking axios is in my opinion an average idea - when we have fantastic tools like msw to deal with your api calls easily

tests initially are always pass ✅

It is quite important to check whether for bad data or for reversal of the studied behavior - the test will correctly fail.
Then we are sure that we do not fall into the so-called false positive.
Here I refer to the article by Vlad Khorikov

Tests don't act as living documentation

Good tests should be easy for the person reading them.
You can always check it by folding all test cases in your IDE and reading its description only, if it gives you a brief idea what behavior is being tested then everything is fine.
Below I cite some of the most important features developed by Gerard Meszaros

The guiding principle, of course, is to write tests for people not robots, a good test:

describes the context, starting point or preconditions that must be met

illustrates how the code is called

variables or names in the test are trivial for the recipient to understand

describes exactly the expected result or the secondary conditions it verifies

Lack of any test

The biggest red flag that I can think of 🛑 . It is best to start by testing the simplest utils or even (it might be controversial) write empty test cases with detailed business descriptions of the functionality.
When the time is right, someone can help with writing such tests, or you can learn it yourself.

DEV Community: Krzysztof Sordyl

Part 4: Migration to RsBuild

Alternative

Why Rsbuild?

Vite

Establishing comparison metrics

Environment controls

Webpack results

Rsbuild results

Summary

Trade-offs

Part 3: Asset Handling, Unit Testing, and Bundle Analysis

Unit testing setup

Asset handling

CSS setup

Bundle size observability

How I migrated from CRA to RSBuild

Why RSBuild ?

Few words about RSBuild

CSS

Environment Variables

Testing

Results

Other migration cases

Part 2: Integrating Babel and React

Babel setup

Environment variables

React

Part 1: Setting Up the Basics

What is Webpack

Core concepts

Why Webpack ?

Setting up npm

Unified Node version

Additional setup for npm

Install dependencies

Base tsconfig.json

Add minimal Webpack build configuration

Example entry file and build command

Code Coverage - more than just a number

Code coverage

What information code coverage gives us ?

What information code coverage won’t give you ?

The code coverage requirements

Headless UI Libraries: The Key to Flexible and Accessible User Interfaces

What are headless components ?

Why to even think about it ?

When to choose a headless option ?

Are “traditional” UI Library obsolete then ?

Drawbacks of headless UI

Summary

Frontend test smells

Introduction

Test smells

Using the fireEvent for user interactions

Lack of using setup for userEvent

Lack of using await for the user events

Huge test cases

Too many assertions in one test case

Lack of any assertions or assertion which are useless

Lack of strongly typed response mocks

Badly described test cases

Tests that sometimes passes, sometimes not

Logic in your tests

It is hard to write any tests

tests duplication

very high coverage (90% +)

Very slow tests

mocking everything

tests initially are always pass ✅

Tests don't act as living documentation

Lack of any test

Material that helped me a lot preparing this article:

Using the `fireEvent` for user interactions

Lack of using setup for `userEvent`

Lack of using await for the `user events`