I think it's very unrealistic for WXT to fully benchmark NUXT

[lvzhenbo]

First of all, although everyone's understanding of Nuxt is not consistent, but one thing is very sure, that is, Nuxt is a front-end meta-framework with multiple features based on Vue language. And WXT is just a multi-language browser development framework based on the Vite packaging tool. This huge difference leads to some problems:

1. Auto import problem. Auto import is to be divided into two parts , one is the API and the other is the UI components , for the multilingual tools API can be solved , but the UI components will be a bit of a headache . For UI component frameworks I want both API and UI components to be auto-imported, so I would go for a combination like unplugin-auto-import and unplugin-vue-components. You can't ask someone to adapt it separately, so why not use a more mature and convenient solution in the Vite ecosystem and adapt it for plugins like unplugin-auto-import.
2. modularization? I don't really understand the recent changes, why modularize on top of the language modularity that Vite already has, you're just extracting the configurations, it's very, very redundant. What about if I want to use vue-jsx, what do I do, I still have to add it myself, the module for vue just includes @vitejs/plugin-vue.

So, there are some things about Nuxt that WXT can learn, such as convention-based file structures, but the two are not the same type of tool. Often it's not good to develop blindly, you have to figure out what's easy to develop and what's not. I'm very optimistic about WXT, but after trying it out I've decided to stick with CRXJS for now, even though CRXJS hasn't been updated in a while.

[aklinker1]

By the way, if you have time could you reply to my discussion posting
#765 (reply in thread)

I read it, didn't seem like there was anything to respond to? You didn't really ask any questions, just shared your opinion, and I didn't feel the need to try and change your mind

[lvzhenbo]

Ok, I didn't make myself clear. I wanted to ask why you want to complicate a lot of things, such as currently only being able to auto-import wxt-api instead of using the auto-import plugin that already exists in the vite ecosystem, as well as modularizing again on top of the modularity that already exists in vite. T
his is my current configuration, and when I see the recent version changes I'm already at a loss and I don't know how to follow up on your thoughts:

import { defineConfig } from 'wxt';
import vue from '@vitejs/plugin-vue';
import vueJsx from '@vitejs/plugin-vue-jsx';
import { visualizer } from 'rollup-plugin-visualizer';
import AutoImport from 'unplugin-auto-import/vite';
import Components from 'unplugin-vue-components/vite';
import { NaiveUiResolver } from 'unplugin-vue-components/resolvers';

// See https://wxt.dev/api/config.html
export default defineConfig({
  manifest: {
    name: 'localStorage 管理器',
    description: '用于添加、删除、修改localStorage和sessionStorage的简单插件',
  },
  imports: {
    addons: {
      vueTemplate: true,
    },
  },
  vite: () => ({
    plugins: [
      vue(),
      vueJsx(),
      AutoImport({
        imports: [
          'vue',
          {
            'naive-ui': ['useDialog', 'useMessage', 'useNotification', 'useLoadingBar'],
          },
        ],
        eslintrc: {
          enabled: true,
        },
      }),
      Components({
        resolvers: [NaiveUiResolver()],
        dirs: ['components/'],
      }),
      visualizer(),
    ],
    build: {
      chunkSizeWarningLimit: 1024,
    },
  }),
});

[aklinker1]

Here's what your config should look like.

import { defineConfig } from 'wxt';
import vueJsx from '@vitejs/plugin-vue-jsx';
import Components from 'unplugin-vue-components/vite';
import { NaiveUiResolver } from 'unplugin-vue-components/resolvers';

// See https://wxt.dev/api/config.html
export default defineConfig({
  // Add vue module to apply defaults
  modules: ["@wxt-dev/module-vue"],
  
  manifest: {
    name: 'localStorage 管理器',
    description: '用于添加、删除、修改localStorage和sessionStorage的简单插件',
  },
  
  // Your unimport config goes here:
  imports: {
    addons: {
      vueTemplate: true,
    },
    eslintrc: true,
    imports: [
      { 'native-ui': ['useDialog', 'useMessage', 'useNotification', 'useLoadingBar'] },
    ],
  },
  
  analytics: {
    // Always generate stats.html, same as passing --analyze flag
    enabled: true,
  },
  
  vite: () => ({
    plugins: [
      // These aren't included in the vue module, so you can keep adding them here
      vueJsx(),
      Components({
        resolvers: [NaiveUiResolver()],
        dirs: ['components/'],
      })
    ],
    build: {
      chunkSizeWarningLimit: 1024,
    },
  }),
});

You just don't need to include any of the config the vue module adds for you.

https://github.com/wxt-dev/wxt/blob/main/packages/module-vue/src/index.ts

Just keep adding things that aren't included in the module.

---

I wanted to ask why you want to complicate a lot of things, such as currently only being able to auto-import wxt-api instead of using the auto-import plugin that already exists in the vite ecosystem, as well as modularizing again on top of the modularity that already exists in vite

1. Why not use unplugin-auto-import?

   Because WXT orchestrates multiple vite builds. That means to keep things fast, WXT needs to run some operations only once, like generating the auto-import declartation files for your editor or copying the public directory. Internally, WXT and Nuxt and unplugin-auto-import all use the unimport.

   You might be thinking "ok, but those operations don't seem very large, they should be done pretty quickly?" Correct, except dev mode adds a layer that complicates all this. plugins are both loaded into a dev server and production builds, where they're executed multiple times and when some files are changed. Rather than COMPLICATING all the vite plugins I use to modify the build process to opt out of some of these operations in EVERY plugin, WXT pulls that logic out of vite so it can simplify things and do it itself.

   The other thing to consider is what happens when Vite gets killed and the next new bundler comes out? I don't want core features of my framework to depend on any one bundler. Yes, the unplugin ecosystem might support it, but there's no guarentee of that. I have to hedge my bets, and I've chosen not to fully depend on vite when possible.

2. What's up with WXT's modules?

   It may look like the module system is a simple wrapper around vite because the only module's I've released thus far are for front-end frameworks, but that's not true. Modules are able to modify WXT's build orchestration, not just the vite config used during one build step.

   If you want a better idea of what modules can do, follow the new devtools PR, where were using a module to inject code into all entrypoints and report logs back to a single "devtools" UI automatically bundled in the extension. Yes, adding vite config is important to this process, but it's not something vite alone can do.

   https://discord.com/channels/1212416027611365476/1224507127863967784/1245039995123667026

   Another contributor is working on it in a fork, so the progress isn't visible, but I think the idea and base implementation from the PR is enough to prove that modules aren't just a useless abstraction around vite plugins.

   Another reason to break front-end framework support out into modules is so I can add features to them independent of WXT itself. That means yes, I could introduce unplugin-vue-components into the vue module to add support for auto-importing components, which I plan on doing (feel free to open a PR adding this if you'd like!). Same with JSX, though, most vue project's don't use JSX, so we'd probably include it as an optional peer dependency.

Overall, yes, there are definitely things that can be simplified. But not the things you mentioned.

[lvzhenbo]

Ok, thanks for the detailed explanation, I've got an idea of where the framework is going, but then again this way then I'll need a migration document (it took me half an hour to migrate from CRXJS to WXT). I'll keep an eye on this ambitious project.