Electron-forge: [6.x] Add Webpack rules per environment basis (using the Webpack template)

Created on 2 Jun 2019  路  9Comments  路  Source: electron-userland/electron-forge

  • [x] I have read the contribution documentation for this project.
  • [x] I agree to follow the code of conduct that this project follows, as appropriate.
  • [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Please describe your issue:

I've setup a small project using electron-forge, version 6. I've added css-loader, style-loader and mini-css-extract-plugin to my project in order to import css files and resolve them properly.

However, style-loader is only relevant in development and the mini-css-extract-plugin is only relevant in production. Since I only have one entrypoint per process, how do I separate configuration between environments?

According to the documentation, I shouldn't need to care, but in this case I do need to care. Is there any example or guidelines for how one go about adding environment specific options using the Webpack template?

Enhancement Help Wanted webpack

Most helpful comment

@MarshallOfSound thanks for the quick response.

Heh, well put 馃挴 If the webpack plugin set process.env.NODE_ENV to production while loading your config for prod packaging would that suit your use case?

I'm not entirely sure what you're saying here. Are you asking me if using process.env.NODE_ENV would be enough if it reflected the current environment? If so, the short answer is yes.

No, that behavior is specific to the webpack cli rather than the webpack API that we consume.

I see. Would it be of interested supporting the behavior? It would align nicely with how Webpack currently works and make the transitions easier for people already using it. I'd be up for helping out with a pull request if we decide to move forward with that approach. 馃檪

All 9 comments

Looking through the Webpack documentation, you can export a function instead of an object. See https://webpack.js.org/configuration/mode/. This would allow me adding loaders/plugins on a per-mode basis. Is this compatible with the webpack plugin?

According to the documentation, I shouldn't need to care, but in this case I do need to care

Heh, well put 馃挴 If the webpack plugin set process.env.NODE_ENV to production while loading your config for prod packaging would that suit your use case?

Is this compatible with the webpack plugin?

No, that behavior is specific to the webpack cli rather than the webpack API that we consume.

@MarshallOfSound thanks for the quick response.

Heh, well put 馃挴 If the webpack plugin set process.env.NODE_ENV to production while loading your config for prod packaging would that suit your use case?

I'm not entirely sure what you're saying here. Are you asking me if using process.env.NODE_ENV would be enough if it reflected the current environment? If so, the short answer is yes.

No, that behavior is specific to the webpack cli rather than the webpack API that we consume.

I see. Would it be of interested supporting the behavior? It would align nicely with how Webpack currently works and make the transitions easier for people already using it. I'd be up for helping out with a pull request if we decide to move forward with that approach. 馃檪

I had the same issue, but I simply solved it by using:

const isProd = process.env.NODE_ENV === 'production';
...
isProd ? MiniCssExtractPlugin.loader : 'style-loader',

and then modifying package script like this

"package": "cross-env NODE_ENV=production electron-forge package",

Of course it would be nice if webpack plugin would set NODE_ENV variable

There's other benefits to indicating production vs development. The most recent version of webpack uses a "mode" flag (see https://webpack.js.org/configuration/mode/) which runs some good optimizations based on the environment.

This can greatly impact the performance of a production app and is pretty much the only reason I use webpack.

I think some of the plugins it mentions like the TerserPlugin are really important to configure well as well.

In our case, we're migrating a Webpack web app to be an Electron Windows app. Our previous webpack config had something like this:

module.exports = env => {
    env = env || {};

    const OAUTH_URL = env.OAUTH_URL;
    ...
};

and then we would invoke Webpack like so:

webpack serve --env OAUTH_URL='...'

This allowed us to configure the app was we were compiling it.

Ah, looks like there's already a pull request for this: https://github.com/electron-userland/electron-forge/pull/1556

Yeah. Manually setting mode: 'production' in webpack.renderer.config.js doesn't do anything.

Neither does setting the flags in package.json:

    "package": "cross-env-shell NODE_ENV=production electron-forge package",
    "make": "cross-env-shell NODE_ENV=production electron-forge make",

I'm really not sure why and I'm starting to regret not choosing a different electron build toolchain.

Yeah. Manually setting mode: 'production' in webpack.renderer.config.js doesn't do anything.

Neither does setting the flags in package.json:

    "package": "cross-env-shell NODE_ENV=production electron-forge package",
    "make": "cross-env-shell NODE_ENV=production electron-forge make",

I'm really not sure why and I'm starting to regret not choosing a different electron build toolchain.

FYI: Setting an environment variable the way you are doing with cross-env worked for me. NODE_ENV is indeed set correctly and can be read from webpack config files.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Skizu picture Skizu  路  5Comments

mistermicheels picture mistermicheels  路  4Comments

chenzhiguo picture chenzhiguo  路  5Comments

noahott picture noahott  路  5Comments

kzimny picture kzimny  路  3Comments