Builder-Vite: Add null character prefix to virtual file IDs

[valentinpalkovic]

Closes #28567

What I did

I have added a null byte to the resolveID for virtual files. Virtual modules should be prefixed with a null byte to avoid a
false positive "missing source" warning. Context: https://github.com/vitejs/vite/pull/5587/files#diff-414e1bd440bdc6c3c213c6f9cc712d2b29b1c1662b04a9daa9c02ee6bcca9432R11-R15

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

1. Run a vite-based sandbox for template, e.g. yarn task --task sandbox --start-from auto --template react-vite/default-ts
2. Open Storybook in your browser
3. The terminal should not log the following console.log:

Sourcemap for "/virtual:/@storybook/builder-vite/setup-addons.js" points to missing source files
Sourcemap for "/virtual:/@storybook/builder-vite/vite-app.js" points to missing source files

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

name	before	after	diff	z	%
createSize	0 B	0 B	0 B	-	-
generateSize	76.3 MB	76.3 MB	0 B	-0.11	0%
initSize	167 MB	167 MB	81 B	-0.65	0%
diffSize	91.1 MB	91.1 MB	81 B	-0.65	0%
buildSize	7.42 MB	7.42 MB	0 B	1.36	0%
buildSbAddonsSize	1.61 MB	1.61 MB	0 B	-1.36	0%
buildSbCommonSize	195 kB	195 kB	0 B	-	0%
buildSbManagerSize	2.29 MB	2.29 MB	0 B	1.36	0%
buildSbPreviewSize	351 kB	351 kB	0 B	-1.36	0%
buildStaticSize	0 B	0 B	0 B	-	-
buildPrebuildSize	4.45 MB	4.45 MB	0 B	1.36	0%
buildPreviewSize	2.97 MB	2.97 MB	0 B	-1.36	0%
testBuildSize	0 B	0 B	0 B	-	-
testBuildSbAddonsSize	0 B	0 B	0 B	-	-
testBuildSbCommonSize	0 B	0 B	0 B	-	-
testBuildSbManagerSize	0 B	0 B	0 B	-	-
testBuildSbPreviewSize	0 B	0 B	0 B	-	-
testBuildStaticSize	0 B	0 B	0 B	-	-
testBuildPrebuildSize	0 B	0 B	0 B	-	-
testBuildPreviewSize	0 B	0 B	0 B	-	-

name	before	after	diff	z	%
createTime	21s	19.5s	-1s -496ms	0.05	-7.6%
generateTime	18.9s	26.3s	7.3s	1.13	27.9%
initTime	16s	22.6s	6.6s	1.54	🔺29.3%
buildTime	15.2s	10.5s	-4s -664ms	-1.39	🔰-44.2%
testBuildTime	0ms	0ms	0ms	-	-
devPreviewResponsive	6.6s	9.4s	2.8s	0.84	30.3%
devManagerResponsive	4.2s	5.4s	1.2s	0.51	22.2%
devManagerHeaderVisible	690ms	1s	392ms	2.73	🔺36.2%
devManagerIndexVisible	717ms	1.1s	399ms	2.79	🔺35.8%
devStoryVisibleUncached	1.2s	1.7s	582ms	2.84	🔺32.5%
devStoryVisible	736ms	1.1s	395ms	2.74	🔺34.9%
devAutodocsVisible	607ms	832ms	225ms	0.76	27%
devMDXVisible	650ms	765ms	115ms	0.39	15%
buildManagerHeaderVisible	682ms	952ms	270ms	1.64	🔺28.4%
buildManagerIndexVisible	683ms	960ms	277ms	1.66	🔺28.9%
buildStoryVisible	722ms	993ms	271ms	1.54	🔺27.3%
buildAutodocsVisible	596ms	818ms	222ms	1.07	27.1%
buildMDXVisible	565ms	760ms	195ms	0.91	25.7%

Greptile Summary

The PR resolves 'missing source' warnings by adding a null byte prefix to virtual file IDs in the code-generator-plugin.ts file, ensuring correct identification and handling by Vite.

• Modified /code/builders/builder-vite/src/plugins/code-generator-plugin.ts to add null byte prefix to virtual file IDs in resolveId and load functions.
• Ensures virtual modules are correctly identified, preventing false positive warnings.
• Aligns with Vite's handling of virtual files, mitigating potential issues with source maps.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 68be834. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 2 targets

• nx affected -t check -c production --parallel=7
• nx run-many -t build -c production --parallel=3

---

Sent with 💌 from NxCloud.

[greptile-apps]

LGTM

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings}

[greptile-apps]

LGTM

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings}

[ndelangen]

😮

[IanVS]

Just curious, why not update the ID constants themselves?

[valentinpalkovic]

This would affect the imports as well, and I wasn't sure about changing them. I just changed what resolveId returns and what the load hook actually receives. But for sure. If the null byte change doesn't affect the actual imports, I can change it!

[IanVS]

Well, to my knowledge, those are just made-up constant names for the virtual files, which should be used wherever we deal with those virtual files. I'm not sure what you mean by "the actual imports", since those imports will still pass through resolveId, so as long as the same value is being used everywhere it should be fine (this is the reason I made them constants, to be sure they didn't change in only one spot and not another).

I would encourage at least trying it out, I think it would be a cleaner approach.

[valentinpalkovic]

I will. I will create a new PR!

[valentinpalkovic]

@IanVS Here we go:
#28867