fix!: default build.cssMinify to 'esbuild' for SSR

[sapphi-red]

Description

Even for SSR, there's no reason to skip minify for CSS files.

SvelteKit and Astro sets this.
https://github.com/sveltejs/kit/blob/6200a48befe538176b1f5c1cb9e32c51af84345b/packages/kit/src/exports/vite/index.js#L607
https://github.com/withastro/astro/blob/7e1db8b4ce2da9e044ea0393e533c6db2561ac90/packages/astro/src/core/build/static-build.ts#L178-L180

Additional context

---

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, especially the Pull Request Guidelines.
• 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).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

@sapphi-red you marked this as a breaking change, would we still be able to merge it for Vite 5.1? Vite 6 is too far away right now.

[patak-dev]

Ah, ok, I see:

• docs: build.minify defaults to false for SSR #15636

I think we could still merge this one in Vite 5.1, but maybe I'm missing something here.

[sapphi-red]

I think the change has a slightly big impact. Given that there's a workaround, I think it's better to wait for Vite 6.

[bluwy]

Should we also only minify only if ssrEmitAssets is true? Otherwise the minified result is thrown away.

[sapphi-red]

Should we also only minify only if ssrEmitAssets is true? Otherwise the minified result is thrown away.

Even if ssrEmitAssets is false, the user wants the same file hash for CSS files (also for other assets). To get the same file name between client and server, the same content needs to be generated. So I think we need to enable minify.

[bluwy]

I don't quite understand how one would compare the same file name between client and server if ssrEmitAssets is false? There won't be any assets in the first place. And the JS generated by client and server builds would already be different.

[bluwy]

Ah I guess checking the Remix issue, it's because the hash is exposed for .css?url 🤔

[sapphi-red]

Yep, the the hash is exposed for .css?url. The URL on the server points to nothing.
Example: https://stackblitz.com/edit/vitejs-vite-8zxxdh?file=main.js

[sapphi-red]

I'm using raw.ssr to align with minify: raw.ssr ? false : 'esbuild', above. Do we want to update that to consumer === 'server'? I guess we don't want to, because we would want to enable minify for edge runtimes.

[bluwy]

I don't quite understand the question, would edge runtimes be consumer == 'server' true too? Checking consumer seems correct to me, unless we want external environments to decide on the default themselves.

[sapphi-red]

would edge runtimes be consumer == 'server' true too?

Yes, it would. Just that enabling minify for edge runtimes are more sensible default as they commonly have a file size limit. (nitro does that: base-worker, netlify edge, cloudflare workers, vercel edge).
But on second thought, since we don't have a concept of edge runtime anymore, probably we can just disable minify for all consumer === 'server'.

[bluwy]

I think I'm even more confused now 😄 If we're talking about CSS minify, isn't this PR about enabling that for SSR (or server consumers) by default so that they match the client output?

[sapphi-red]

Yes, that is correct. The comments were talking about minify option (not the cssMinify option). It was suggesting to change minify: raw.ssr ? false : 'esbuild' to minify: consumer === 'server' ? false : 'esbuild' or minify: consumer === 'server' && !notWorker ? false : 'esbuild'. Why this is related to this PR is because the condition should be same between minify and cssMinify. For example, if minify is changed to minify: consumer === 'server' && !notWorker ? false : 'esbuild', then cssMinify should be cssMinify: consumer === 'server' && !notWorker ? 'esbuild' : !!resolved.minify. It is because we want to set a different default value from !!resolved.minify only when resolved.minify was implicitly set to false (= when the default value was used).

[bluwy]

Ah everything makes sense now, I didn't realize you we're talking about changing to consumer === 'server' to the minify option.

My first intuition is that I agree with you at "I guess we don't want to, because we would want to enable minify for edge runtimes.", but then we're partial towards edge runtime being extended, e.g. what if it's a rsc environment.

notWorker check seems to be a better addition check to alleviate this case, would it be based on webCompatible? I guess my only fear with all these later is that it could be hard to explain in docs.

Would be good to have @patak-dev chime in too as this relates to fallback values for different environments.

[patak-dev]

Yes, we missed this one. We should move to minify: consumer === 'server' ? false : 'esbuild' (for both).

About edge environments, they can set minify: false as their default:

function edgeEnvironment(userConfig) {
  return mergeConfig({
      build: {
        minify: false
      }
      dev: {
        createEnvironment: ...
      }
    },
    userConfig
  );
}

[sapphi-red]

Replaced with consumer === 'server' 👍