You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After adding any of the following Storybook packages (@storybook/nextjs, @storybook/react-webpack5, or @storybook/server-webpack5) to a Next.js 14 + NX 19 project, all environment variables become undefined after the build. The issue occurs even without implementing any Storybook-specific code. Changing the environment variable file from .env.serve.local to .env resolves the issue, but this is not a desirable solution since we need to use runtime environment variables with the serve prefix.
Expected behavior:
The environment variables should be accessible in runtime (after the build) with the serve prefix, and the Storybook packages should not interfere with this configuration.
Actual behavior:
When any of the mentioned Storybook packages are added to package.json, the environment variables become undefined after the build. This happens even if no code implementation for Storybook is added. Changing the file name from .env.serve.local to .env makes the variables accessible again, but this is not a desired solution since we need to inject environment variables during runtime, not at build time.
Questions:
How can I prevent Storybook packages from overwriting my existing environment variable configuration during build?
Is there a way to integrate Storybook with the existing runtime environment variable setup without causing issues with the build configuration?
Describe the bug
After adding any of the following Storybook packages (@storybook/nextjs, @storybook/react-webpack5, or @storybook/server-webpack5) to a Next.js 14 + NX 19 project, all environment variables become undefined after the build. The issue occurs even without implementing any Storybook-specific code. Changing the environment variable file from
.env.serve.local
to.env
resolves the issue, but this is not a desirable solution since we need to use runtime environment variables with the serve prefix.Expected behavior:
The environment variables should be accessible in runtime (after the build) with the serve prefix, and the Storybook packages should not interfere with this configuration.
Actual behavior:
When any of the mentioned Storybook packages are added to package.json, the environment variables become undefined after the build. This happens even if no code implementation for Storybook is added. Changing the file name from .env.serve.local to .env makes the variables accessible again, but this is not a desired solution since we need to inject environment variables during runtime, not at build time.
Questions:
How can I prevent Storybook packages from overwriting my existing environment variable configuration during build?
Is there a way to integrate Storybook with the existing runtime environment variable setup without causing issues with the build configuration?
Reproduction link
Reproduction steps
Steps to reproduce:
Set up a project using Next.js 14 and NX 19.
Configure environment variables in runtime (using
.env.serve.local
with a serve prefix as per [NX's documentation](https://nx.dev/recipes/tips-n-tricks/define-environment-variables)).Only files with
serve
prefix, without original.env file
Add one of the following Storybook packages to package.json:
@storybook/nextjs
@storybook/react-webpack5
@storybook/server-webpack5
Build the application.
Run application using
serve:[appropriate prefix for the environment variable file]
Observe that all environment variables are undefined in runtime
System
Additional context
The environment variables are correctly injected during runtime with the serve prefix (.env.serve.local).
The issue appears to stem from the configuration in the Storybook packages, which may be overriding the NX/webpack setup for environment variables.
We do not want to change the variable file naming convention to .env, as this would affect the runtime behavior.
The text was updated successfully, but these errors were encountered: