kmui2
commented
6 years ago Have you tried including .env in the environmentHash?
Open dguayrobotiq opened 6 years ago
kmui2
commented
6 years ago Have you tried including .env in the environmentHash?
mzgoddard
commented
6 years ago Optimally dotenv-webpack would be reflected in the configHash. You can console.log sorted in defaultConfigHash.js if you want to find out what hard-source is hashing by default. Maybe there isn't enough detail about the DefinePlugin in the hash.
Beyond that hard-source cannot support this issue. configHash is the support mechanism and we can try to support that but a dynamic way to not cache DefinePlugin or dotenv-webpack is not possible because of how they work.
dguayrobotiq
commented
6 years ago @mzgoddard How can I add dotenv-webpack to the configHash? My webpack config looks like this:
plugins: [
new Dotenv({
systemvars: true,
path: path.join(__dirname, "../.env"),
}),
new HardSourceWebpackPlugin(),
],Have you tried including .env in the environmentHash?
Actually, this seems to be working !
johnculviner
commented
5 years ago Sure, but what if you aren't using .env for everything that might change across builds! (Like you have npm run start-XX, where XX targets a different API using env vars right before the command)
EX:
"scripts": {
"start-qa": "REACT_APP_ENV=qa npm-run-all -p watch-css start-js",This worked for me w/o any 3rd party libraries. Note the recommended node-object-hash didn't for some reason.
const util = require('util');
const crypto = require('crypto');
....
new HardSourceWebpackPlugin({
configHash: webpackConfig => crypto
.createHash('md5')
.update(
JSON.stringify(
util.inspect({
webpackConfig,
reactAppVars: Object.entries(process.env).filter(([name]) =>
name.toUpperCase().includes('REACT_APP')
),
})
)
)
.digest('hex'),
environmentHash: {
root: process.cwd(),
directories: [],
files: ['package-lock.json', '.env', 'package.json'],
},
....I really like this lib but I think something like the above should be talked about more in the docs (or even be the default) as this burned me pretty bad for awhile till I figured out what was happening.
alexeychikk
commented
5 years ago @johnculviner I think with this approach you lose any caching when you switch between different envs. I mean I have something similar that looks like this:
"test:e2e:ci": "npm run test:e2e:ENV_1 && npm run test:e2e:ENV_2 && npm run test:e2e:ENV_3"
And in webpack config I have something like this:
{
plugins: [
// ...
new webpack.EnvironmentPlugin({
PROJECT_NAME,
PROJECT_INTL,
PROJECT_REGION_INTL,
// ...
}),
new HardSourceWebpackPlugin(),
// ...
],
resolve: {
alias: {
"@projectImages": PROJECT_IMAGES,
"@projectIntl": PROJECT_INTL,
"@projectRegionIntl": PROJECT_REGION_INTL,
}
}
}Each different env changes values of PROJECT_NAME, PROJECT_INTL and PROJECT_REGION_INTL and because of this HardSourceWebpackPlugin writes new cache for each npm run test:e2e:ENV_X call.
It would be nice to be able to switch between envs without loosing caching possibilities but recomputing modules that rely on env.
Expected Behavior
Environment variables should not be cached.
Actual Behavior
Environment
Is an error being thrown?
No
Steps to Reproduce
.envfile and use it inEnvironment.js.webpack-serveyour websitewebpack-serve.envwebpack-serveOperating System, Node, and NPM dependency versions