WXT vs. Plasmo. Some thoughts on migrating from Plasmo to WXT.

[aiktb]

TL;DR

This is the conclusion I got after spending a day migrating my extension from Plasmo to WXT:

Plasmo takes extension development out of the primitive world, and WXT really brings it into the modern world!

Something better than plasmo in WXT.

Effective HMR

Plasmo's HMR is not "React-only", in fact in the extensions I've written using React, HMR only works when the page is very small, 99%+ of the time I don't experience any HMR at all.

But WXT's HMR is very effective, and that's the strongest point I think WXT has over Plasmo.

Based on Vite

No Parcel.

Anyone familiar with plasmo will have encountered a bunch of Parcel bugs upstream, yet I can't do anything but sidestep them with some ugly code, and I haven't encountered any weird Vite bugs tripping me up in my time with WXT!

Vite's documentation is much better than Parcel, and I know how to do something with Vite, but Parcel I don't.

Vite is one of the most popular tools out there and many people are willing to invest in it, but Parcel's usage is not.

This is probably Plasmo's biggest mistake.

Better maintenance of the status quo

I haven't seen any major DX improvements in Plasmo in almost a year, just bug fixes.

I can trust WXT, right?

Expose UI framework mount process

Just using vue as an example, plasmo completely hides the app.mount process, the problem is that many libraries rely on app.use(...) , hiding this makes it impossible for developers to use these libraries smoothly, especially component libraries.

WXT will add some boilerplate code by exposing this process, but I think it's worth it compared to the flexibility it brings.

Hooks and Assets

Plasmo doesn't make any hooks public, nor does it have a public directory, and can't even do the simple function of adding a few files to the build product, whereas that flexibility should be necessary.

Manifest Override

Plamso doesn't support plasmo.config.ts, manifest.json overrides can only be written in package.json, and wxt.config.ts lets me utilize TypeScript to prevent spelling errors and more:

const commands = {
  key1: "content1",
  key2: "content2",
};

export type Command = keyof typeof commands;

I'll be able to utilize Command type in background/index.ts.

Something WXT is missing.

Some details Plasmo did better.

1. Only one assets/icon.png of 512*512 size is needed, plasmo will automatically generate images of other sizes.
2. Icons in development mode are automatically converted to grayscale, making it very easy to identify which extension came from development mode.
3. Prefer contents/*.ts to *.content.ts directory structure.

[aiktb]

Incidentally, really like the fact that WXT formats the manifest.json file in development mode, and when I use plasmo I often do this manually with json_pp < ./build/chrome-mv3-dev/manifest.json to do this.

[aklinker1]

Thanks for the feedback! I haven't used plasmo for an extended period of time, so it's good to hear positive feedback from someone who has used it for longer.

I could add sharp to generate smaller icons and make them greyscale in development. Not sure if I want to include that dependency directly, so maybe in a WXT module? With tools like Figma, it's really easy to generate assets of multiple dimensions nowadays. But the greyscale thing is a good idea.

[aiktb]

Thanks for the feedback! I haven't used plasmo for an extended period of time, so it's good to hear positive feedback from someone who has used it for longer.

I could add sharp to generate smaller icons and make them greyscale in development. Not sure if I want to include that dependency directly, so maybe in a WXT module? With tools like Figma, it's really easy to generate assets of multiple dimensions nowadays. But the greyscale thing is a good idea.

WxtModule accomplishes this easily. Thanks.

modules/icon.ts:

import fs from "node:fs";
import path from "node:path";
import sharp from "sharp";

import { defineWxtModule } from "wxt/modules";

export default defineWxtModule((wxt) => {
  wxt.hooks.hook("build:done", () => {
    const sizes = [16, 32, 48, 128];
    const destDir = path.resolve(wxt.config.outDir, "icons");
    fs.mkdirSync(destDir);
    const logo = sharp(path.resolve(__dirname, "../assets/icons/Logo.svg"));
    for (const size of sizes) {
      const destFile = path.resolve(destDir, `${size}.png`);
      const png = logo.resize(size, size).png();
      if (wxt.config.mode === "development") {
        png.grayscale().toFile(destFile);
      } else {
        png.toFile(destFile);
      }
    }
  });
});

wxt.config.ts:

export default defineConfig({
  manifest: {
    icons: {
      "16": "icons/16.png",
      "32": "icons/32.png",
      "48": "icons/48.png",
      "128": "icons/128.png",
    },
  }
});

[aklinker1]

Great example of how to write a module!

[Timeraa]

Made a module for it: #851

[vanarok]

WXT is the best tool I've found for developing browser extensions. Previously, I had to set up EVERYTHING manually, from hot reloading to building the extension. When I decided to write my own extension, I came across WXT, and from start to finish, I had NO issues during development. Special thanks for the detailed documentation.

[stevebeauge]

Moving from plasmo to wxt has the benefits of decreasing my bundled extension (I mean the zip file) from 5MB to 500KB. I guess the tree shaking is effective here, and wasn't using plasmo

[GorvGoyl]

We also migrated our browser extension from Plasmo to WXT and wrote about our migration process, including the challenges we faced and how we resolved them. Here's the article for anyone looking to migrate as well: https://chatgptwriter.ai/blog/migrate-plasmo-to-wxt