/
plugin.ts
154 lines (152 loc) · 5.54 KB
/
plugin.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
import type {
CustomPluginOptions,
LoadResult,
PluginContext,
ResolveIdResult,
Plugin as RollupPlugin,
TransformPluginContext,
TransformResult
} from 'rollup'
import type { UserConfig } from './config'
import type { ServerHook } from './server'
import type { IndexHtmlTransform } from './plugins/html'
import type { ModuleNode } from './server/moduleGraph'
import type { HmrContext } from './server/hmr'
import type { PreviewServerHook } from './preview'
import type { ConfigEnv, ResolvedConfig } from './'
/**
* Vite plugins extends the Rollup plugin interface with a few extra
* vite-specific options. A valid vite plugin is also a valid Rollup plugin.
* On the contrary, a Rollup plugin may or may NOT be a valid vite universal
* plugin, since some Rollup features do not make sense in an unbundled
* dev server context. That said, as long as a rollup plugin doesn't have strong
* coupling between its bundle phase and output phase hooks then it should
* just work (that means, most of them).
*
* By default, the plugins are run during both serve and build. When a plugin
* is applied during serve, it will only run **non output plugin hooks** (see
* rollup type definition of {@link rollup#PluginHooks}). You can think of the
* dev server as only running `const bundle = rollup.rollup()` but never calling
* `bundle.generate()`.
*
* A plugin that expects to have different behavior depending on serve/build can
* export a factory function that receives the command being run via options.
*
* If a plugin should be applied only for server or build, a function format
* config file can be used to conditional determine the plugins to use.
*/
export interface Plugin extends RollupPlugin {
/**
* Enforce plugin invocation tier similar to webpack loaders.
*
* Plugin invocation order:
* - alias resolution
* - `enforce: 'pre'` plugins
* - vite core plugins
* - normal plugins
* - vite build plugins
* - `enforce: 'post'` plugins
* - vite build post plugins
*/
enforce?: 'pre' | 'post'
/**
* Apply the plugin only for serve or build, or on certain conditions.
*/
apply?: 'serve' | 'build' | ((config: UserConfig, env: ConfigEnv) => boolean)
/**
* Modify vite config before it's resolved. The hook can either mutate the
* passed-in config directly, or return a partial config object that will be
* deeply merged into existing config.
*
* Note: User plugins are resolved before running this hook so injecting other
* plugins inside the `config` hook will have no effect.
*/
config?: (
config: UserConfig,
env: ConfigEnv
) => UserConfig | null | void | Promise<UserConfig | null | void>
/**
* Use this hook to read and store the final resolved vite config.
*/
configResolved?: (config: ResolvedConfig) => void | Promise<void>
/**
* Configure the vite server. The hook receives the {@link ViteDevServer}
* instance. This can also be used to store a reference to the server
* for use in other hooks.
*
* The hooks will be called before internal middlewares are applied. A hook
* can return a post hook that will be called after internal middlewares
* are applied. Hook can be async functions and will be called in series.
*/
configureServer?: ServerHook
/**
* Configure the preview server. The hook receives the connect server and
* its underlying http server.
*
* The hooks are called before other middlewares are applied. A hook can
* return a post hook that will be called after other middlewares are
* applied. Hooks can be async functions and will be called in series.
*/
configurePreviewServer?: PreviewServerHook
/**
* Transform index.html.
* The hook receives the following arguments:
*
* - html: string
* - ctx?: vite.ServerContext (only present during serve)
* - bundle?: rollup.OutputBundle (only present during build)
*
* It can either return a transformed string, or a list of html tag
* descriptors that will be injected into the <head> or <body>.
*
* By default the transform is applied **after** vite's internal html
* transform. If you need to apply the transform before vite, use an object:
* `{ enforce: 'pre', transform: hook }`
*/
transformIndexHtml?: IndexHtmlTransform
/**
* Perform custom handling of HMR updates.
* The handler receives a context containing changed filename, timestamp, a
* list of modules affected by the file change, and the dev server instance.
*
* - The hook can return a filtered list of modules to narrow down the update.
* e.g. for a Vue SFC, we can narrow down the part to update by comparing
* the descriptors.
*
* - The hook can also return an empty array and then perform custom updates
* by sending a custom hmr payload via server.ws.send().
*
* - If the hook doesn't return a value, the hmr update will be performed as
* normal.
*/
handleHotUpdate?(
ctx: HmrContext
): Array<ModuleNode> | void | Promise<Array<ModuleNode> | void>
/**
* extend hooks with ssr flag
*/
resolveId?(
this: PluginContext,
source: string,
importer: string | undefined,
options: {
custom?: CustomPluginOptions
ssr?: boolean
/**
* @internal
*/
scan?: boolean
}
): Promise<ResolveIdResult> | ResolveIdResult
load?(
this: PluginContext,
id: string,
options?: { ssr?: boolean }
): Promise<LoadResult> | LoadResult
transform?(
this: TransformPluginContext,
code: string,
id: string,
options?: { ssr?: boolean }
): Promise<TransformResult> | TransformResult
}