Svelte: Fix Vite crashing on virtual module imports

[rChaoz]

Closes #20562

What I did

Surround the readFileSync with a try/catch so there is no unhandled exception for trying to load non-existing files (which happen with virtual module imports).

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!

Install storybook in a SvelteKit project that uses unplugin icons. It doesn't work. With this PR it does.

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>

[IanVS]

Thanks for the PR, but I think the correct fix here is to use the src given to us rather than reading the file directly. Would you like to give that a shot?

Though, now I'm curious why we didn't just do that to begin with. It's been quite a while since I worked on any of this code...

[rChaoz]

@IanVS thanks the the suggestion! This is what I tried to do initially (as you can see by the commit history), but then the entire plugin stopped working. The src argument and the rawSource being read are not the same.

[JReinhold]

Thanks for the PR @rChaoz!

The src argument and the rawSource being read are not the same.

I think this is because we need the initial source, and not the source as transformed by all the plugins before it - but I could be completely wrong.

@rChaoz can you describe what will now happen in the case of virtual modules? "Ignoring" them now, how does that impact the result (other than not crashing of course)?

I guess it won't be an issue because there's no way for docgen data from virtual modules to be surfaced to users anyway, so it doesn't matter if we ignore them or not.
I wonder if we should just completely skip virtual modules in this plugin?

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit fd9f8a1. 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 1 target

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

---

Sent with 💌 from NxCloud.

[rChaoz]

@JReinhold so really, nothing changes for virtual modules - without this PR it just crashes, so it does nothing. With this PR it skips them, also doing nothing. So, it just allows it to run on files with virtual imports without crashing.

I believe it might be OK to just skip virtual modules altogether - the behaviour wouldn't be different.

[JReinhold]

I believe it might be OK to just skip virtual modules altogether - the behaviour wouldn't be different.

Can you make those changes? I think it would also make the code a bit clearer.