fix(plugin-legacy): skip in SSR build

[andylizi]

Description

Disable plugin-legacy in SSR build, since it's obviously not needed, and the output won't be used in html files anyway.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[Shinigami92]

/cc @brillout

[tjk]

A resolved config doesn't change throughout the build, right? It's a tad unfortunate that in the "framework" style of plugin insertion, there is no support for resolving the config once and then nesting an array of plugins underneath that (or in this case just returning []) -- would mean these checks wouldn't have to be spread out.

On a slightly tangential note, the config.lib.build check and error in legacy-post-process doesn't happen until enforce: "post" but that could be known upfront so we don't have to delay the failure. Is that correct?

Also there is currently a apply option on Plugin... could that be extended a bit so more simple config setting checks can be done by vite instead of plugins themselves?

---

That aside, I haven't done a proper check of whether all these checks are correct but I'm very much in support of disabling plugin-legacy if it's not needed at all (and causing errors, see #4818)!

[antfu]

I guess ideally we could have some feature extends apply, like

apply: 'client-build' | 'ssr-build'

but in that case, maybe a function would be more flexible:

apply(config) {
  return config.command === 'build' && !config.build.ssr
}

🤔

[brillout]

I'm voting for a function; I can see other scenarios where an apply function would be helpful.

[brillout]

I agree that we should disbale the plugin for SSR but that we should accomodate a nicer way to disable plugins.

The current implementation is brittle. An apply() function would be a rock-solid solution 😍.

[andylizi]

I've submitted #4857 for apply function, and we can rewrite this PR pending that.

[brillout]

Neat 👌.

we can rewrite this PR pending that.

We can already rebase it against your other PR now, even though it's not merged yet.

[patak-dev]

Thats great @andylizi 👍

We can already rebase it against your other PR now, even though it's not merged yet.

Please dont. Lets merge this one so we can fix #4818, and release tomorrow. Getting approval for apply will take some days

[andylizi]

Uh, I just realized, there may be a bit of a problem with the current implementation.……

vite/packages/plugin-legacy/index.js

Lines 451 to 462 in 1f068fc

	const legacyEnvPlugin = {
	name: 'legacy-env',
	config(_, env) {
	if (env) {
	return {
	define: {
	'import.meta.env.LEGACY':
	env.command === 'serve' ? false : legacyEnvVarMarker
	}
	}
	} else {

I didn't gate this part with a SSR check, so when building in SSR mode, it will inject the marker as import.meta.env.LEGACY, but cannot later replace it due to relevant parts being disabled.

vite/packages/plugin-legacy/index.js

Lines 252 to 262 in 1f068fc

	if (raw.includes(legacyEnvVarMarker)) {
	const re = new RegExp(legacyEnvVarMarker, 'g')
	let match
	while ((match = re.exec(raw))) {
	ms.overwrite(
	match.index,
	match.index + legacyEnvVarMarker.length,
	`false`
	)
	}
	}

So if I'm understanding the process correctly (haven't tested), this will cause SSR build to throw ReferenceError: __VITE_IS_LEGACY__ is not defined…… And it wasn't caught by tests because we didn't test legacy with SSR.

Oops? 😅

[patak-dev]

Nice catch @andylizi! Would you like to add these tests to the playgrounds? Since plugin-legacy takes some time to spin, it would be interesting to see if we could add a basic SSR setup to the current playground/plugin-legacy just to avoid these regressions in the future.

[andylizi]

Sure. #4861