Adding a new loader to webpack config about electron-webpack

[SimulatedGREG]

Okay, so I've been playing around with adding custom loaders/plugins via modifying the provided webpack configurations. The only problem of course is once I create a custom configuration, I lose yarn dev handling the electron process.

Here is an example of adding the raw-loader to the renderer process for those that are interested.

const webpackRenderer = require('electron-webpack/webpack.renderer.config.js')

module.exports = env => {
  return new Promise((resolve, reject) => {
    webpackRenderer(env).then(rendererConfig => {
      rendererConfig.module.rules.push({
        test: /\.txt$/,
        use: 'raw-loader'
      })

      resolve(rendererConfig)
    })
  })
}

And then running with webpack...

webpack --config myCustomWebpack.renderer.config.js

---

So all that to say, would it be worth adding an option to point to a custom webpack config, that way yarn dev & yarn compile are aware? So something like...

"electronWebpack": {
  "renderer": {
    "webpackConfig": "myCustomWebpack.renderer.config.js"
  }
}

[SimulatedGREG]

I’d say both programmatic and declarative would be beneficial. I personally would prefer programmatic.

[SimulatedGREG]

Okay, so I think I may have a nice approach to this, which would also simplify the process. I propose that you can define a path to a custom webpack configuration with an electronWebpack option (just like I mentioned before), but the difference now being that you actually provide a raw configuration with only the needed modifications. Then electron-webpack can internally use webpack-merge with its own configuration and the custom one. This would eliminate the need to require each needed configuration manually, and provide a very developer-friendly experience as the full webpack API would still apply.

---

webpack.modded.renderer.js

module.exports = {
  /* your raw webpack modifications */
}

package.json

{
  "electronWebpack": {
    "renderer": {
      "webpackConfig": "webpack.modded.renderer.js"
    }
  }
}

With this setup, electron-webpack will internally apply your custom modifications.

[develar]

1. Core package is not bloated because nunjucks-loader and nunjucks only detected, but not required by electron-webpack. Not listed as dependencies or peerDependencies. User must install it in own project if need.
2. " I'll have to wait to have a new loader added officially" That's why this issue is not closed :) No doubt — ability to configure loaders should be added.

[develar]

On another note, what about support for a separate config file, like a electronWebpack.json

Feature was added recently, but not documented. electron-webpack.yml or electron-webpack.json5 or electron-webpack.json

[loopmode]

Sounds good to me, especially in the context of adding loaders.

Once in place, we could think about how to support https://github.com/survivejs/webpack-merge#merging-with-strategies

[develar]

Thanks to @SimulatedGREG, this feature implemented in the 1.9.0 (it is prerelease, will be latest after confirmation that it works and no regressions). https://webpack.electron.build/modifying-webpack-configurations

[develar]

I will add easy way to add loaders today/tomorrow.

For now, you can use programmatic API — simply modify provided configuration files according to your needs. Please see #5 (comment)

[develar]

electron-webpack 1.1.0 — nunjucks is auto supported.

After yarn add nunjucks-loader nunjucks --dev required loader will be added automatically.

[ashokgelal]

I appreciate you adding support for nunjucks loader but I don't think adding it to core the right approach. There are couple of issues with doing this way: the core package gets bloated, I'll have to wait to have a new loader added officially, and less freedom on configuring the loaders that come supported out of the box.

It would be nice to allow passing a config file similar to what Laravel Mix does. This way we can configure webpack to our hearts content and still get to use your awesome package.

[develar]

I am going to support declarative way. In the electronWebpack object in the package.json or separate file, will be new option to configure loaders.

Do you prefer programmatic way or declarative?

[develar]

You can use programmatic —

require("electron-webpack").getAppConfiguration(env)

or other methods (see provided configuration files).
Or require provided configuration file, of you want.

And modify webpack configuration as you want.

I am not sure, that we need to add build-style "easy" programmatic way. Probably if you want programatic, it will be better to not introduce another wrapper.

Ok, ok, I will look what Laravel Mix does anyway (as my working language is Kotlin, build-style is a little bit arhaic for me, DSL is better).

[SimulatedGREG]

True. And as another note, I don't think adding loaders into electron-webpack directly may be the best approach. Sure you can easily drop in support for more loaders as people request, but then what happens when somebody needs a specific configuration of a loader? I don't see how all cases could ever be supported.

I think proper documentation, with a few examples, of how to add more loaders would be very beneficial. Going to add to my list.

[develar]

but then what happens when somebody needs a specific configuration of a loader

If added configuration by auto-detection is not suitable, explicit usage of declarative way should be used (#11 (comment)).

[SimulatedGREG]

Yeah, and I would agree with that. I should have a lot of time today to flesh this out in words for the docs.

PS: Do you have another way of communication? Maybe Discord? So that I can talk with you directly.

[develar]

@SimulatedGREG electron-builder slack (direct messages to develar) — https://slackin.electron.build/

[ashokgelal]

Agree to pretty much everything with what @SimulatedGREG said. Cannot emphasis more on how proper documentation with few examples on how to add/configure more loaders would be extremely helpful.

[SimulatedGREG]

@ashokgelal I'm working on a checklist of things to mention in the docs. Feel free to comment any topics you might suggest. :)

#8 (comment)

[ashokgelal]

@SimulatedGREG I'm using this package with your great electron-vue boilerplate scaffolding generator (cannot thank enough for the numbers of hours you have saved me), I've come across a few things where I wish I had access to better documentation. Some of them are not directly related to this package or your package directly but still. If you don't mind I can dump them as I come across and you can choose whether to include it to document or not.

[SimulatedGREG]

@ashokgelal Feel free to suggest anything inside SimulatedGREG/electron-vue#372

[develar]

Final proposal:

option moduleRules in the ElectronWebpackConfiguration (root) and in the PartConfiguration (main and renderer).

moduleRules?: Array<Rule> | Rule where rule is just a webpack Rule.

So, to add nunjucks-loader:

"electron-webpack": {
  "moduleRules": {
    "test": /\.(njk|nunjucks)$/,
     "loader": "nunjucks-loader"
    }
}

Not yet clear is webpack can handle regexp as string or is regexp allowed in the yaml/json5 (if you use external config file). But it is doesn't matter.

[SimulatedGREG]

This could work for simpler needs, but there will always be a need for the programmatic approach. I think once documentation on that is complete, it would be easier to determine whether or not this will be necessary to support.

On another note, what about support for a separate config file, like a electronWebpack.json? I know not everybody prefers to have configurations inside of package.json.

[SimulatedGREG]

Oh awesome. I'll note that.

[develar]

As far I see, Laravel Mix does exactly what electron-webpack does and I already suggest for users — https://github.com/JeffreyWay/laravel-mix/blob/master/docs/faq.md#how-might-i-manually-add-coffeescript-compilation

Less magic — better for users. No one need yet another sexy API around webpack. Nothing can be more simpler then

 module: {
            rules: [
                { test: /\.coffee$/, loader: 'coffee-loader' }
            ]
        }

So, we need just document how to modify provided configurations. And I don't recommend to use electron-webpack main export for this purpose. Better to await require("electron-webpack/webpack.renderer.config.js") where webpack.renderer.config.js it is wanted configuration file. In our test code we also doesn't use electron-webpack internal API.

[develar]

But as since we provide yarn dev command, electron-webpack should be aware what configuration file to use to compile app/main/renderer.

I think, indeed, moduleRules option will open Pandor's box. I definitely don't want to complicate electron-webpack. Today user needs module.rules, tomorrow user will want something else. No doubt — it doesn't mean that we will not provide declarative way to configure something, but in this case nothing to simplify. User just need to specify loaders and this configuration is straightforward.

So, instead, we should just add option webpackConfiguration to main and renderer objects of config (PartConfiguration). So, electron-webpack dev command and composite configuration webpack.app.config.js will check these options.

[FantasticFiasco]

I'm opting to use Sass and guess I will have to configure Webpack into using the sass-loader. This is a guess from my part since I'm pretty new to frontend development.

I'll wait for the next release and see if I can figure out how to configure Webpack.

[RyanMelenaNoesis]

Would it be possible to allow some declarative configuration or convention by which we could define a callback function that can modify the default webpack configuration before executing the build process? It seems that would allow for the flexibility to perform any kind of configuration modification while still allowing use of the electron-webpack cli, particularly electron-webpack dev. It would also avoid the need for creating a custom .config file(s) as @SimulatedGREG had to do because all the custom modifications could be done dynamically as part of the electron-webpack pipeline.

[AndreyWeber]

@SimulatedGREG you wrote above: "I lose yarn dev handling the electron process"

Let's say I've added custom renderer webpack config and I want to use

webpack --config myCustomWebpack.renderer.config.js

CLI command in some chain of other CLI commands to start electron in dev mode. Can you please provide example of scripts section of package.json showing usage of custom webpack config + benefits of electron-webpack dev mode?

Thank you.

[loopmode]

I like part of what @SimulatedGREG wrote:

// assuming this is package.json or electron-webpack.json etc
"electronWebpack": {
  "renderer": {
    "webpackConfig": "myCustomWebpack.renderer.config.js"
  }
}

However, i really don't like the heavyweight Promise approach for the config itself. Do we really need that?
I would prefer something like this for the configs:

module.exports = (config, env) => config

I personally would then break it down to more specific individual files:

// config/webpack/renderer.config.js:
module.exports = (config, env) => require(`./renderer.${env}.config`)(config);

// config/webpack/renderer.development.config.js:
module.exports = (config) => config;

// or:
const merge = require('webpack-merge');
module.exports = (config, env) => merge(config, require(`./config.${env}`));

// or even:
module.exports = () => require('entirely/different/config')

It leaves all kinds of options and personal preference to the user.

[SimulatedGREG]

@loopmode

If you want something a tad more lightweight, then you can use async/await. electron-webpack is built to be aware of what dependencies you are using. That means it will create a fresh webpack configuration every time, therefore this operation will always be asynchronous.

const webpackRenderer = require('electron-webpack/webpack.renderer.config')

module.exports = async env => {
  const rendererConfig = await webpackRenderer(env)

  /* your modifications */

  return rendererConfig
}

Or using webpack-merge

const webpackRenderer = require('electron-webpack/webpack.renderer.config')
const merge = require('webpack-merge')

module.exports = async env => {
  return merge(await webpackRenderer(env), {
    your: 'modifications'
  })
}

[loopmode]

I see. Also. the promise-based approach seems to be baked in already, so no reason discussing that :)

[loopmode]

Btw I tried the custom-config branch that @SimulatedGREG is working on, and I must say it works pretty well - however, currently only for the renderer bundles and not yet for the dll bundles.

Just clone the repo, switch to the branch custom-config, run yarn && yarn compile && yarn link, then yarn link electron-webpack in your project.

Then you can use a electron-webpack.json, specify the name of your custom config, and it gets merged nicely via webpack-merge. For example, I added raw-loader for some three.js stuff like this:

electron-webpack.json:

{
    "renderer": {
        "webpackConfig": "renderer.development.config.js"
    }
}

renderer.development.config.js:

module.exports = {
    module: {
        rules: [
            {
                test: /\.(frag|vert|obj)$/,
                use: 'raw-loader'
            }
        ]
    }
};

[loopmode]

What's the plan regarding merging https://github.com/electron-userland/electron-webpack/tree/feat/custom-config?
I've been using the branch in a real project for quite a while, and it works fine for both renderer and dll bundles (since 3a5bc76)

@SimulatedGREG you said in a chat you weren't too happy with the code itself, in terms of DRY principles. But functionally it seems to be working just fine. I suggest the branch should be merged, and improvements can be implemented later on in master. What do you think?

[SimulatedGREG]

Glad to hear you aren't having any issues. I've just unfortunately been busy with work. I'm planning to catch up on all my OSS work this weekend, so stayed tuned... 👀

[loopmode]

Awesome!

[funwithtriangles]

One issue I'm facing with this is that certain loaders aren't working because the file extension in the test has already been covered with the already included loaders. The specific issue I'm having is with an svg loader which is clashing with the test for the included url-loader.

The first workaround I tried using is to test for .icon.svg instead of .svg but it appears it was still overridden. I finally got it working by using .txt extensions instead.

[loopmode]

@funwithtriangles This is because the smart strategy is hardcoded at the moment.

As mentioned elsewhere, I think we need to be able to specify or override the merge strategy somehow. We just have to come up with a good and easy/robust way.

[mhuggins]

Does the promise format work with electron-webpack dev? It doesn't appear to. All the documentation says to use webpack directly, but how can I make that work with the dev command?

[UXDart]

is there anyway to do this last comment here? I want to change the config but still use electron-webpack... I see many issues about this, without any answer... is not possible...? Thanks