Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/guide/api-environment-runtimes.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,7 +80,7 @@ A Vite dev server exposes two environments by default: a `client` environment an

The transformed source code is called a module, and the relationships between the modules processed in each environment are kept in a module graph. The transformed code for these modules is sent to the runtimes associated with each environment to be executed. When a module is evaluated in the runtime, its imported modules will be requested triggering the processing of a section of the module graph.

A Vite Module Runner allows running any code by processing it with Vite plugins first. It is different from `server.ssrLoadModule` because the runner implementation is decoupled from the server. This allows library and framework authors to implement their layer of communication between the Vite server and the runner. The browser communicates with its corresponding environment using the server Web Socket and through HTTP requests. The Node Module runner can directly do function calls to process modules as it is running in the same process. Other environments could run modules connecting to a JS runtime like workerd, or a Worker Thread as Vitest does.
A Vite Module Runner allows running any code by processing it with Vite plugins first. It is different from `server.ssrLoadModule` because the runner implementation is decoupled from the server. This allows library and framework authors to implement their layer of communication between the Vite server and the runner. The browser communicates with its corresponding environment using the server WebSocket and through HTTP requests. The Node Module runner can directly do function calls to process modules as it is running in the same process. Other environments could run modules connecting to a JS runtime like workerd, or a Worker Thread as Vitest does.

One of the goals of this feature is to provide a customizable API to process and run code. Users can create new environment factories using the exposed primitives.

Expand Down
2 changes: 1 addition & 1 deletion docs/guide/api-javascript.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ interface ViteDevServer {
*/
watcher: FSWatcher
/**
* Web socket server with `send(payload)` method.
* WebSocket server with `send(payload)` method.
*/
ws: WebSocketServer
/**
Expand Down
2 changes: 1 addition & 1 deletion docs/guide/api-plugin.md
Original file line number Diff line number Diff line change
Expand Up @@ -286,7 +286,7 @@ Vite plugins can also provide hooks that serve Vite-specific purposes. These hoo

**Storing Server Access**

In some cases, other plugin hooks may need access to the dev server instance (e.g. accessing the web socket server, the file system watcher, or the module graph). This hook can also be used to store the server instance for access in other hooks:
In some cases, other plugin hooks may need access to the dev server instance (e.g. accessing the WebSocket server, the file system watcher, or the module graph). This hook can also be used to store the server instance for access in other hooks:

```js
const myPlugin = () => {
Expand Down
2 changes: 1 addition & 1 deletion packages/vite/src/node/server/index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -275,7 +275,7 @@ export interface ViteDevServer {
*/
watcher: FSWatcher
/**
* web socket server with `send(payload)` method
* WebSocket server with `send(payload)` method
*/
ws: WebSocketServer
/**
Expand Down