Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: missing changes guides #18491

Merged
merged 3 commits into from
Oct 30, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
16 changes: 8 additions & 8 deletions docs/changes/per-environment-apis.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,16 +4,12 @@
Give us feedback at [Environment API feedback discussion](https://github.com/vitejs/vite/discussions/16358)
:::

Multiple APIs from ViteDevServer related to module graph has replaced with more isolated Environment APIs.

- `server.moduleGraph` -> [`environment.moduleGraph`](/guide/api-environment#separate-module-graphs)
- `server.transformRequest` -> `environment.transformRequest`
- `server.warmupRequest` -> `environment.warmupRequest`
Multiple APIs from `ViteDevServer` related to module graph and modules transforms have been moved to the `DevEnvironment` instances.

Affect scope: `Vite Plugin Authors`

::: warning Future Deprecation
The Environment instance was first introduced at `v6.0`. The deprecation of `server.moduleGraph` and other methods that are now in environments is planned for `v7.0`. We don't recommend moving away from server methods yet. To identify your usage, set these in your vite config.
The `Environment` instance was first introduced at `v6.0`. The deprecation of `server.moduleGraph` and other methods that are now in environments is planned for `v7.0`. We don't recommend moving away from server methods yet. To identify your usage, set these in your vite config.

```ts
future: {
Expand All @@ -26,8 +22,12 @@ future: {

## Motivation

// TODO:
In Vite v5 and before, a single Vite dev server always had two environments (`client` and `ssr`). The `server.moduleGraph` had mixed modules from both of these environments. Nodes were connected through `clientImportedModules` and `ssrImportedModules` lists (but a single `importers` list was maintained for each). A transformed module was represented by an `id` and a `ssr` boolean. This boolean needed to be passed to APIs, for example `server.moduleGraph.getModuleByUrl(url, ssr)` and `server.transformRequest(url, { ssr })`.

In Vite v6, it is now possible to create any number of custom environments (`client`, `ssr`, `edge`, etc). A single `ssr` boolean isn't enough anymore. Instead of changing the APIs to be of the form `server.transformRequest(url, { environment })`, we moved these methods to the environment instance allowing them to be called without a Vite dev server.

## Migration Guide

// TODO:
- `server.moduleGraph` -> [`environment.moduleGraph`](/guide/api-environment#separate-module-graphs)
- `server.transformRequest(url, ssr)` -> `environment.transformRequest(url)`
- `server.warmupRequest(url, ssr)` -> `environment.warmupRequest(url)`
65 changes: 62 additions & 3 deletions docs/changes/shared-plugins-during-build.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,6 @@
Give us feedback at [Environment API feedback discussion](https://github.com/vitejs/vite/discussions/16358)
:::

// TODO:
See [Shared plugins during build](/guide/api-environment.md#shared-plugins-during-build).

Affect scope: `Vite Plugin Authors`
Expand All @@ -15,8 +14,68 @@ Affect scope: `Vite Plugin Authors`

## Motivation

// TODO:
Align dev and build plugin pipelines.

## Migration Guide

// TODO:
To be able to share plugins across environments, plugin state must be keyed by the current environment. A plugin of the following form will count the number of transformed modules across all environments.

```js
function CountTransformedModulesPlugin() {
let transformedModules
return {
name: 'count-transformed-modules',
buildStart() {
transformedModules = 0
},
transform(id) {
transformedModules++
},
buildEnd() {
console.log(transformedModules)
},
}
}
```

If we instead want to count the number of transformed modules for each environment, we need to keep a map:

```js
function PerEnvironmentCountTransformedModulesPlugin() {
const state = new Map<Environment, { count: number }>()
return {
name: 'count-transformed-modules',
perEnvironmentBuildStartEnd: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does perEnvironmentBuildStartEnd still exist? The search result does not return any usage only the declarations: https://github.com/search?q=repo%3Avitejs%2Fvite+perEnvironmentBuildStartEnd&type=code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, it is actually called perEnvironmentStartEndDuringDev. We need a better name for this. Any recommendations?

About this option, the problem we have is that plugins my be expecting a single buildStart call during dev, even if there are multiple environments, so I don't think we can start calling it multiple times in Vite 6. A lot of times it will work though, because it will end up reseting multiple times the state, but it could fail too. Moving to multiple buildStart calls is something we haven't discuss much but I think it is a good idea to align dev and build

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that was it. I don't have any better naming 😅. But I guess we should rename perEnvironmentBuildStartEnd to perEnvironmentStartEndDuringDev and use the settings in the pluginContainer.

buildStart() {
state.set(this.environment, { count: 0 })
}
transform(id) {
state.get(this.environment).count++
},
buildEnd() {
console.log(this.environment.name, state.get(this.environment).count)
}
}
}
```

To simplify this pattern, internally in Vite, we use a `useEnvironmentState` helper:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is somewhat related to useEnvironmentState helper. It's not directly related to this PR, but putting it here for now. I had to create a different plugin instance per-environment when using native plugins with Vite + Rolldown.

The implementation was like:
https://github.com/rolldown/vite/blob/f633bd2ceeaf3d3f28d6c9940977343b12f89ac6/packages/vite/src/node/plugin.ts#L339-L380
https://github.com/rolldown/vite/blob/f633bd2ceeaf3d3f28d6c9940977343b12f89ac6/packages/vite/src/node/plugins/index.ts#L85-L97

I'm not sure if this would be needed commonly, but maybe something similar to this is needed when using some of the rollup plugins in npm.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed with Anthony about a similar helper when we were trying to see how to refactor the reporter plugin: https://github.com/vitejs/vite/pull/17292/files

The api.getBuiltinPlugin trick is interesting. I also think we're going to need a better story to make rollup plugins per environment. When we had the functional API for plugins it was very easy, just wrap it as () => rollupPlugin() and you're done. Same with the object based { environmentPlugins: () => rollupPlugin() }.
We ended up ditching the first one because of back compat, and the idea in general (the second was ok regarding compatibility) because we didn't want to push for the concept of two types of plugins:

  • Shared plugins (environment aware)
  • Per-environment plugin

The user now needs to know that a per-env plugin can't be in the main pipeline. And that a shared plugin (that actually shares data across env) needs to be always used as a regular plugin.
But maybe it is unavoidable, because with the current API, we are just ignoring that all these rollup plugins exists. When we tried to make alias per plugin, we didn't have a good way to do it internally either.

I wonder if we should extend to applyToEnvironment(environment) => boolean | plugin, and so we can have something similar to what you did in rolldown-vite with a helper

{
  name: 'per-environment-alias',
  applyToEnvironment(environment) => aliasPlugin(environment.config.alias)
}

If an object is returned instead of a boolean, it replaces the current plugin with it for this environment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The user now needs to know that a per-env plugin can't be in the main pipeline. And that a shared plugin (that actually shares data across env) needs to be always used as a regular plugin.

Yeah, the user might sometime need to understand it. But I think that doesn't happen much and the decision of making shared plugins by default was good.

I wonder if we should extend to applyToEnvironment(environment) => boolean | plugin, and so we can have something similar to what you did in rolldown-vite with a helper

That would work too. I went with

makeEnvironmentAwarePlugin('per-environment-alias', env => aliasPlugin(env))

because it felt more intuitive from a plugin user standpoint for me (the metal model is that this function makes the plugin env-aware).


```js
function PerEnvironmentCountTransformedModulesPlugin() {
const state = usePerEnvironmentState<{ count: number }>(() => ({ count: 0 }))
return {
name: 'count-transformed-modules',
perEnvironmentBuildStartEnd: true,
buildStart() {
state(this).count = 0
}
transform(id) {
state(this).count++
},
buildEnd() {
console.log(this.environment.name, state(this).count)
}
}
}
```