Skip to content
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

Core: Add multiple DefinePlugin support for process.env #13949

Closed
wants to merge 3 commits into from
Closed

Core: Add multiple DefinePlugin support for process.env #13949

wants to merge 3 commits into from

Conversation

7rulnik
Copy link
Contributor

@7rulnik 7rulnik commented Feb 18, 2021

Problem

Current storybook behavior is overriding the whole process.env. I'm trying to use it with https://github.com/7rulnik/isomorphic-env-webpack-plugin and it doesn't work because process.env already replaced by the storybook. So for now it's possible to find DefinePlugin in webpackFinal and replace definitions by hand.

What I did

Currently DefinePlugin has definiton like this:

{
  'process.env': {...}
}

After this PR DefinePlugin will have:

{
  'process.env.FOO': 'FOO_VALUE',
  'process.env.BAR': 'BAR_VALUE',
}

How to test

  • Is this testable with Jest or Chromatic screenshots? — No
  • Does this need a new example in the kitchen sink apps? — No
  • Does this need an update to the documentation? — No

Currently, we have a custom snapshot serializer that outputs only plugins names.

But it should possible to set any env variable like before and override some env that doesn't set by pushing DefinePlugin in webpackFinal.

Copy link
Contributor

@phated phated left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you do this without adding the dependency? I still have to check with the others to see if this is something we want, but adding the dep is probably a no-go.

@7rulnik
Copy link
Contributor Author

7rulnik commented Feb 18, 2021

@phated I added lodash only because there are already several packages in storybook that use lodash as a dependency.

Thit is yarn why from my project:

├─ @storybook/addon-actions@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-actions@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-actions@npm:6.1.17 [6ab0e]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-actions@npm:6.1.14 [81f85]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-docs@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-docs@npm:6.1.17 [6ab0e]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-knobs@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/addon-knobs@npm:6.1.14 [81f85]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/api@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/api@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/api@npm:6.1.17 [6ab0e]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/api@npm:6.1.14 [74efa]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/client-api@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/client-api@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/client-api@npm:6.1.17 [6712e]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/client-api@npm:6.1.14 [74efa]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/codemod@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/components@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/components@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/components@npm:6.1.17 [6712e]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/components@npm:6.1.14 [74efa]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/csf@npm:0.0.1
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/react@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/react@npm:6.1.14 [81f85]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/source-loader@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/source-loader@npm:6.1.17 [1955f]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/ui@npm:6.1.14
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/ui@npm:6.1.17
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/ui@npm:6.1.17 [71976]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)
│
├─ @storybook/ui@npm:6.1.14 [bf7a3]
│  └─ lodash@npm:4.17.19 (via npm:^4.17.15)

But if you insist, I can refactor it

Copy link
Member

@shilman shilman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does this PR do? Storybook strips out the contents of process.env because if we don't it's a massive security problem since the contents get bundled into your webpage and served out to the entire internet. If you are only using your Storybook on your dev machine or on a secured network, or on "safe" machines without any sensitive environment variables set, I could imagine an opt-in "dangerous" mode. But never as Storybook's default behavior.

@7rulnik
Copy link
Contributor Author

7rulnik commented Feb 20, 2021

@shilman it doesn't leak variables. Let me explain:

Our source content:

// src.js
console.log(process.env.BAR)
console.log(process.env.FOO)

The current behaviour of storybook close to this:

new webpack.DefinePlugin({
	'process.env': {
		bar: 'bar_value',
		// some others value
	}
}),
// dist.js
console.log(({"bar":bar_value}).BAR)
console.log(({"bar":bar_value}).FOO)

With this PR not defined env variables will be untouched:

new webpack.DefinePlugin({
	'process.env.BAR': 'bar_value',
	// some others value
}),
// dist.js
console.log(bar_value)
console.log(process.env.FOO)

So it makes possible use several DefinePlugins

Before this PR:

new webpack.DefinePlugin({
	'process.env': {
		bar: 'bar_value',
		// some others value
	}
}),
new webpack.DefinePlugin({
	'process.env': 'some_global_variable_that_stores_values'
}),
// dist.js
console.log(({"bar":bar_value}).BAR)
console.log(({"bar":bar_value}).FOO)

After this PR:

new webpack.DefinePlugin({
	'process.env.BAR': 'bar_value'
}),
new webpack.DefinePlugin({
	'process.env': 'some_global_variable_that_stores_values'
}),
// dist.js
console.log(bar_value)
console.log(some_global_variable_that_stores_values.FOO)

And now I can set variables in runtime by modyfing some_global_variable_that_stores_values.

@shilman
Copy link
Member

shilman commented Feb 20, 2021

@7rulnik Thanks so much for the clarification!! 🙏

@shilman shilman added the bug label Feb 20, 2021
@shilman shilman changed the title fix: don't replace all process.env Core: Add multiple DefinePlugin support for process.env Feb 20, 2021
7rulnik and others added 3 commits February 25, 2021 18:50
# Conflicts:
#	lib/builder-webpack4/src/preview/iframe-webpack.config.ts
#	lib/core-server/src/manager/manager-webpack.config.ts
@ndelangen
Copy link
Member

@7rulnik some refactors happened in the storybook core, and I want to help out bring this PR back in shape, but I do not have access to push to it, could you enable this option?

@ndelangen ndelangen mentioned this pull request Mar 11, 2021
@7rulnik
Copy link
Contributor Author

7rulnik commented Mar 11, 2021

@ndelangen I can't allow edits by maintainers because it's a repo in the organization, not mine, I guess. So I sent an invite to the repo for you.

Also, I'm not sure that #14203 does the job. Why do you think it's breaking change?

@ndelangen
Copy link
Member

Why do you think it's breaking change?

@7rulnik because people might have enumerated over process.env; or people might destructure off it..

Also, I'm not sure that #14203 does the job

What makes you think that?
This should ensure that both process.env get replaced (as it was), AND things like process.env.FOO get replaced too?

Perhaps we should add an option so users can choose between replacing:

process.env.FOO

vs

process.env

vs

FOO

That way replacing process.env can be opt-out. WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants