dotenv-webpack: Unexpected token: punc (.)

I’m using a library which is relying on process.env[name] dynamically. So replacing with MISSING_ENV_VAR is not working.

I had to remove dotenv-plugin for @lid3rs solution adapted to bypass the syntax error:

const { config: configDotEnv } = require('dotenv');
const { DefinePlugin, ProvidePlugin } = require('webpack');
const dotenv = configDotEnv();

new ProvidePlugin({ process: 'process' }),
new DefinePlugin({
  'process.env': `(${JSON.stringify(dotenv.parsed)})`,
}),

@mrsteele do you think we could do this in dotenv-plugin instead?

@moroine a few things:

1. This is not on topic with the issue, and this issue has closed. Please open a new ticket if you would like to discuss.
2. If we kept all the envs, we are not really bundling envs anymore but stashing all of them which does not meet one of the plugin goals (Only bundle what you use for security purposes and bundle sizes like @sapkra mentions)

I would love to spend some time to resolve this immediately because of the challenge its posing, unfortunately things are busy at work and home.

I looked briefly for ways to look at the webpack config within the context of my plugin and I didn’t see anything obvious (though it should be there right?) If anyone has an idea/suggestion I’d recommend trying it out and submitting a PR.

Otherwise, it might be a matter of removing from the code and writing something in the README to explain how to polyfill for the browser when the ENV is empty and not breaking on the browser. If anyone could volunteer to help with that it would be greatly appreciated.

This has been on my thoughts the past few days, just can’t get enough time unfortunately to dedicate to it at the moment.

Curious on your thoughts about this: https://github.com/mrsteele/dotenv-webpack/pull/289

Essentially removes stubs, but makes the developer responsible for ALYWAYS referencing the variables. A little more strict but I think this would really help what you all may be running into.

If you are able to test it out, let me know. Essentially does what I suggested here but in your declaration configs.

working like a charm !

🎉 This issue has been resolved in version 7.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

@mrsteele The reason this started popping up is that for some reason specifically the {}.NAME stub stopped working. We had it in our config as well, then all of the sudden had to change it due to getting this error.

The problem seems to be specifically the {}. part, and changing it to be something like "ENV_VAR_NOT_FOUND". instead will make it work again!

I can attest that this is the current problem as right now we are using dotenv in dev mode which is breaking due to this error, but when we build for production we use our custom stub which works and does not error.

The exact config we’re using right now:

webpack.DefinePlugin({
  "process.env": '"ENV_VAR_NOT_FOUND"',
})

@martinjuhasz I had a look in my dependencies and searched for this code. It’s part of a file called node.js in a package called debug. I this error will only happen when webpack is trying to built something for node.

https://github.com/visionmedia/debug/blob/master/src/node.js#L205

In electron the debug package is a dependency of electron-download and electron-squirrel-startup in my case.

@thisVioletHydra You could try to set the env var in your environment. You can do this in your package.json script too.

Just double-checked this in my dotenv-webpack-example repo and I’m right about removing that line and causing unreferenced process.env variables to throw errors:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

How can i use this setting with new webpack 5? Everything worked with the old one, and the node did not swear at the lack of a certificate during development, and now I cannot even influence this parameter