Skip to content

feat: resolve environments plugins at config time #20120

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

Merged
merged 8 commits into from
May 29, 2025

Conversation

patak-dev
Copy link
Member

Description

We recently discussed with @dominikg about environment plugins resolutions and he asked how to access the resolved plugins for a given environment. These are currently present at environment.plugins once the instance are inited. So during dev, there is the need to wait after server listen.

We decided to pass a PartialEnvironment to applyToEnvironment to avoid committing to resolving the plugins after the Environment instance are created, and leave the door open to move the resolution to config time. This PR explores this change.

The benefits are:

  • The plugins for each environments are available at resolvedConfig.environments[name].plugins.
  • configResolved can be used to read this values.
  • vite-plugin-inspect et al would be easier to implement.
  • Align with the way config.plugins always worked (they are fixed at config time, not after the server is created)
  • Easier to explain

The main difference with creating the plugins in the Environment instance is that if two Environments are created with the same config, they will share the environment plugins after this PR. We only allow a single server per ResolvedConfig, and we should do the same for Environments so this doesn't seems like an issue to me.

@patak-dev patak-dev added feat: environment API Vite Environment API p2-nice-to-have Not breaking anything but nice to have (priority) labels May 27, 2025
@github-project-automation github-project-automation bot moved this to Discussing in Team Board May 27, 2025
@patak-dev patak-dev added this to the 7.0 milestone May 27, 2025
Copy link
Member

@sapphi-red sapphi-red left a comment

Choose a reason for hiding this comment

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

The change sounds good to me.

@@ -1450,10 +1453,20 @@ export async function resolveConfig(
.getSortedPluginHooks('configResolved')
.map((hook) => hook.call(resolvedConfigContext, workerResolved)),
)
;(workerResolved.plugins as Plugin[]) = resolvedWorkerPlugins
Copy link
Member

Choose a reason for hiding this comment

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

Could we have a comment that explains why this need to mutate workerResolved.plugins? Also do we also need to mutate workerResolved.environments, or is that fine?

Copy link
Member Author

Choose a reason for hiding this comment

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

Added comments, and rearranged the code so it is easier to follow (hopefully). Also avoided recreating the worker resolved config after passing it to hooks (as they may store a reference) and fixed resolvedConfig for hooks, that should be after resolve the environment plugins ad08fee

@patak-dev patak-dev merged commit f6a28d5 into main May 29, 2025
42 of 44 checks passed
@patak-dev patak-dev deleted the feat/resolve-environments-plugin-at-config-time branch May 29, 2025 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat: environment API Vite Environment API p2-nice-to-have Not breaking anything but nice to have (priority)
Projects
Status: Discussing
Development

Successfully merging this pull request may close these issues.

2 participants