-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Svelte-Vite: Upgrading from 6.5 to 7.0 breaks Storybook because of svelteOptions
in main.cjs
#20236
Comments
@JReinhold FWIW it’s not a problem to have breaking changes in the Beta or even the RC. We try to handle all of them in the alpha, but stuff always comes up. What’s important is that we ship the right thing for users |
That's not quite true I think. IIUC, the svelte config is normally defined in a
We also have separate logic to load the svelte config, using I'm in favor of dropping support for What about webpack, though? It also supports specifying |
I'm supportive of removing |
Thanks for clearing that up @IanVS, that was a misunderstading on my part. Let's remove support for |
Ta-da!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.0.0-beta.8 containing PR #20270 that references this issue. Upgrade today to the
Closing this issue. Please re-open if you think there's still more to do. |
My threlte project requires a special preprocessor. How can I change the preproccesors, with the removal of svelteOptions? Instance of a threlte import preprocess from 'svelte-preprocess'
import seqPreprocessor from 'svelte-sequential-preprocessor'
import { preprocessThrelte } from '@threlte/preprocess'
const config = {
// …
preprocess: seqPreprocessor([preprocess(), preprocessThrelte()])
}
export default config |
@yustarandomname as long as you have it in |
Relevant maintainers:
@IanVS @benmccann @joshwooding
tl;dr
The default
svelteOptions
inmain.cjs
from 6.5 are breaking Storybook 7.0. I propose to not support that config property anymore, since it's unnecessary now that we are automatically loading the project's options from the root Vite config and Svelte config.The Problem
In a 6.5 setup with Svelte and Vite, the
svelteOptions
property inmain.cjs
is used to add specific options to the Svelte Vite plugin, most often adding the preprocess fromsvelte.config.js
(which is the default content aftersb init
).In 6.5 this is needed because we didn't load the root Vite config automatically.
The default
svelteOptions
in 6.5 looks like this:In theory it could also be used to add any options that the user wanted to be different from their app Svelte configuration, however after inspecting all instances of
svelteOptions
found on GitHub, exactly 0 of them had options that differed from their main Svelte config. Based on that, we can maybe conclude that that is actually not a use case.The
require
call is what's causing us problems, it makes Storybook fail instantly with:Most likely because Svelte and/or SvelteKit have moved to pure ESM, which we can't import with
require
(changing it toimport
doesn't fix it though, so it might be caused by something else).In 7.0 we automatically load the user's Vite config, and by extension Svelte config, so this isn't necessary anymore - users can and should remove their
svelteOptions
property unless there's a very very specific reason for them to have it thereProposed Solutions
A. Automigration to remove
svelteOptions
I think at least we should have an automigration that removes the
svelteOptions
property from the configuration. Initially I thought it should only suggest removing it if it was the default options, but after my GitHub crawling I personally think we should always recommend removing it, with a prompt explaining why, and why not.This solution could be done with B or C too.
B. Remove support for
svelteOptions
altogetherIt would technically be a breaking change to not support
svelteOptions
which we want to avoid at this stage in the release cycle, however:viteFinal
and thereby replacing the Svelte Vite plugin with their own instance and options.C. Keep support for
svelteOptions
We could keep supporting
svelteOptions
. It would require that if we detected customsvelteOptions
, we'd remove the Svelte Vite plugin added by the root Vite config, and add our own instance with the user's custom options.Additional Context
@IanVS have already flagged this before in #19280, but that issue and work ended up diverging in to so many topics that we forgot to conclude anything from it.
To Reproduce
The text was updated successfully, but these errors were encountered: