The Plugin System: Hook Execution, Ordering, and Core Plugins

Vite's plugin system is what makes it extensible enough to support React, Vue, Svelte, and hundreds of community integrations through a single interface. It extends Rolldown's plugin API with Vite-specific hooks, implements a dual-tier sorting system for precise ordering, and includes an optimization layer that skips hooks early when filters don't match.

In this article, we'll examine the plugin interface, understand how Vite assembles 28+ plugins in the right order, explore the filter cache that avoids unnecessary hook invocations, and look inside the most important core plugins.

The Plugin Interface and Vite-Specific Hooks

Vite's Plugin interface extends Rolldown's RolldownPlugin with hooks that don't exist in bundler contexts:

Hook	When it runs	Purpose
config	Before resolution	Modify user config
configResolved	After resolution	Read final config, store references
configEnvironment	Per environment	Modify environment-specific options
configureServer	Server creation	Add middlewares, access server instance
configurePreviewServer	Preview server creation	Same but for preview
hotUpdate	File change in dev	Customize HMR behavior
buildApp	Build orchestration	Control multi-environment build order
transformIndexHtml	HTML processing	Inject scripts, modify HTML

The TypeScript integration is notable. Vite uses declaration merging on lines 86–89 to extend Rolldown's types:

declare module 'rolldown' {
  export interface MinimalPluginContext extends PluginContextExtension {}
  export interface PluginContextMeta extends PluginContextMetaExtension {}
}

This means every Rolldown plugin context automatically gets this.environment — the current Environment instance. Plugin authors can access this.environment.config, this.environment.mode, and other environment-specific data without any casting.

There are also two distinct categories of plugins documented in the code: app plugins and environment plugins. Environment plugins are created via a constructor function called once per environment, and they can't define app-level hooks like config or configureServer.

Plugin Sorting: enforce and order

Vite uses a dual-tier sorting system. The first tier splits user plugins into three groups via the enforce field: 'pre', normal (no enforce), and 'post'. The second tier sorts individual hooks within those groups via the order field on each hook.

The resolvePlugins function assembles the final pipeline:

flowchart LR
    subgraph "Pre Zone"
        A1["optimizedDepsPlugin"]
        A2["watchPackageDataPlugin"]
        A3["preAliasPlugin"]
        A4["aliasPlugin (native or JS)"]
        A5["...user pre plugins"]
    end
    subgraph "Normal Zone"
        B1["modulePreloadPolyfillPlugin"]
        B2["oxcResolvePlugin (2 instances)"]
        B3["htmlInlineProxyPlugin"]
        B4["cssPlugin"]
        B5["oxcPlugin"]
        B6["nativeJsonPlugin"]
        B7["wasmHelperPlugin / webWorkerPlugin"]
        B8["assetPlugin"]
        B9["...user normal plugins"]
    end
    subgraph "Post Zone"
        C1["nativeWasmFallbackPlugin"]
        C2["definePlugin"]
        C3["cssPostPlugin"]
        C4["buildHtmlPlugin"]
        C5["...build plugins"]
        C6["...user post plugins"]
        C7["clientInjectionsPlugin"]
        C8["cssAnalysisPlugin"]
        C9["importAnalysisPlugin"]
    end
    A5 --> B1
    B9 --> C1

The getSortedPluginsByHook function implements the second tier. For each hook invocation, plugins are re-sorted by their hook's order property. The implementation is optimized — it uses index tracking to insert directly into the result array rather than creating three temporary arrays:

let pre = 0, normal = 0, post = 0
for (const plugin of plugins) {
  const hook = plugin[hookName]
  if (hook) {
    if (typeof hook === 'object') {
      if (hook.order === 'pre') {
        sortedPlugins.splice(pre++, 0, plugin)
        continue
      }
      if (hook.order === 'post') {
        sortedPlugins.splice(pre + normal + post++, 0, plugin)
        continue
      }
    }
    sortedPlugins.splice(pre + normal++, 0, plugin)
  }
}

Tip: Three dev-only plugins are always placed last: clientInjectionsPlugin, cssAnalysisPlugin, and importAnalysisPlugin. These must run after all other transforms because they analyze the final output to rewrite imports and inject the HMR client.

The Filter Optimization System

Vite includes a filter system that lets plugins declare which files their hooks care about, so the plugin container can skip invocations entirely for non-matching files. This is implemented in pluginFilter.ts.

The getCachedFilterForPlugin function extracts filter declarations from plugin hooks and caches them in a WeakMap:

flowchart TD
    HOOK["Plugin hook with filter"] --> EXTRACT["extractFilter(hook)"]
    EXTRACT --> CHECK{"Hook type?"}
    CHECK -->|resolveId| IDFilter["createIdFilter(rawFilter)"]
    CHECK -->|load| IDFilter
    CHECK -->|transform| TFilter["createFilterForTransform(id, code, moduleType)"]
    IDFilter --> CACHE["WeakMap<Plugin, FilterValue>"]
    TFilter --> CACHE
    CACHE --> USE["Plugin container checks filter before calling hook"]

For the transform hook, the filter can check both the module ID and the code content. This is particularly useful for plugins that only need to process code containing specific patterns (e.g., a plugin that transforms JSX only needs to run when the code contains JSX syntax).

The patternToIdFilter function supports both RegExp and glob patterns, using picomatch for glob matching. All paths are normalized to forward slashes before matching.

Native vs. JS Plugin Strategy

A key design decision in Vite 8 is the use of native Rolldown plugins where possible. Looking at resolvePlugins, we can see the pattern:

import {
  viteAliasPlugin as nativeAliasPlugin,
  viteJsonPlugin as nativeJsonPlugin,
  viteWasmFallbackPlugin as nativeWasmFallbackPlugin,
  oxcRuntimePlugin,
} from 'rolldown/experimental'

The alias plugin choice on lines 60–73 demonstrates the fallback strategy:

isBundled && !config.resolve.alias.some((v) => v.customResolver)
  ? nativeAliasPlugin({ entries: config.resolve.alias.map(/*...*/) })
  : aliasPlugin({ entries: config.resolve.alias, customResolver: viteAliasCustomResolver })

The native Rust plugin is used during build when there are no custom resolvers, falling back to the JS @rollup/plugin-alias otherwise. This gives maximum performance in the common case while preserving flexibility.

Core Plugin Deep Dives

The Resolve Plugin

oxcResolvePlugin wraps Rolldown's native viteResolvePlugin with Vite-specific logic. It returns an array of plugins — optionally including optimizerResolvePlugin for dev mode — and creates the native resolver per environment via perEnvironmentOrWorkerPlugin.

The resolver handles Vite's special URL prefixes (/@fs/, /@id/), browser field mapping, conditional exports, optional peer deps, and integration with the dependency optimizer. The finalizeBareSpecifier callback is what redirects bare imports like import React from 'react' to pre-bundled dependencies.

The Import Analysis Plugin

importAnalysisPlugin is a dev-only plugin that rewrites every import statement in your modules. It uses es-module-lexer to parse imports without a full AST, then uses MagicString to rewrite them. Bare imports become optimized dep URLs, relative imports get timestamp queries for cache busting, and the HMR API (import.meta.hot) is detected and processed.

The CSS Plugin

At 3500+ lines, cssPlugin is the largest core plugin. It handles:

• CSS preprocessors (Sass, Less, Stylus) via optional peer dependencies
• PostCSS processing with config auto-detection
• CSS Modules with scoped class names
• Lightning CSS as an alternative engine
• Source map handling across all transform stages
• Dev mode injection (inline <style> tags) vs. build mode extraction

The plugin is split into three parts: cssPlugin (pre-processing), cssPostPlugin (post-processing and extraction), and cssAnalysisPlugin (dev-only import tracking).

What's Coming Next

We've seen how plugins are sorted, filtered, and assembled into a pipeline of 28+ components. In the next article, we'll follow what happens when a file changes: the HMR system traces through the module graph to find update boundaries, sends payloads to the browser, and the client re-imports updated modules. We'll also explore dependency pre-bundling — how Rolldown scans your imports, bundles node_modules, and serves them from a cache.