v3.20.0 breaks Vite Storybook builds

[IanVS]

Rollup Version

3.20.0

Operating System (or Browser)

Mac/Linux

Node Version (if applicable)

No response

Link To Reproduction

https://634ff621f2a0d0f01971eae7-oclscgzyyl.chromatic.com/?path=/story/example-button--primary

Expected Behaviour

The daily storybook CI jobs, which create new projects with all the latest dependencies, began to fail yesterday. Specifically, vite projects were failing, mostly svelte and vue3, though it was a bit inconsistent. At first we thought this was due to the 4.2.1 release of Vite, but nothing in that small release could cause our issue. We pinned vite to an older version, and kept getting the failures

Then we looked at rollup, which also had a release yesterday. We pinned rollup to 3.19.1, and the failures stopped.

This is a really tricky one to troubleshoot, because so far it only reproduces reliably in CI, not locally. Though it can happen occasionally locally as well, it's not reliable enough for troubleshooting (once in 10 or 20 tries maybe).

Here is the storybook build output from a rollup 3.19.1 build:
https://app.circleci.com/pipelines/github/storybookjs/storybook/44977/workflows/b7df949a-2c35-4003-bccf-adba5b6cf938/jobs/502484/parallel-runs/22/steps/22-104

And here's the resulting storybook:
https://634ff621f2a0d0f01971eae7-pwrriypbvy.chromatic.com/?path=/story/example-button--primary

Actual Behaviour

In Storybook, we create a list of dynamic imports for stories: https://github.com/storybookjs/storybook/blob/351dbb6bac38be546c9653a2a538277fde9ff882/code/lib/builder-vite/src/codegen-importfn-script.ts#L29-L37. Vite (or rollup?) takes that dynamic import and creates a subarray of files (chunks) for each import. In rare cases, a chunk is included in that array which does not exist (e.g. Button-bc1a867b.css). Here's an example.

const L = {
    //...
	"./src/stories/Button.stories.js": async()=>t(()=>import("./Button.stories-31dc05da.js"), ["./Button.stories-31dc05da.js", "./Button-9407cf82.js", "./index-31b69ecb.js", "./Button-bc1a867b.css"], import.meta.url),

and we get an error like:

Unable to preload CSS for https://634ff621f2a0d0f01971eae7-oclscgzyyl.capture.chromatic.com/assets/Button-bc1a867b.css
    at HTMLLinkElement.<anonymous> (https://634ff621f2a0d0f01971eae7-oclscgzyyl.capture.chromatic.com/assets/iframe-aa39f297.js:1:1422)

This is an example storybook containing this error: https://634ff621f2a0d0f01971eae7-oclscgzyyl.chromatic.com/?path=/story/example-button--primary

To see the import array, look in the non-sourcemapped version of virtual:/@storybook/builder-vite/storybook-stories.js. Compare it to the working version from rollup 3.19.1 above, and you will see that in the working version, there is a reference to index-bc1a867b.css, which was generated in both cases.

Here is the build log of that storybook, which shows that no Button-X.css was created, but index-X.css was: https://app.circleci.com/pipelines/github/storybookjs/storybook/44964/workflows/ea841823-ce14-4065-a2be-38cc65a33364/jobs/502424/parallel-runs/22/steps/22-104

I wish I could give you a simpler, more minimal reproduction, but as I said I'm having a hell of a time getting this to happen locally, there's some kind of race condition involved. Perhaps it happens more reliably in CI due to the limited number of CPU cores available there, but I don't know how to artificially limit them when running locally. If you have any suggestions for us, that would be great.

Please let me know if there's anything we can do to try to help troubleshoot. As it is, we will need to tell Vite Storybook users to pin to rollup 3.19.1 until this is resolved.

[lukastaegert]

You can help we by guiding me how and where the build process is configured that produces these outputs. My guess so far is that it is related to the changed asset naming logic if several emitted files share their contents. Previously, Rollup would use the name of the file that is emitted first. Now, it uses sorting to pick a name.
As there are two changes in the last release, can you install Rollup from a commit

npm i rollup/rollup#3682f30a2019ceec398eb907a94a750413c66974

to see if this also has the issue? If yes, then it is definitely the asset handling logic and we need to revisit that.

[lukastaegert]

I think I have an idea what might be going on. The change broke this.getFileName for deduplicated assets in some situations. I will have a look if I can fix it, but if I do not manage to do so by tomorrow I will roll back the change.

[sapphi-red]

I think you are right. Vite calls this.getFileName just after this.emitFile is called.
https://github.com/vitejs/vite/blob/688a55787a4c0ec2b941327d242979cda06261b1/packages/vite/src/node/plugins/css.ts#L580
So the final file name and the result of this.getFileName gets inconsistent when this.emitFile is called with a same content.

[lukastaegert]

Fix at #4919

[rollup-bot]

This issue has been resolved via #4919 as part of rollup@3.20.1. You can test it via npm install rollup.