prebundle the preview #19718
prebundle the preview #19718
Conversation
code/addons/storyshots/storyshots-core/src/frameworks/angular/loader.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Ian VanSchooten <[email protected]>
…-out-plan-for-package-structure-rework # Conflicts: # code/addons/links/package.json # code/addons/storyshots/storyshots-puppeteer/package.json # code/lib/api/package.json # code/lib/builder-vite/package.json # code/lib/builder-vite/src/index.ts # code/lib/builder-webpack5/package.json # code/lib/client-api/package.json # code/lib/codemod/package.json # code/lib/core-client/package.json # code/lib/core-server/package.json # code/lib/csf-tools/package.json # code/lib/source-loader/package.json # code/lib/store/package.json # code/lib/types/package.json # code/ui/blocks/package.json # code/ui/components/package.json # code/yarn.lock
|
@ndelangen, I took a slightly different approach to generate exports.ts for I think this is working in the vite builder. I verified that everything works great when building a sandbox. In dev, though, I'm seeing a case where the browser opens before the preview builder is finished building, and that same strange behavior we saw initially where requests would hang for a minute or two before finishing. I didn't remove the extra re-exports in preview, though I think they're no longer needed if we take this approach. |
…work' of github.com:storybookjs/storybook into norbert/sb-798-figure-out-plan-for-package-structure-rework
| <script type="module"> | ||
| /* eslint-disable import/no-absolute-path, import/extensions, import/no-unresolved */ | ||
|
|
||
| import '/sb-preview/runtime.mjs'; |
There was a problem hiding this comment.
There was a problem hiding this comment.
In this case I think the two urls are equivalent since iframe.html is at the root of the site, right? The relative path looks a little odd to me, personally, but I don't feel strongly so long as both work correctly, including when the site is served at a subpath (e.g. github pages).
There was a problem hiding this comment.
It's not always the root of the site
|
@IanVS I changed the code a bit so it mimics the manager more |
|
@tmeasday vite is implemented! |
| options, | ||
| router, | ||
| server, | ||
| channel: serverChannel, |
There was a problem hiding this comment.
The docs for builders will need to be updated.
There was a problem hiding this comment.
true, will do this in a follow-up PR
| @@ -0,0 +1,94 @@ | |||
| # Preview (Web) | |||
|
|
|||
| This is the main API for the (web) version of the Storybook Preview. | |||
There was a problem hiding this comment.
Maybe this README should also explain a bit about the globals?
| * If you forget to do either, TypeScript will complain. | ||
| * | ||
| * This `definitions.ts` file is consumed by the `builder-manager` package, | ||
| * The `runtime.ts` file is used inside the manager's browser code runtime. |
There was a problem hiding this comment.
Copy-paste errors from manager code
| configFile: false, | ||
| cacheDir: 'node_modules/.cache/.vite-storybook', | ||
| root: path.resolve(options.configDir, '..'), | ||
| // Allow storybook deployed as subfolder. See https://github.com/storybookjs/builder-vite/issues/238 | ||
| base: './', | ||
|
|
There was a problem hiding this comment.
Nit: I think this newline was accidental.
ndelangen
deleted the
norbert/sb-798-figure-out-plan-for-package-structure-rework
branch
ndelangen
restored the
norbert/sb-798-figure-out-plan-for-package-structure-rework
branch
ndelangen
deleted the
norbert/sb-798-figure-out-plan-for-package-structure-rework
branch
cleanup up version of #19678
Split the work required to get the preview to run into steps, where we can do some of the work ahead of time, so the user's builder has to do less work.
The way we slit the work is by taking a bunch of packages and pre-bundle them together, into a single module.
At the builder stage, we then swap packages to shims. These shims exports everything that the package is supposed to export, but it does so by de-structuring it off the global namespace.
This causes the builder to have to do less work, because the dependency graph is more shallow.