How do you mock $env/static/public when using the Sveltekit framework? #25267
-
SummaryAccording to this this page, it should be possible to mock I have tried with this:
but it does not seem to work. Additional informationNo response Create a reproductionNo response |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
@JReinhold Can you check this? |
Beta Was this translation helpful? Give feedback.
-
"Supported" means that it doesn't break anything and that it reads the same values as your SvelteKit application does. It does not mean that you can mock it, only the properties listed in the How To Mock section are mockable. I'm open to suggestions if you think the support-table can be clearer about this. Can you describe the use case for needing to define different env vars on a per-story basis? |
Beta Was this translation helpful? Give feedback.
-
In my case, I kept getting this error: import type { StorybookConfig } from "@storybook/sveltekit"
import { type InlineConfig } from "vite"
const config: StorybookConfig = {
// ... other options ...
viteFinal(config): InlineConfig {
return {
...config,
plugins: [
{
name: "mockSvelteKitEnvDynamicPublic",
load(id: string) {
if (id === "\0virtual:$env/dynamic/public") return "export const env = {}"
},
},
...(config.plugins ?? []),
],
}
},
}
export default config The magin line is if (id === "\0virtual:$env/dynamic/public") return `
export const env = {
MY_ENV_VAR: "123",
OTHER_VAR: "test",
// ...
}
` You can of course also mock any other virtual module the same way. You can even customize the values per-story like so: if (id === "\0virtual:$env/dynamic/public") return `
export const env = {}
globalThis.mockEnv = env
` Then use |
Beta Was this translation helpful? Give feedback.
"Supported" means that it doesn't break anything and that it reads the same values as your SvelteKit application does. It does not mean that you can mock it, only the properties listed in the How To Mock section are mockable.
I'm open to suggestions if you think the support-table can be clearer about this.
Can you describe the use case for needing to define different env vars on a per-story basis?