mrsteele
DefinePlugin and `dotenv-webpack` conflict
I use a shared webpack.config.js among projects and it uses the DefinePlugin to write some variables during build time - including process.env.NODE_ENV. I would also like to use dotenv-webpack so projects using the shared config can supply a .env for build time as well. If I use both plugins, however, I receive the error:
WARNING in DefinePlugin
Conflicting values for 'process.env'
I can make sure in DefinePlugin that process.env isn't used - except in some cases I need to write process.env.NODE_ENV at build time.
Instead, it would be preferable that dotenv-webpack simply merge with an existing process.env from DefinePlugin and overwrite any conflicts within.
This is a pretty convoluted problem, anyone have any ideas in particular to address this?
Perhaps:
new webpack.DefinePlugin({
'process.env.something': '"true"',
...(new DotenvPlugin().definitions)
})
To simply spread the results? I'm not at my computer so not sure if this is totally accurate but hopefully you can follow what I'm thinking.
Having this issue as well, it seems to be caused by the stub for me, as I'm getting the following when I show stats details:
WARNING in DefinePlugin
Conflicting values for 'process.env'
'"MISSING_ENV_VAR"' !== '{... big list of my env vars ...}'
@Yonben you might want to see what you have configured for your webpack config, primarily the target property. We stub sometimes and other times we don't. We also need to be careful not to double-up according to this error message on what variables are already used (hence my comment above)
@mrsteele I get it without using DefinePlugin on our testing CI. we do have this config for testing:
const { merge } = require('webpack-merge');
const productionConfig = require('./webpack.production');
module.exports = merge(productionConfig, {
optimization: { nodeEnv: 'testing' },
});
Has anyone found a solution to this issue? I am not using DefinePlugin only webpack Dotenv which is supposed to manage DefinePlugin automatically (if my understanding is correct):
plugins: [
new Dotenv({
systemvars: true
})
]
Mind sharing more context? How you are accessing your env variable and your file structure for instance usually helps.
When I need to use the variables in the .env file with the --env variable that comes with webpack, I don't have a good way.
Now I have to write webapck env into process.env first and then enable systemvars, But I don't think it's appropriate.
I want the following：
// execute
npm run serve -- --env custom=1
// webpack.conf.js
module.exports = (env) => {
console.log(env.custom) // 1
return {
plugins: [
new DotenvPlugin({
// I would like to have a configuration like this
// It takes precedence over configuration in process.env and configuration in .env
extralEnv: {...env}
})
]
}
}
@ywymoshi that explains it well, is that the same problems others were facing?
Any solution yet? This can be really annoying on development using watcher.
@typoworx-de a couple of solutions above, it sounds like a few solutions work descent for others.
Of course I’d be curious to see this supported with a first party solution, I’m just too detached from the issue to test well. Do you have an idea for a solution?
I can try to get to the update proposed above maybe later this month. I have a lot of personal things going on so I can’t make any promises. Of course I’m always open to someone opening a PR themselves if they need it sooner.
I just opened a PR #497. Would you mind taking a look and seeing if something like that would help in your scenario?
The idea is you would add { force: true } in your config object to make sure your variables take precedence over anything that pre-exists.
Found this solution and it seemed to work for me, no more conflicting values for process.env https://stackoverflow.com/questions/67431401/conflicting-values-for-process-env-with-webpack-encore-and-dotenv
@typoworx-de a couple of solutions above, it sounds like a few solutions work descent for others.
Of course I’d be curious to see this supported with a first party solution, I’m just too detached from the issue to test well. Do you have an idea for a solution?
Hey there @mrsteele sorry I've been (and being) busy in daily business as developer. As there was no reaction long time I somehow had cope with the problem. I had no real solution for it so I've had to do things done to get the project ready.
If there's a good solution I'm looking fordward to use it in a next project I may have this setup.
Sounds like the “ignoreStub” option would be your best bet. I’m going to close this assuming that solves your problem.