-
-
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
process.env is empty since 6.4.10 #17336
Comments
As a temporary workaround, we can use this in the module.exports = {
webpackFinal: async config => {
const definePlugin = config.plugins.find(
({ constructor }) => constructor && constructor.name === 'DefinePlugin',
);
if (definePlugin) {
definePlugin.definitions = injectEnv(definePlugin.definitions);
}
return config;
},
}; Where function injectEnv(definitions) {
const env = 'process.env';
if (!definitions[env]) {
return {
...definitions,
[env]: JSON.stringify(
Object.fromEntries(
Object.entries(definitions)
.filter(([key]) => key.startsWith(env))
.map(([key, value]) => [key.substring(env.length + 1), JSON.parse(value)]),
),
),
};
}
return definitions;
} Honestly though, I believe #17174 should be reverted, because this is quite a convoluted workaround to something that didn't need to be broken in the first place. I'm sure it wasn't intentionally broken, but it sure is a regression, iyam. |
There are two conflicting scenarios: destructuring 6.4.9
6.4.10
As far as I know, there is no easy way to get all three to work. If you have a suggestion for how to revert #17174 AND not have |
In the console, when I now log Question number two that mystifies me completely, On top of this, when our website runs by itself, outside of Storybook, our config is set up to have |
spent some time reading & re-reading the docs before i found this ... could someone add a note to those docs that it actually doesn't work since 6.4.10 and link to this issue? |
Is there more information about this issue yet? It is still occurring for me on storybook |
Also accessing process.env by variable is not working which is very strange @shilman I hope it can be resolved soon const name = "REACT_APP_API_URL";
console.log(process.env.REACT_APP_API_URL); // logs real value
console.log(process.env["REACT_APP_API_URL"]); // logs real value
console.log(process.env[name]); // logs undefined
console.log(process.env); // logs empty object |
@israelKusayev Exactly my point. What manner of black magic happens when logging some key in an object yields its real value, but the object as a whole logs empty. How? How how how? This really feels like bad practice hackery/trickery, so I would say the cure is worse than the disease, so to speak. |
What is the status on this issue? Makes Storybook unusable, if you want some of the newer features. |
Maybe the following issues are the same cause. |
Can we get an update on where this issue is at? |
I'm in the same boat 😢 |
It seems that in storybook 6.4.19 if your .env has:
and your code has
the code actually executed is:
and so having code like:
results in:
which doesn't end well! It also seems that if If you add
to the default exports of main.js you'll get no imports from the .env and be able to configure them for each story as needed. This seems good to me as I would expect a story's behaviour to be predictable and independent of the local .env especially if you have tests for your stories. |
Can we get an update on this issue?! |
It seems that this problem has not been solved even in Storybook ver6.5, so I will describe how to define your own environment variables in main.js when the builder is vite.
|
I noticed that my .env variables for my associated application generated with create-react-app still work. So now anything I need in storybook I just prepend with |
Running Storybook 7.0.12 with CRA , using a variable to read an environment value is not working.
|
I'm having the same problem as @inxsvf; it makes storybook unusable since I'm dynamically accessing the env variables. Is there a fix or workaround? |
Validating with zod also doesn't work. import { z } from 'zod';
const envVariables = z.object({
REACT_APP_API_ENDPOINT: z.string().url(),
// ... more vars to validate
});
envVariables.parse(process.env); // this fails |
Will this ever be worked on? Should be a simple fix to allow dynamic access 😐 |
I'm pretty sure it's due to these changes: https://github.com/storybookjs/storybook/pull/17174/files |
Following the above changes, I was able to retain dynamic environment access: // main.ts
import type { StorybookConfig } from '@storybook/react-webpack5';
const config: StorybookConfig = {
[...],
env: (config) => ({
...config,
STORYBOOK_ENVS: JSON.stringify(config),
}),
};
export default config; // environment.ts
function getEnv<IsOptional extends boolean = false>(
name: string,
isOptional?: IsOptional
): Env<string, IsOptional> {
let environment: Record<string, unknown>;
if (process.env.STORYBOOK === 'true') {
assert(
process.env.STORYBOOK_ENVS !== undefined,
`Missing required environment variable: STORYBOOK_ENVS`
);
environment = JSON.parse(process.env.STORYBOOK_ENVS);
} else {
environment = process.env;
}
const processValue = environment[`REACT_APP_${name}`];
const windowValue = (window as any)[name];
const value = processValue || windowValue; // prefer local development override
if (!isOptional) {
assert(
value !== undefined && value !== `$${name}`,
`Missing required environment variable: ${name}`
);
}
return value;
} |
Confirming issue with Storybook 6.5.16 and 7.4.0. My temp workaround is to set whatever I need in module.exports = {
// ...
env: config => ({
...config,
REACT_FOOBAR: "whatever"
})
}; |
Not sure, if this will help anyone, but instead of using |
@cherouvim |
Describe the bug
At runtime, inside of a story, we need access to a (subset of) process.env to pass some values from the buildserver onto Storybook, and ultimately the application proper.
In Storybook 6.4.9 this worked fine.
In Storybook 6.4.10 this got broken.
process.env
is now{ }
.In Storybook 6.4.14 this is not fixed, unfortunately.
Neither env variables from the CLI are passed, nor variables from
.env
. We use both, and neither end up inprocess.env
.Is it possible that #17174 broke this? That one is the only fix that remotely seems to have anything to do with
process.env
, assuming the changelog is complete.To Reproduce
I'm not sure what has been done to get this to work in the first place, or whether this is standard functionality. I do see
dotenv
being exported frompaths.js
, but it's really difficult to dig into Storybook to see what it's doing with that, if anything.System
The text was updated successfully, but these errors were encountered: