Plugin API, about ordering of plugins and Vite specific configs

[patak-dev]

enforce naming

@rollup/plugin-image is the only official rollup plugin where enforce: 'pre' is required. I wanted to send a PR to rollup/plugins so they include enforce in it but I think that it could be rejected because of naming. There could be issues if WMR decides to have a different ordering but the same config name.
Would it make sense to rename enforce to be more explicit, something like viteOrder?
I think that rollup plugin maintainers may be more willing to accept these compat enhancements if they know the hooks are not going to interfere later with other projects (or with a future API from rollup itself).

Vite plugin ordering

There are some Vite core plugins that I would consider optional features: jsonPlugin, wasmPlugin, webWorkerPlugin, assetPlugin. I think it is a good idea to have these features out of the box, but if a user would like to use a different wasm plugin, or as with @rollup/plugin-image, would like to import images in a different way than what Vite does out of the box, it would be good if they can just use the plugins without the need to use enforce: 'pre'. If they are including one of these plugins, their intent is clear.
Right now, the ordering is:

• Alias
• User plugins with enforce: 'pre'
• Vite core plugins
• User plugins without enforce value
• Vite build plugins
• User plugins with enforce: 'post'
• Vite post build plugins

I was thinking that the Vite core plugins could be broken into two buckets: Vite Core plugins (resolve, etc) and Vite Features plugins (json, wasm, webWorker, importing images as URL). The Vite Features plugins could then be applied after normal user plugins like:

• Alias
• User plugins with enforce: 'pre'
• Vite core plugins
• User plugins without enforce value
• Vite features plugins
• User plugins with enforce: 'after'
• Vite build plugins
• User plugins with enforce: 'post'
• Vite post build plugins

I think this could help reduce the need for explicitly enforcing the ordering in user plugins ( I do not know if after is really needed. Naming could also be pre, post, last ).

[ElMassimo]

Regarding rollup plugins, it definitely improves the user experience in Vite when they work out of the box.

Since Vite is not the only consumer, I agree that enforce might be too generic and create incompatibilities with other development tools. Using viteOrder like you proposed, or enforceInVite, as aliases might be a good way to play nice with the ecosystem, while ensuring a generic rollup plugin works out of the box in Vite.

---

About Vite's "feature" plugins, instead of modifying the order and introducing another value for enforce, perhaps we can allow a user to opt-out of any of these plugins by name.

Although it would require an additional configuration option, it opens up the possibility for some plugins to opt-out automatically by using the config option, so that the user doesn't have to do it manually.

[patak-dev]

About naming, I thought that enforce may not be the only option that we may end up prefixing. So we could end up with viteOrder, viteConfig, viteConfigureServer.

I like the idea of being able to disable feature plugins, that could even be proposed independently of this thread. For some users, that may be a good feature (and there are already some opt out config options in Vite). But it doesn't help to be able to use rollup plugins out of the box though, instead of having to use enforce: 'pre', users need to disable particular plugins. That may be even harder to get right for a lot of users.

Another idea would be to offer the Vite official feature plugins (webassembly, workers, import url, etc) as opt-in instead of opt-out, maybe with a preset to add them all together so it is easier for users to get the default setup. I think that Evan wanted to have all these common web dev patterns out of the box, so that may not be an option. So, I still think that having the internal Vite plugins separated into two groups is a good solution to keep the current "most common things out of the box" but let the users win against these extra features by just adding the plugin (no need to enforce order in most of the cases)

[ElMassimo]

Makes sense to use a prefix considering we might need other options in the future 👍

Having the "feature" plugins enabled by default is what makes Vite so easy to get started with, so opt-in doesn't seem reasonable.

Something that I'm not sure I understand, how would Vite detect if a user intends to use an alternative plugin for, say, "wasm"? Would that rely on a vite-prefixed property in the rollup plugin, such as viteSupports: ['wasm'], or is there a simpler strategy that I'm missing?

[patak-dev]

There is no need for extra config options. The only thing that I am proposing is that we change where users plugins are inserted by default. Right now, they are inserted after the core feature plugins. What I tried to explain in the first message is to insert them by default before wasmPlugin, webWorkerPlugin, etc. I do not know exactly where is the cut, but let's say that it is before jsonPlugin here https://github.com/vitejs/vite/blob/main/packages/vite/src/node/plugins/index.ts#L46.

Alias
User plugins with enforce: 'pre'
Vite core plugins ( dynamicImportPlugin, resolvePlugin, etc )
User plugins without enforce value ( userWasmPlugin rollup plugin without extra configs )
Vite features plugins ( jsonPlugin, webWorkerPlugin, wasmPlugin, etc )
User plugins with enforce: 'after'
Vite build plugins
User plugins with enforce: 'post'
Vite post build plugins

So, userWasmPlugin wins with against the internal wasmPlugin because it comes before.

[ElMassimo]

Gotcha, so you are talking about relying on the fact that the first transform wins?

Moving the "feature" plugins after the user plugins would work in this scenario, but it could override user options in others.

Is transform the only option that these "feature" plugins are currently using? If that's the case, then it's safe, and it seems like a nice improvement.

[patak-dev]

Yes, but not for transform because that one is "sequential", there you only get the user plugins before the internal ones.

There are other rollup hooks that are "first" hooks. For example resolveId and load, that are typical in loaders (json, yaml, images, etc). Having the user plugins before the internal feature plugins ensure that the user win no matter which "first" hooks they used

[antfu]

Although the ability to use rollup plugins out-of-box could be a nice feature, I don't think it's good to have Vite-specific options in rollup plugins. I personally think it's better to wrap rollup plugins and publish them as Vite plugins with some override configure like enforce etc if they can't be used directly. The same should apply to other ecosystems on top of rollup (e.g. wmr). Otherwise, even if we solve the naming conflicts, they would end up with something like viteEnforce: 'pre', wmrEnfore: 'pre', xxxEnfore: 'pre' in the rollup plugins, which I don't think it's an ideal solution.

[patak-dev]

Thanks for the feedback. I understand that it is not ideal, but I also think that having to maintain four packages just for adding this flag is also not the best for the ecosystem. People are going to start reporting issues to vite-plugin-some-loader, instead of doing it in the main plugin and it could generate quite a bit of churn. On the other hand, the rollup plugins may get some issues related to Vite, which would be better to be reported upstream. I think there isn't a clear answer regarding this, and we will have to see how the ecosystem evolves. IMO, for plugins I could maintain, I would prefer to add the config option instead of keeping track of two repositories, or having to create a monorepo just for this.

But I see your point. If we separate the internal vite plugins in two buckets as proposed, enforce wouldn't be actually needed in most cases (at least for loaders), so this may be a better way forward. What do you think of the second part of this proposal @antfu?

Something interesting is that having the internal "feature" vite plugins (json, wasm, worker, etc) go after user plugins is that it will be a lot easier to add new out of the box features to Vite later. If we want to add support for GLSL out of the box for example, and we follow the current approach, it is a breaking change because the plugin will win over user plugins. If we place the feature plugins after the user plugins by default, then it is not an issue, because the user plugin will continue to be the one that gets to load the resource first.

[antfu]

The second idea sounds good but I am not very confident about the change as it might break the existing ones. Would need to do some test out I think.

Other idea I came up with might be able to custom the built-in plugins, where we already have the top level configs for esbuild json css.

export default {
  json: false, // disable the built-in json plugin
  esbuild: false,
  // ...
}

[patak-dev]

@ElMassimo also proposed disabling the built-in plugins. I like the idea, and that could even be proposed independently of this thread. For some users, that may be a good feature (and there are already some opt out config options in Vite as you said).

But it doesn't help to be able to use rollup plugins out of the box though, instead of having to use enforce: 'pre' in the plugins, users need to disable particular plugins in the main config. I think that this may be even harder to get right for users.

[yyx990803]

Changing the ordering alone won't be enough because Rollup transform hooks are applied for all matching plugins. There is no way for a plugin to say "the transform stops here" (which is kind of a limitation that I'd like to see addressed in Rollup), so even if user plugins are applied before core feature plugins, the core feature plugins will still attempt to transform the result passed on from user plugins and likely cause an error.

Still, I think the best practice is to first check the features page of the docs to see "is this covered in Vite already?" before reaching for plugins.

P.S. we should probably add a dedicated section in the features page for the special queries (?worker, ?raw, ?url).

[patak-dev]

Changing the ordering alone won't be enough because Rollup transform hooks are applied for all matching plugins. There is no way for a plugin to say "the transform stops here" (which is kind of a limitation that I'd like to see addressed in Rollup), so even if user plugins are applied before core feature plugins, the core feature plugins will still attempt to transform the result passed on from user plugins and likely cause an error.

You are right. I was thinking about plugins like rollup-plugin-image ( implementation ), that only uses first hooks (like resolveId and load). But checking the implementation of several others, I see that most of them are implemented using transform. So my proposal doesn't work in the general case, it may help with only a few plugins.

The issue is that in the future, every time that a new plugin is added to the out-of-the-box ones, the release maybe needs to be marked as breaking because the new plugin may win over the users plugins. In most cases, if the feature is a common pattern, it will mean that the user just needs to remove the plugin that is no longer needed. But I do not have any solution that doesn't imply offering all these features as part of Vite but opt-in by including the plugins by hand (like we already do with legacy, vue, etc), and AFAIU, that is not an option.

Still, I think the best practice is to first check the features page of the docs to see "is this covered in Vite already?" before reaching for plugins.

Thanks for the message about ?raw today, will recommend that one next time 👍🏼

we should probably add a dedicated section in the features page for the special queries (?worker, ?raw, ?URL).

I'll see if I can draft a PR for it

P.S. Are Discussions the proper place for this kind of thread? Or would this be better as an issue?