Vue: fix vue-component-meta docgen HMR not working

[IonianPlayboy]

Closes #27514

What I did

Currently, the vue-component-meta plugin is only running when Storybook is initially launched, but it never updates afterwards. The only way to get the updated values inside Storybook is to stop the dev server and relaunch it everytime there is a change, which is a far from ideal DX experience.

This PR proposes two steps (each in a separate commit) to improve the current experience :

• Update the generated meta whenever the component is changed. This allows the users at the very least to refresh the Storybook page inside the browser to get the updated meta inside theirs stories, without having to restart the dev server.
• Once the component meta has been updated, trigger a full reload. With this change, there is no actions needed from the user to see the updated meta inside theirs stories. I am not very familiar with Vite HMR API or the way Storybook integrates it in its own builder, so maybe there is a more efficient to achieve the same result here without a full reload.

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 sandbox for the Vue 3 Vite template, e.g. yarn task --task sandbox --start-from auto --template vue3-vite/default-ts
2. Update the generated .storybook/main.ts to use the vue-component-meta plugin for docgen:

 framework: {
    name: '@storybook/vue3-vite',
    options: {
      docgen: {
        plugin: 'vue-component-meta',
        tsconfig: 'tsconfig.app.json',
      },
    },
  },

3. Open Storybook in your browser
4. Access the Button story
5. Update the Button.vue component to change the generated meta, for example with a new prop:

  /**
   * add border to the button
   */
  withBorder?: boolean,

7. Confirm that the Button story has been updated correctly, for example with the added withBorder prop:
   

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-storybook/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	78.2 MB	78.2 MB	0 B	1.16	0%
initSize	143 MB	143 MB	2.83 kB	1.18	0%
diffSize	65.1 MB	65.1 MB	2.83 kB	1.16	0%
buildSize	6.88 MB	6.88 MB	0 B	1.12	0%
buildSbAddonsSize	1.51 MB	1.51 MB	0 B	-	0%
buildSbCommonSize	195 kB	195 kB	0 B	-	0%
buildSbManagerSize	1.9 MB	1.9 MB	0 B	1.11	0%
buildSbPreviewSize	271 kB	271 kB	0 B	-	0%
buildStaticSize	0 B	0 B	0 B	-	-
buildPrebuildSize	3.88 MB	3.88 MB	0 B	1.11	0%
buildPreviewSize	3 MB	3 MB	0 B	1.11	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	6.5s	6.7s	164ms	-0.92	2.4%
generateTime	19.5s	19.8s	333ms	-0.65	1.7%
initTime	13.5s	15.9s	2.3s	0.28	14.9%
buildTime	8.1s	8.8s	660ms	-0.22	7.5%
testBuildTime	0ms	0ms	0ms	-	-
devPreviewResponsive	5.5s	5.1s	-314ms	-1.06	-6.1%
devManagerResponsive	3.5s	3.3s	-150ms	-0.89	-4.4%
devManagerHeaderVisible	473ms	553ms	80ms	-0.52	14.5%
devManagerIndexVisible	500ms	607ms	107ms	-0.56	17.6%
devStoryVisibleUncached	602ms	894ms	292ms	-0.45	32.7%
devStoryVisible	499ms	580ms	81ms	-0.74	14%
devAutodocsVisible	467ms	505ms	38ms	-0.39	7.5%
devMDXVisible	450ms	488ms	38ms	-0.55	7.8%
buildManagerHeaderVisible	631ms	505ms	-126ms	-0.85	-25%
buildManagerIndexVisible	648ms	516ms	-132ms	-0.85	-25.6%
buildStoryVisible	630ms	509ms	-121ms	-0.8	-23.8%
buildAutodocsVisible	477ms	425ms	-52ms	-0.72	-12.2%
buildMDXVisible	478ms	423ms	-55ms	-0.66	-13%

Greptile Summary

Enhanced HMR functionality for Vue component metadata in Storybook by adding support for dynamic updates without requiring server restarts.

• Added handleHotUpdate hook in code/frameworks/vue3-vite/src/plugins/vue-component-meta.ts to update component metadata on file changes
• Implemented module invalidation using Vite's HMR API to ensure proper cache clearing
• Added full page reload trigger via WebSocket to refresh component documentation
• Fixed issue [Bug]: vue-component-meta docgen HMR not working #27514 where vue-component-meta docgen changes weren't reflected without server restart

[greptile-apps]

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

[greptile-apps]

style: Consider using more granular HMR updates instead of full page reload. A full reload works but may impact development experience for large applications.

[kasperpeulen]

@larsrickert What do you think about this?