Forem: Wojciech Maj

Why using Bun in production (maybe) isn't the best idea

Wojciech Maj — Sun, 14 Sep 2025 22:24:15 +0000

Bun deserves credit. It's fast, ambitious, and it shook a JavaScript ecosystem that had once been stagnating. The pace of exciting innovations sped up significantly after Bun showed what an integrated experience could feel like. Node.js, once conservative to a fault, suddenly delivered: native TypeScript support, fetch in core, built-in watch mode, an official test runner, .env support. Bun lit the fire, and the whole ecosystem got warmer.

That's a win for everyone. But production is where optimism meets entropy.

“Be everything” or “be sustainable”?

When Bun 1.0 launched, the pitch wasn't just “another runtime”. It aimed to replace Node itself and a half-dozen tools around it: npx, dotenv, cross-env, nodemon, pm2, ws, node-fetch/isomorphic-fetch, tsc, Babel, ts-node, tsx. At the time, that all-in-one story felt like the future we were longing for.

Two years later, many of those headline features landed in Node. The parts Node didn't absorb (bundling, package management, etc.) are arguably better left in userland, where specialization and rapid iteration thrive (think: Rolldown or LightningCSS). Not everything should be integrated into one runtime, because, respectfully, no single team can possibly excel at everything at once.

Performance: yeah, it's fast, but…

Bun's launch aura was speed. While their obsession for performance still stands and continues to push the industry forward, some of the charts they advertised Bun with were questionable from the start - like comparing against Yarn v1 when Yarn v3 was already available. Worse yet, the same charts are still featured prominently two years later.

Other headline numbers often lack context. Take “Bun is 5× faster than Vitest”. Sounds impressive, until you note that Vitest and Jest deliberately add overhead for test isolation, making tests way more deterministic and debuggable. It's part of the reason why Jest even earned its crown back in the Mocha days.

Ignoring those trade-offs is misleading. At best, it's incomplete. At worst, dishonest.

Since then, the rest of the JS ecosystem didn't stand still. Node, npm, pnpm, Vitest, and others, all continued to improve. On top of that, community initiatives (e.g., e18e) are driving performance wins across the entire ecosystem, not just Bun.

Portability & lock-in: easy to start, hard to stop

Bun ships non-standard APIs that may feel great on day one - but quietly tether you to Bun itself. It's tempting to bun init, bun test, and lean on helpers like Bun.file, Bun.serve, and Bun.YAML.stringify. Migrating away later if something goes south? Good luck.

// Detect dark theme var iframe = document.getElementById('tweet-2029685779413487776-473'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2029685779413487776&theme=dark" }

Probably not what they had in mind

Consider the long-standing “Support Vitest” request. It was opened before Bun 1.0 and remains open today. If you want to have a go with Bun seriously, you're effectively pushed into using Bun's own test runner. That seems convenient, until you want to move back to Node or another runtime and face an tedious migration.

Versioning & stability: version numbers are a contract

After announcing 1.0, Bun shipped dozens of 1.0.x releases that included new features - not just bug fixes - attempting to keep 1.1 for the elephant in the room - Windows support.

That simply isn't how semantic versioning works; it's closer to the internet-famous “pride versioning” joke:

PROUD.DEFAULT.SHAME
PROUD for changes you're proud of, DEFAULT for routine releases, SHAME for fixes you hope nobody notices.

If patch releases include new features, what stops them from releasing a minor release from shipping breaking changes? We don't need to wonder, because that's EXACTLY what happened already!
For example, Bun 1.1 changed the default NODE_ENV value, changed the way conditional exports are resolved, and 1.1.26 changed idleTimeout in node:http.

For production teams, version numbers are a contract. They signal when it's safe to upgrade and when to brace for impact. If those signals can't be trusted, upgrades become roulette.

Contrast with Node: today, Node ships fast on current releases, so you can try new features quickly. But there's also the battle-tested, super-stable LTS line (that still receives some of the cool stuff from time to time!), and that dual model is critical. You can experiment at the edge, but when you need reliability, the LTS cadence gives you exactly that. That balance is what makes Node production-ready.

Questionable design choices

JSONC in package.json: comments are handy, but making package.json not JSON breaks compatibility with every other tool. That's fragmentation, not progress.
Binary lockfile: Bun originally shipped a binary lockfile that made PR reviews opaque - a dream scenario for anyone trying to sneak malicious code through. It later switched to text, but the format remains far less readable than Yarn's or pnpm's one. Hard-to-audit lockfiles weaken security culture.
Lifecycle scripts: Bun doesn't run them by default (which partially explains its “faster installs” - less work is being done). Skipping scripts by default is a fantastic idea that greatly improves ecosystem safety, and for this reason other package managers quickly adopted it as well. The problem lies in the details: Bun maintains an arbitrary allowlist of “popular packages” whose scripts do run. If you're listed, your postinstall executes - great for you (or… for someone who compromised your npm account). If you're not, Bun users will need to run extra steps to make your package work. That's a perfect mix of no actual security and no actual convenience.

YOLO-driven roadmap & disregard for neighbors

Bun often feels like it ships whatever won last week's Twitter poll.

The speed Bun ships these features with can be intoxicating, but it also leads to overreach: a made-up tsconfig.json flag, jsxSideEffects, was added in Bun 1.2.22. Think about it: this flag was dropped into TypeScript's namespace by a project other than TypeScript itself. If the TS team ever wanted to actually add that flag, confusion and breaking changes are inevitable.

This also reminds me of the LightningCSS controversy where instead of collaborating with the existing Rust project, whose author even provided C bindings and offered support, Bun ported it to Zig and keeps a separate copy (did I mention something about userland and sustainability? I thought so…).

// Detect dark theme var iframe = document.getElementById('tweet-1822020304753062281-495'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1822020304753062281&theme=dark" }

Ouch. That's not how open source works. Whatever the license permits, ethics and ecosystem trust matter.

It paints a picture of a project more interested in going its own way than building alongside the wider community, and that's not the kind of foundation I would advise to rest production systems on.

Maintenance signals: issue trackers don't lie

As of today, Node - the runtime powering practically the entire planet, including your toothbrush, probably - carries about 1.7k open issues. Bun, much younger and - while popular - considerably far less adopted, has around 4.7k. Raw numbers are never telling us the full story, but the imbalance is striking. Node shoulders a global workload and yet manages a far leaner backlog. Bun, still in its infancy, is already swamped. That doesn't exactly inspire confidence for production workloads.

When would I use Bun?

This isn't “never use Bun.” It's “use it wisely.”

Good fits:

Prototypes and playgrounds where the integrated DX speeds you up.
Single-purpose CLIs or scripts where portability isn't critical.
Projects in which performance matters more than anything else.

Guardrails if you adopt it:

Stick to standards; isolate Bun specifics.
Prefer portable tooling.
Pin versions, read changelogs carefully, and test upgrades like you would a database migration.

What Bun could do to earn a production seat

Treat semver as a contract; features in minors, breakages in majors.
Establish a clear LTS and release schedule so teams know what's safe to adopt.
Make benchmarks honest: compare like with like, explain trade-offs.
Prefer collaboration over duplication: contribute upstream, coordinate publicly.
Ship new features with a thoughtful, ecosystem-aware process.

Bottom line

Production depends on sustainability, predictability, and trust. Right now, Bun's design choices, versioning, and marketing weaken those foundations. If these matter to you, think twice before building on Bun today.

But don't get me wrong: Bun made the ecosystem better simply by existing. It reminded everyone what great DX can feel like, and it jolted Node into shipping long-awaited features. And it continues to do so! I'm genuinely thankful for that.

Make your app install and run faster with nolyfill

Wojciech Maj — Wed, 25 Oct 2023 20:10:39 +0000

Do you use eslint-plugin-import, eslint-plugin-jsx-a11y, eslint-plugin-react? Of course you do! What do they have in common? They all contain tons of polyfills to ensure backward compatibility. "With what?", you ask? With Node.js 4. NODE DOT JS VERSION FOUR. Released in 2015. "So?"

These polyfills are totally useless. Unless, of course, you run Node.js 4. They:

impact install times,
make your node_modules bigger,
and make your app run slower (native implementations are rarely slower than their polyfills).

So what can you do?

One way to deal with it is by forking such packages, stripping off useless dependencies, and re-releasing them under new names. This, however, is rarely worth it.

`eslint-plugin-i`

eslint-plugin-i, a fork of eslint-plugin-import, is a good example of when it IS worth it. Not only they do the above, but also replace tsconfig-paths and heavy typescript under the hood with get-tsconfig. This resolves security issues eslint-plugin-import has, vastly improves performance, and adds support for new TypeScript features. I highly recommend you replacing eslint-plugin-import with eslint-plugin-i, and if I'm not convincing enough, perhaps pure madness exhibited by eslint-plugin-import's lead maintainer in this issue will convince you to.

But usually, there's an easier way!

`nolyfill`

SukkaW created an amazing project called nolyfill. nolyfill is leveraging npm's, yarn's and pnpm's capabilities to replace heavy polyfills with so-called "nolyfills".

Nolyfills are tiny wrappers around what Node.js already offers. You must check it out!

https://github.com/SukkaW/nolyfill

Run npx nolyfill on your repo, and see for yourself, how many redundant dependencies you have!

`@yarnpkg/plugin-nolyfill`

On top of SukkaW's work, I've built another thing: @yarnpkg/plugin-nolyfill.It does the same thing nolyfill's CLI does, but hooks directly into Yarn resolution step, replacing the polyfills in question on the fly. It has the added benefit of "install and forget" - plugin will work every time you install your repository, so it guarantees no new redundant polyfills will ever appear in your repository.

If you use Yarn (2+), check it out as well!

Install it by running yarn plugin import https://raw.githubusercontent.com/wojtekmaj/yarn-plugin-nolyfill/v0.1.2/bundles/@yarnpkg/plugin-nolyfill.js. Then, reinstall repository by running yarn install.

Package manager wars. The real picture

Wojciech Maj — Sat, 21 Oct 2023 22:37:03 +0000

"pnpm has surpassed Yarn!" I've read on Twitter the other day. "In what exactly?" - I thought to myself. The answer to this question turned out to be: "In npm downloads". However, this doesn't mean anything at all!

In this article, we'll explore why it's a horrible way of comparing different package managers popularity, and we'll find out the real answer to the question: "Which package managers are the most popular?".

Why npm downloads can't be counted?

The most obvious problem with counting npm downloads is that npm ships with Node.js. This means that, in theory, everyone can use npm in Node.js project with no additional downloads. You don't download npm from npm to obtain it, only to update it.

Why Yarn downloads can't be counted?

First, I need you to know that Yarn Classic (v1) and Yarn Modern (also known as Yarn Berry; v2+) are completely different things.

Let's look at Yarn Classic first.

Yarn Classic was indeed shipped as an npm package called yarn. The recommended way of installing it was by running npm install -g yarn. However, it is not the only way of downloading Yarn Classic. Among many others you could use brew, config of which unveils that, unsurprisingly, it downloads Yarn binary from yarnpkg.com rather than npm.

For Yarn Modern, things got complicated.

Before Corepack (I'll cover it later) became a thing, Yarn 2 installation was weeeird. To install Yarn 2, you had to install Yarn 1 first. Then, in every repository, you had to run yarn set version berry, which installed Yarn 2 in this repository, specifically in .yarn/releases. While doing so, you could see the console output:



Resolving berry to a url...
Downloading https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js...
Saving it into /private/tmp/my-app/.yarn/releases/yarn-berry.js...
Updating /private/tmp/my-app/.yarnrc...
Done!

So, again, not npm. In fact, you cannot download Modern Yarn from npm at all!

Corepack

Nowadays, the recommended way of installing Yarn is through Corepack, a tool shipped (although not enabled - yet) by default with Node.js.

Slight off-topic: I highly recommend you to familiarize yourself with Corepack, regardless of your package manager of choice. Once enabled, it transparently downloads a binary for a package manager a given project requires, as specified in packageManager in package.json. You don't need to install Yarn or pnpm manually at all!

Back to the topic. Where does Corepack downloads Yarn from? Corepack's config makes it clear: it's yarnpkg.com, so again, not npm.

Why pnpm downloads can't be counted?

pnpm's 1st (and thus preferred) installation method installation instructions is "Using standalone script". Looking at script source, we quickly learn it downloads its binaries from GitHub. So… not npm.

Unlike Yarn, pnpm can actually be downloaded from npm. Corepack takes advantage of that, and uses npm under the hood to download pnpm binaries.

What do we know so far?

npm is underreported on npm downloads stats. You don't need to download it to use it.
Yarn Classic is underreported. You can download it from other sources.
Yarn Modern is not reported at all. You can't download it from npm.
pnpm is underreported. You can download it from other sources.
And perhaps the most importantly, more npm downloads != more popularity. It just means… There is more downloads. If package manager A is updated weekly, and package manager B is updated once per year, A will get more downloads than B, even if B is technically more popular.

So what can we measure?

Here's my plan.

Get as many most starred GitHub JavaScript and TypeScript repositories as I can.
Figure out package manager each repo is using.
- Check if packageManager is present in package.json. If present, count as whatever is specified.
- Check for package-lock.json or npm-shrinkwrap.json. If present, count as npm.
- Check for yarn.lock, and…
- Check for .yarnrc.yml. If present, count as Yarn Modern.
- If not, count as Yarn Classic.
- Check for pnpm-lock.yaml. If present, count as pnpm.
- Check for bun.lockb. If present, count as Bun.
- If all else fails, check documentation for commands that would hint on package manager used.

And so, the script was born.

Without further ado, here are the results:

Package manager	Total
npm	978 (53%)
Yarn Classic	471 (26%)
Yarn Modern	75 (4%)
pnpm	105 (6%)
Bun	4 (0%)
unknown	203 (11%)

Stat	Total
Projects examined	2040
Projects with `package.json`	1836
Projects using Corepack	179
Projects not using Corepack, but with a lockfile	1657

So there you have it. The real picture of package manager wars.

pnpm does, indeed, appear to have surpassed Yarn Modern (v2 and v3). But it is nowhere near to Yarn Classic's (v1) popularity, which, in turn, is not nearly as popular as npm.

npm is the absolute king with whopping 53% of the "market". In reality, it's likely even more than that. 11% of the projects examined did not have lockfile committed. My suspicion is that the vast majority of maintainers of these projects are in fact using npm, as there is no (machine-readable) indication that something other than the "default" is being used.

Final words

If you'd like to see how the script was done, or would like to improve it, please visit:

https://github.com/wojtekmaj/package-manager-stats

Migrating your React app from Webpack to Vite

Wojciech Maj — Thu, 07 Apr 2022 22:47:13 +0000

What is Vite?

Vite is a "next generation front-end tooling", as its maintainers claim. Instant dev server, fast Hot Module Reload, easy configuration, optimized production builds - it's all there.

But… Vite's documentation doesn't say how to migrate your existing Webpack app 🤷 Worry not! In this guide, we'll get through this together!

Change your repo to ES modules

In your package.json, add the following entry:



  "type": "module",

Embrace modernity! Reject tradition! That's why we're switching to Vite anyway!

Install Vite and its plugins



npm i --save-dev vite @vitejs/plugin-react vite-plugin-simple-html



yarn add vite @vitejs/plugin-react vite-plugin-simple-html --dev

Replace scripts

In your package.json, you'll probably have scripts similar to these:



  "build": "NODE_ENV=production webpack",
  "dev": "NODE_ENV=development webpack serve",

build command, invoked by npm run build or yarn build, builds your app for production. dev command starts a development server.

These scripts needs to be replaced with:



  "build": "vite build",
  "dev": "vite serve",

On top of that, you can add one extra command:



  "preview": "vite preview"

preview command will start a server running your app built for production.

Let's run the development server!



  vite v2.9.1 dev server running at:

  > Local: http://localhost:3000/
  > Network: use --host to expose

  ready in 261ms.

👁👄👁 Wow, that is fast.

Teach Vite where the root is

If you started the development server now, Vite will look for index.html in your project's root directory. If it's anywhere else, Vite will not be able to find it and will display an empty page instead.

To fix this, you need to either move index.html to your root directory, or specify a different root directory for Vite to look for index.html in. In my case, it's located at src/index.html.

You can do this by adding root directory path to your commands, like this:



  "build": "vite build src",
  "dev": "vite serve src",

However, you can also do this by creating a vite.config.js file in your project root. You will need it in a short while anyway, so why not create one now to keep all the configuration in one place?



import { defineConfig } from 'vite';

export default defineConfig({
  root: 'src',
  build: {
    // Relative to the root
    outDir: '../dist',
  },
});

Configure `vite-plugin-simple-html`

Now that Vite knows where to find your index.html file, it will try and parse it.

You may encounter an error like me:

How to deal with it? I was using HtmlWebpackPlugin's templateParameters option to dynamically inject custom title and other info into index.html file, like so:



  <title><%= title %></title>



new HtmlWebpackPlugin({
  template: 'index.html',
  templateParameters: {
    title: env === 'production' ? 'My site' : `My site [${env.toUpperCase()}]`,
  },
}),

Thankfully, we can do the same with vite-plugin-simple-html. In your vite.config.js, add the following bits:



import simpleHtmlPlugin from 'vite-plugin-simple-html';

export default defineConfig({
  // …
  plugins: [
    simpleHtmlPlugin({
      inject: {
        data: {
          title: env === 'production' ? 'My site' : `My site [${env.toUpperCase()}]`,
        },
      },
    }),
  ],
});

Add entry module to your `index.html` file

At this point, your index.html file should be served just fine. But the app still won't load!

If you used Webpack, you probably have also used html-webpack-plugin to handle injecting <script> tag(s) with your entry module(s) to index.html.

Vite will not inject these tags automatically. You will need to add them by yourself. For example:



<script type="module" src="./index.jsx"></script>

Aaah, that's better. Something came to life.

Configure `@vitejs/plugin-react`

Okay, as you can see, we're not quite there yet. We need to configure @vitejs/plugin-react to make it work with React.

If you still used classic JSX runtime, your app may already load at this point, but you'll want to follow these steps anyway. This plugin will not only handle automatic JSX runtime (the one thanks to which you don't need to manually import React in every file), but also add features like Fast Refresh, enable Babel integration, and much, much more.

Add it to your vite.config.js file like so:



import react from '@vitejs/plugin-react';

export default defineConfig({
  // …
  plugins: [
    // …
    react({
      // Use React plugin in all *.jsx and *.tsx files
      include: '**/*.{jsx,tsx}',
    }),
  ],
});

Aliases

At this point, if you were using aliases (to write e.g. import Button from 'src/components/Button' instead of import Button from '../../../../../components/Button'), your build may fail. Easy fix!

Webpack:



  resolve: {
    alias: {
      src: path.resolve(__dirname, 'src'),
    },
  },

Vite:



  resolve: {
    alias: {
      src: path.resolve(__dirname, 'src'),
    }
  },

Wait a second, same thing? 🤔 Yes! Well, kinda. You have more options to choose from, but most of the time, your aliases should work when copied over.

Static files handling

By default, files from public directory placed in your root directory are going to be copied over at build time. If you have these files elsewhere, you can use publicDir option like so:



export default defineConfig({
  // …
  publicDir: '../public',
});

SVG handling

If you used to import SVG icons to use not as static files but rather as React components, @cassidoo just wrote an interesting article on that matter - be sure to check it out!

Babel plugins

You might not need Babel at all, as @babel/preset-env and @babel/preset-react are of no use.

But sometimes Babel plugins may still come in handy. For example, there's a plugin to remove PropTypes you can use to make bundle size a bit smaller, and there's a dedicated plugin for styled-components that makes development and testing easier by, among others, adding component display names.

@vitejs/plugin-react will come to the rescue here, with babel option. For example, to add babel-plugin-styled-components plugin:



    react({
      // …
      babel: {
        plugins: ['babel-plugin-styled-components'],
      },
    },

The `process.env.*` problem

I was using process.env.NODE_ENV in a bunch of places in my app. This resulted in the following error being thrown in the console:



Uncaught ReferenceError: process is not defined

In Vite, you can use import.meta.env.* instead. For example, process.env.NODE_ENV can be replaced with import.meta.env.NODE_ENV.

Enjoy!

Now you should see your app, powered by Vite!

We're not done yet; we'll still need to tweak a few things before running it in production. For this, you'll have to wait for the second part of this guide. Subscribe to get notified!

Cleaning up

You can safely remove these dependencies, which are now unused:

core-js (unless you've been using it directly)
webpack (duh)
webpack-cli
webpack-dev-server
*-loader (e.g. babel-loader, style-loader)
*-webpack-plugin (e.g. html-webpack-plugin, mini-css-extract-plugin
@babel/preset-env
@babel/preset-react
@pmmmwh/react-refresh-webpack-plugin
react-refresh

webpack.config.js Webpack config file can also be deleted.

babel.config.js, babel.config.json, or .babelrc can be deleted, provided that you didn't use it as your Babel config in @vitejs/plugin-react configuration.

Anything missing?

Do you think there's anything else that needs to be addressed, that may be a common problem when migrating from Webpack to Vite? Please, please let me know in the comments!

Enzyme is dead. Now what?

Wojciech Maj — Mon, 20 Dec 2021 10:59:30 +0000

I'm the maintainer of @wojtekmaj/enzyme-adapter-react-17. I'm here to warn you. Enzyme, a popular utility to test React components, is dead. It's time to move on. Here's why I think so.

For a long time, Enzyme has been the 1st choice when it comes to testing React applications, despite of how bumpy the road to Enzyme React 16 support was. Even today, 1/3 of React apps are still being tested using Enzyme!

How `@wojtekmaj/enzyme-adapter-react-17` came to life

Back in August 2020, React 17 Release Candidate came out. Shortly after, an issue has been raised in Enzyme repository to add support for React 17. Immediately after, @layershifter has opened a PR adding an official enzyme-adapter-react-17.

Unfortunately, there were (and, spoiler alert, still are) some issues with testing that prevented this PR from being merged.

Now, here's the thing. I'm the maintainer of many popular React packages, React-PDF, React-Calendar, and React-Date-Picker just to name a few. Professionally, I maintain several large projects, which collectively have more than 30,000 Enzyme-based unit tests.

I was in no position to wait for Enzyme to add support for React 17 to support React 17 in my packages. Rewriting all unit tests also looked like no fun to me. So, I've decided to act and publish a temporary adapter based on Oleksandr's work.

It wasn't only the adapter though: certain changes were also necessary in Enzyme adapter utils, which all Enzyme adapters depend on, so a fork of them was also needed. A couple of tireless evenings later, @wojtekmaj/enzyme-adapter-react-17 was born.

Fast-forward one year

The issue for adding React 17 support remains open and has become nothing but a source of bitter comments mixed with unproductive "any updates?". Oleksandr's PR remains unmerged. enzyme-adapter-react-17 is nowhere in sight. The unofficial adapter I published with an intention of being just a stepping stone before everyone eventually migrates to enzyme-adapter-react-17, has become de facto the default adapter for React 17, with 16 million downloads so far.

Retrospectively, I'm not sure if publishing the package was a good decision.

On one hand, this move has helped thousands of developers worldwide to upgrade to React 17, relatively hassle-free.

On the other, I helped prolonging Enzyme's inevitable death and thus gave many developers hope and a sense of safety they shouldn't get to feel. And I'm sorry for that.

React 18

Before I came to this conclusion though, React 18 beta was announced, and of course, I jumped to see if @wojtekmaj/enzyme-adapter-react-18 could be released.

The big thing in React 18 are concurrent features. To opt-in, after upgrading to React 18, you also need to switch to the new createRoot API:

// before
const container = document.getElementById('root');
ReactDOM.render(<App />, container);

// after
const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);
root.render(<App/>);

Until you switch to the new API, your app will behave as if it's running React 17. So if you don't plan to do this, there's no point of upgrading!

I quickly realized that the API changes in React 18 meant that releasing a React 18 Enzyme adapter will not be possible without a huge rework of not only the adapter itself, but also Enzyme, enzyme-adapter-utils and enzyme-adapter-react-helper.

Trust me, it's not gonna happen. It's over. No more "stepping stones". And certainly no more official adapters. Whether or not you plan to upgrade to React 18 in the near future, you should consider looking for Enzyme alternative right now.

What should I do? 😱

The answer is, as always, it depends. You don't have to upgrade React, after all.

Here's what I would do:

Start familiarizing yourself with React Testing Library, an officially recommended library for React components.
Make a rule to write new tests using RTL only.
Consider making a rule to rewrite tests to RTL whenever you need to touch them and/or the component they are testing.
In your designated time for repaying technical debt (you have designated time for repaying technical debt, right? …right?), rewrite your remaining Enzyme-based tests to RTL.
Clean up your repo from Enzyme-specific bits
When you're ready, upgrade to React 18.

A bit of personal advice

While Migrate from Enzyme support article is available, I suggest you to just start fresh, forgetting that Enzyme has ever existed. RTL is by no means an Enzyme drop-in replacement, so having a completely fresh mindset will help you getting the most of it.

Optimizing React apps: Hardcore edition

Wojciech Maj — Fri, 20 Aug 2021 15:30:52 +0000

You've heard of minifying. You've heard of lazy-loading. You've heard of tree shaking. You've done it all. Or did you? Here are some optimizations you may have never heard of before. Until now!

Enable "loose" transformations in `@babel/preset-env`

Enabling "loose" transformations may make your application considerably smaller. I shaved off roughly 230.9 KB, or 16.2% from my bundle!

This, however, comes at a price: your application may break, both when enabling, and disabling these transformations.

In my case, the only fix I needed to do was related to iterating over HTMLCollection (document.querySelectorAll(…), document.getElementsByTagName(…) and HTMLFormControlsCollection (form.elements). I was no longer able to do e.g. [...form.elements], I had to swap it out for Array.from(form.elements).

Still tempted by the large savings? Give it a go by enabling loose flag in Babel config:

babel.config.json

  "presets": [
-   "@babel/preset-env"
+   ["@babel/preset-env", {
+     "loose": true
+   }]
  ]

Remove prop-types from your production bundle

PropTypes are incredibly helpful during development, but they are of no use for your users. You can use babel-plugin-transform-react-remove-prop-types to remove PropTypes from your bundle.

To install, run:

npm install --save-dev babel-plugin-transform-react-remove-prop-types

yarn add -D babel-plugin-transform-react-remove-prop-types

and add it to your Babel config like so:

babel.config.json

  "env": {
    "production": {
      "plugins": [
+        "transform-react-remove-prop-types"
      ]
    }
  }

Savings will vary depending on the size of your app. In my case, I shaved off 16.5 KB or about 1.2% from my bundle.

Consider `unsafe-wrap` mode

unsafe-wrap mode is, as the name states, a bit unsafe for the reasons well explained in plugin's docs.

However, in my case, PropTypes were not accessed from anywhere and the application worked flawlessly.

To enable this mode, you need to change your Babel config like so:

babel.config.json

  "env": {
    "production": {
      "plugins": [
-       "transform-react-remove-prop-types"
+       ["transform-react-remove-prop-types", {
+         "mode": "unsafe-wrap"
+       }]
      ]
    }
  }

This way, I shaved off a total of 35.9 KB or about 2.5% from my bundle.

Enable new JSX transform

Enabling new JSX transform will change the way Babel React preset transpiles JSX to pure JavaScript.

I explained the benefits of enabling it in my other article: How to enable new JSX transform in React 17?.

I highly recommend you to have a read. If that's TL;DR though, all you need to do for quick results is make sure that @babel/core and @babel/preset-env in your project are both on version 7.9.0 or newer, and change your Babel config like so:

babel.config.json

  "presets": [
-   "@babel/preset-react"
+   ["@babel/preset-react", {
+     "runtime": "automatic"
+   }]
  ]

And poof! Roughly 10.5 KB, or 0.7% of my bundle was gone.

Minify your HTML

Chances are your bundler is smart enough to minify JavaScript by default when ran in production mode. But did you know you can minify HTML, too? And JavaScript in that HTML as well?

You're in? Great! Here's what you need to do:

Install html-minifier-terser:

npm install --save-dev html-minifier-terser

yarn add -D html-minifier-terser

and change your Webpack config to use it. Define minifier options:

webpack.config.js

const minifyOptions = {
  // Defaults used by HtmlWebpackPlugin
  collapseWhitespace: true,
  removeComments: true,
  removeRedundantAttributes: true,
  removeScriptTypeAttributes: true,
  removeStyleLinkTypeAttributes: true,
  useShortDoctype: true,
  // Custom
  minifyCSS: true,
  minifyJS: true,
};

and use them in HtmlWebpackPlugin…:

webpack.config.js

    new HtmlWebpackPlugin({
+     minify: minifyOptions,
      template: 'index.html',
    }),

…as well as in CopyWebpackPlugin:

webpack.config.js

const { minify } = require('html-minifier-terser');

webpack.config.js

  plugins: [
    new CopyWebpackPlugin({
      patterns: [
        {
          from: 'index.html',
          to: '',
+         transform(content) {
+           return minify(content.toString(), minifyOptions);
+         },
        },
      ]
    }),
  ],

Use `babel-plugin-styled-components` (`styled-components` users only)

If you use styled-components, make sure to use their Babel plugin, too. Not only it adds minification of styles, but also adds support for server-side rendering, and provides with a nicer debugging experience.

To install, run:

npm install --save-dev babel-plugin-styled-components

yarn add -D babel-plugin-styled-components

and add it to your Babel config like so:

babel.config.json

  "env": {
    "production": {
      "plugins": [
+        "styled-components"
      ]
    }
  }

This will shave off a few kilobytes on its own, but due to added displayNames the savings will not be so apparent just yet. So now…

Disable `displayName` in production builds

babel.config.json

  "env": {
    "production": {
      "plugins": [
+       ["styled-components", {
+         "displayName": false,
+       }]
      ]
    }
  }

Doing so in my app gave me a surprisingly large savings of 50.4 KB or 3.5%.

Wrap `createGlobalStyle` contents in `css` (`styled-components` users only)

Apparently, while babel-plugin-styled-components is capable of minifying styles, it doesn't minify anything within createGlobalStyle. So, chances are you're shipping your app with tons of unnecessary whitespace.

Remove them by simply wrapping createGlobalStyle contents in css as well, like so:

-const GlobalStyle = createGlobalStyle`
+const GlobalStyle = createGlobalStyle`${css`
   // Your global style goes here
-`;
+`}`;

Replace `react-lifecycles-compat` with an empty mock

react-lifecycles-compat is a dependency that polyfills lifecycle methods introduced in React 16.3 so that the components polyfilled would work with older React versions. Some dependencies may still use this polyfill in order not to break older React version support.

If you use React 16.3 or newer, you don't need react-lifecycles-compat. You can replace it with a mocked version like so:

__mocks__/reactLifecyclesCompatMock.js

module.exports = {
  polyfill: (Component) => Component,
};

webpack.config.js

  resolve: {
    alias: {
+     'react-lifecycles-compat': path.resolve(__dirname, '__mocks__', 'reactLifecyclesCompatMock.js'),
    },
  },

Doing so will save you 2.5 KB.

Replace `classnames` with `clsx`

classnames is not a large dependency, only 729 bytes, but clsx is fully compatible with classnames at just 516 bytes. So, replacing classnames with clsx in your app will save you 213 bytes.

Chances are you'll have both classnames and clsx in your app, e.g. because dependencies may require one or the other. In this case, you can use Webpack's alias to get rid of classnames from your bundle:

webpack.config.js

  resolve: {
    alias: {
+     classnames: 'clsx',
    },
  },

Doing so will save you 729 bytes.

Missing something?

Please share your ideas for not-so-obvious optimizations in the comments below!

How to enable new JSX transform in React?

Wojciech Maj — Tue, 11 Aug 2020 15:07:32 +0000

The biggest feature of React 17, as React team claims, is that there are no new features. This isn't however entirely true.

In Babel 7.9.0, a new JSX transform was announced. It could only be used in experimental React releases. Until now!

Before we dive into how to enable this feature, let's see the advantages:

No more `import React from 'react'`

Yes! You'll no longer need to import React to each. and. every. component. you write. Instead, it will be imported automatically!

Well, not quite. If you use hooks, lazy, Suspense or any other import, you will still need to import them all manually. But no more importing React if you're not using React explicitly in your code, e.g. by calling React.useState.

Smaller bundle

A side effect of this change is also a slightly smaller bundle. In my case, on a moderately sized commercial application with ~1500 components, the savings were around 10.5 KiB. It ain't much, but arguably a welcome improvement.

Where do the savings come from? Take a look at transpiled code, before & after the change we're about to make:

import React from "react";

function Foo() {
  return React.createElement("div");
}

import { jsx as _jsx } from "react/jsx-runtime";

function Foo() {
  return _jsx("div");
}

Turns out, this can add up!

Enough talking, let's do it!

Make sure you're all up to date

To continue, you're going to need:

Babel & @babel/preset-react 7.9.0 or later
React:
- 17: 17.0.0 or later,
- 16: 16.14.0 or later,
- 15: 15.7.0 or later,
- 0.14: 0.14.10 or later

For example, you can use

npm install @babel/core@^7.9.0 @babel/preset-react@^7.9.0 --dev
npm install react@^16.14.0 react-dom@^16.14.0

yarn add @babel/core@^7.9.0 @babel/preset-react@^7.9.0 --dev
yarn add react@^16.14.0 react-dom@^16.14.0

to update your React 16 app.

You can also jump straight to React 17. Note that React 17 contains some breaking changes when compared to React 16. Upgrade carefully!

Babel configuration

Your Babel configuration (.babelrc, .babelrc.json, or similar) needs a small change: In presets section, to

  "@babel/preset-react"

preset you'll now need to pass "runtime": "automatic" option. Change the above line to:

  ["@babel/preset-react", {
    "runtime": "automatic"
  }]

That's it! You're done! 🥳

Cleaning up

Alright, not quite. You're now left with redundant React imports. Cleaning them up is optional, because modern bundlers will ignore unused imports. If you still want to do the cleaning, continue reading.

If you used e.g. React.useState or <React.Fragment> (as opposed to useState or <>), the easiest approach would be to get rid of all React.* occurrences first.

Then, you'll be free to remove "pure" React imports by replacing (using RegEx):

import React from ['"]react['"];?\n

with an empty string, and replacing

import React,\s?(\{.*\})\s?from (['"]react['"])

with

import $1 from $2

which should leave only named imports in a vast majority of cases.

ESLint configuration

Changes are ESLint will complain about you no longer importing React in files where you're using JSX. If that's the case, all you need to do is simply turn off these rules:

  "react/jsx-uses-react": "off",
  "react/react-in-jsx-scope": "off",

Forem: Wojciech Maj

Why using Bun in production (maybe) isn't the best idea

“Be everything” or “be sustainable”?

Performance: yeah, it's fast, but…

Portability & lock-in: easy to start, hard to stop

Versioning & stability: version numbers are a contract

Questionable design choices

YOLO-driven roadmap & disregard for neighbors

Maintenance signals: issue trackers don't lie

When would I use Bun?

What Bun could do to earn a production seat

Bottom line

Make your app install and run faster with nolyfill

So what can you do?

eslint-plugin-i

nolyfill

@yarnpkg/plugin-nolyfill

Package manager wars. The real picture

Why npm downloads can't be counted?

Why Yarn downloads can't be counted?

Let's look at Yarn Classic first.

For Yarn Modern, things got complicated.

Corepack

Why pnpm downloads can't be counted?

What do we know so far?

So what can we measure?

And so, the script was born.

Final words

Migrating your React app from Webpack to Vite

What is Vite?

Change your repo to ES modules

Install Vite and its plugins

Replace scripts

Teach Vite where the root is

Configure vite-plugin-simple-html

Add entry module to your index.html file

Configure @vitejs/plugin-react

Aliases

Static files handling

SVG handling

Babel plugins

The process.env.* problem

Enjoy!

Cleaning up

Anything missing?

Enzyme is dead. Now what?

How @wojtekmaj/enzyme-adapter-react-17 came to life

Fast-forward one year

React 18

What should I do? 😱

A bit of personal advice

Optimizing React apps: Hardcore edition

Enable "loose" transformations in @babel/preset-env

Remove prop-types from your production bundle

Consider unsafe-wrap mode

Enable new JSX transform

Minify your HTML

Use babel-plugin-styled-components (styled-components users only)

Disable displayName in production builds

Wrap createGlobalStyle contents in css (styled-components users only)

Replace react-lifecycles-compat with an empty mock

Replace classnames with clsx

Missing something?

How to enable new JSX transform in React?

No more import React from 'react'

Smaller bundle

Enough talking, let's do it!

Make sure you're all up to date

Babel configuration

Cleaning up

ESLint configuration

Happy coding!

`eslint-plugin-i`

`nolyfill`

`@yarnpkg/plugin-nolyfill`

Configure `vite-plugin-simple-html`

Add entry module to your `index.html` file

Configure `@vitejs/plugin-react`

The `process.env.*` problem

How `@wojtekmaj/enzyme-adapter-react-17` came to life

Enable "loose" transformations in `@babel/preset-env`

Consider `unsafe-wrap` mode

Use `babel-plugin-styled-components` (`styled-components` users only)

Disable `displayName` in production builds

Wrap `createGlobalStyle` contents in `css` (`styled-components` users only)

Replace `react-lifecycles-compat` with an empty mock

Replace `classnames` with `clsx`

No more `import React from 'react'`