Add CSS entrypoints to the manifest

[jessarcher]

Vite does not currently include CSS entry points in the manifest because the standard approach to loading CSS with Vite is to import it via JavaScript.

The problem with loading CSS via JavaScript with Blade, is that in HMR mode, the CSS is injected into the page via JavaScript, and browsers do not block rendering for this, which leads to a "flash of unstyled content" (FOUC) on every page load. It's not an issue with SPAs because the JavaScript also renders the HTML.

This is not an issue in production because we can determine from the manifest the appropriate <link rel="stylesheet"> tags to create from any JavaScript entry points.

To solve this in HMR mode, we need to output <link rel="stylesheet"> tags for CSS, which means we need to specify the CSS files as entry points to the @vite directive. Once we're specifying CSS as entry points, they need to exist in the manifest to be able to load them in production.

There is an open PR to Vite to include CSS entries in the manifest, however, this may not make it into Vite 2 (or even 3 potentially). A solution, at least for the time being, is for our plugin to augment the manifest with CSS entry points. It does this by listening to the renderChunk hook to record the appropriate manifest entries and then hooking into the writeBundle hook to update the manifest. We can hopefully remove this workaround once the above PR is released.

Other backend integration plugins follow a similar approach.

There is currently a separate issue with Vite in HMR where where it currently only updates the href of the <link> tag with a new timestamp when a change occurs. This leads to a FOUC every time an HMR change is made, which is arguably worse than only on page load. Thankfully, @timacdonald has an open PR to Vite which keeps the existing <link> in place until the replacement has loaded. Once that is merged, this will be good to merge also.

[timacdonald]

vitejs/vite#8495 has been merged and is scheduled to be released in Vite 2.9.11

[jessarcher]

This is good to go then! The Vite team is understandably not keen on backporting vitejs/vite#6649 to Vite 2, so we will need this workaround at least temporarily.

[timacdonald]

Once this is merged and assuming vitejs/vite#6649 is merged, we will want to rebase the Vite 3 branch and remove this code.