perf: legacy avoid insert the entry module css

[poyoho]

Description

simple build will collect all entry module css into chunk.viteMetadata.importedCss and inject into the index.html same with legacy.

legacy build should avoid insert the entry module css again

the test would same with #9507.

Sync chunk no generate the css but also had the style.
Async chunk should generate the css and had the style.

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.
• 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.

[bluwy]

I haven't quite caught up with the recent legacy changes, but are we now moving legacy-specific code into core? (just curious 😬)

[patak-dev]

This branch has always been in the css plugin. It would be great to move it plugin-legacy but there are some details where we are cheating from the inception of the plugin.

[poyoho]

maybe no. The previous PR #9507 fix the legacy build css (this if branch) no replace the asset flag(__VITE_ASSET) because the css-post later than asset. This PR optimized legacy build css generate logic, and this if branch will trigger by legcy build. 😊

[Tal500]

@patak-dev @sapphi-red, can you please explain me how after this logic, the JS navigation between entry pages, say in Nuxt.js, should work under Vite on legacy mode?

This PR should have canceled the ability to emulate in JS the navigation between one entry page to the other. In modern, the navigation performs preloading that loads the CSS, but in legacy, no preloading will happen.

Indeed, when I worked on SvelteKit legacy support as I mentioned in #9902, the CSS where not inlined because of this PR that were merged.

This was the main motivation for me to work on PR #9920, that clearly (relatively simply) solves all the compatibility issues, by preloading CSS both on modern and legacy.

[sapphi-red]

IIUC this PR is fixing #2062 (comment) by removing the inlined one.
So I guess preload for CSS in entry chunk won't work after this PR.

[Tal500]

IIUC this PR is fixing #2062 (comment) by removing the inlined one. So I guess preload for CSS in entry chunk won't work after this PR.

So am I right in my observation that this PR breaks some good behavior, and now the CSS loading on navigation for entry files is breaking on legacy, not only on SvelteKit(on legacy, by my external proposal on SvelteKit)?

[poyoho]

do you mean some preload link <link rel="modulepreload" href="..."> can worker on legacy mode and the legacy js also no load the css?

[Tal500]

do you mean some preload link <link rel="modulepreload" href="..."> can worker on legacy mode and the legacy js also no load the css?

No. What I mean is this:
This PR remove CSS inlining on legacy, for all the chunks that is considered to be entry points.

If you serve static SSR, and the navigation between pages isn't handled by JS(such in Next.js, Nuxt and SvelteKit), nothing is wrong in this because the CSS files were already loaded on initial SSR in the <link> tag(also on legacy).

For example, if you're using Nuxt and you on page "/"(homepage), and the user navigates to the "/about" page, the page wouldn't be loaded again by SSR, rather the navigation will be dynamic by JS code.
If you're on modern, than on Vite preload, the CSS files needed for the "/about" page will be injected dynamically in link tags to the head.
However, if you're on legacy, than the styles should be injected via inline styling while dynamically navigating to the "/about" page, but because of this PR no inline styling will be on legacy, since the chunk correlated to the "/about" page is considered to be an entry chunk.

[poyoho]

and the user navigates to the "/about" page, the page wouldn't be loaded again by SSR rather the navigation will be dynamic by JS code.

It mean the navigation by client js don't deps on SSR again. But I don't know why the /about page will considered to be an entry chunk.

I guess the /about page will bunlded by SSG. so all the page will be an entry point, and the / -> /about, client also use the SSG output js chunk(as entry point bundled and no preload css). So /about mistakenly considered as main entry.

IIUC, your PR #9920 maybe can resolve this, make the css as chunk and dynamic load is also can reduce the legacy mode size. 👍

[sapphi-red]

My this comment (#9761 (comment)) was talking about <link rel="preload" href="...">.

However, if you're on legacy, than the styles should be injected via inline styling while dynamically navigating to the "/about" page, but because of this PR no inline styling will be on legacy, since the chunk correlated to the "/about" page is considered to be an entry chunk.

If build.rollupOptions.input is ['index.html', 'about.html'], the chunk loaded by about.html will be an entry chunk. But when you are using client-side routing, I guess build.rollupOptions.input is ['index.html'] and will be code-splitted at dynamic import. In that case, the first chunk loaded by html is an entry chunk, but other's won't be an entry chunk (e.g. chunk that loaded depending on path).

[poyoho]

yes, It may be two case to replay.

1. such as in Next.js, Nuxt and SvelteKit downstream, they need to SSG for each page.
2. build.rollupOptions.input is ['index.html', 'about.html']

[Tal500]

If build.rollupOptions.input is ['index.html', 'about.html'], the chunk loaded by about.html will be an entry chunk. But when you are using client-side routing, I guess build.rollupOptions.input is ['index.html'] and will be code-splitted at dynamic import. In that case, the first chunk loaded by html is an entry chunk, but other's won't be an entry chunk (e.g. chunk that loaded depending on path).

But now what will happen on legacy mode when the user first load the "/about" page(which is serve by SSR with the CSS content in <link> tag), and then decide to navigate to the homepage ("/")? My point is that you can't predict, nor should you, which page will be loaded first, and therefore you treat all of the site pages by default as SSR-abled(here it means as entries).

This is a consensus in all the SSR/SSG methodology, to treat every page (by default) as entry.

[sapphi-red]

If it works like that, I guess it's a server-side routing. Or it has a custom handing that isn't handled by Vite.

[Tal500]

If it works like that, I guess it's a server-side routing. Or it has a custom handing that isn't handled by Vite.

Are you suggesting that Vite shouldn't care at all (even not even via some configuration varaible?) a client side routing between two entry points? It just seems a crucial part of Vite preloading.

Can someone test the scenario I described earlier in Vue&Nuxt when the mode is legacy? It might have the same critical bug there I were facing with SvelteKit legacy. I just don't Vue enough to do so by myself.

If we don't want to merge #9920 (hope it will be merged finally though), here is an alternative solution that reduces the double loading of entry points CSS(i.e. loading both ".css" and the inlined CSS in JS) for legacy mode:
If the file isn't entry, perform the same as today, just inline the CSS in the JS code. If the file is entry, then have two JS files:

1. A JS file that contain the original page JS code.
2. A JS file containing a function that returns a string of the inlined CSS.

On initial page load, i.e. SSR, just serve 1, like happens today.
On Vite preloading function, on legacy mode, load additionally the corresponding JS files of 2, if the file is entry (i.e. the additional JS files of 2 should be passed in the parameter).

[sapphi-red]

Are you suggesting that Vite shouldn't care at all (even not even via some configuration varaible?) a client side routing between two entry points? It just seems a crucial part of Vite preloading.

No, I'm not suggesting that. I'm just saying that I guess that behavior is not handled by Vite.
AFAIK Vite injects entry chunk references to HTML and entry chunks won't be loaded from non-entry chunks.

For a client side routing app that is chunk splitted at dynamic imports, Vite will preload CSS before loading that chunk.
But IIUC what you are saying is not this case, because splitted chunks won't be an entry chunk.

[Tal500]

For a client side routing app that is chunk splitted at dynamic imports, Vite will preload CSS before loading that chunk. But IIUC what you are saying is not this case, because splitted chunks won't be an entry chunk.

What happen today is that preloading CSS, together with preloading the JS in general, isn't happaning at all on legacy mode (and PR #9920 changes this behaviour).
This is why on modern mode, everything works great no matter if the CSS is part of entry or not. However, on legacy mode, since there is no preloading, rather just inlined CSS in JS (and this will be empty for entry points), the case is different here.

TD'LR: In modern mode everything just works, in legacy mode not everything works. This seems to be a wrong behavior overall as far as I understand.

[Tal500]

I formed a suitable issue for out latest discussion in #10285. The continuation of this conversation can be moved there.