Comments (39)
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"
}
}
from electron-webpack.
I’d say both programmatic and declarative would be beneficial. I personally would prefer programmatic.
from electron-webpack.
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.
from electron-webpack.
- Core package is not bloated because
nunjucks-loader
andnunjucks
only detected, but not required by electron-webpack. Not listed asdependencies
orpeerDependencies
. User must install it in own project if need. - " 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.
from electron-webpack.
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
from electron-webpack.
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
from electron-webpack.
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
from electron-webpack.
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)
from electron-webpack.
electron-webpack 1.1.0 — nunjucks is auto supported.
After yarn add nunjucks-loader nunjucks --dev
required loader will be added automatically.
from electron-webpack.
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.
from electron-webpack.
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?
from electron-webpack.
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).
from electron-webpack.
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.
from electron-webpack.
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)).
from electron-webpack.
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.
from electron-webpack.
@SimulatedGREG electron-builder slack (direct messages to develar) — https://slackin.electron.build/
from electron-webpack.
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.
from electron-webpack.
@ashokgelal I'm working on a checklist of things to mention in the docs. Feel free to comment any topics you might suggest. :)
from electron-webpack.
@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.
from electron-webpack.
@ashokgelal Feel free to suggest anything inside SimulatedGREG/electron-vue#372
from electron-webpack.
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.
from electron-webpack.
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
.
from electron-webpack.
Oh awesome. I'll note that.
from electron-webpack.
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.
from electron-webpack.
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.
from electron-webpack.
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.
from electron-webpack.
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.
from electron-webpack.
@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.
from electron-webpack.
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.
from electron-webpack.
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'
})
}
from electron-webpack.
I see. Also. the promise-based approach seems to be baked in already, so no reason discussing that :)
from electron-webpack.
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'
}
]
}
};
from electron-webpack.
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?
from electron-webpack.
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... 👀
from electron-webpack.
Awesome!
from electron-webpack.
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.
from electron-webpack.
@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.
from electron-webpack.
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?
from electron-webpack.
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
from electron-webpack.
Related Issues (20)
- Fail to transpile other js files next to src/main/index.js file HOT 4
- rendering react-router-dom hooks cause hooks rules error HOT 3
- Custom webpack config gets into infinite loop HOT 5
- Sentry integration not working HOT 10
- electron-webpack dev not works for flash plugin HOT 1
- Question: Devserver disable
- electron-webpack issue on --env.production parameter HOT 1
- electron 13.x HOT 6
- Images not showing up in output folder HOT 1
- CSS Error: Unexpected Token
- Can you push update so there was support of Webpack 5? HOT 5
- Adding tailwind to Electron-Webpack HOT 1
- electron-webpack doesn't recognize my loader HOT 3
- NAPI Addon How it works in electron-wepack HOT 1
- Recommended migration strategies? HOT 3
- map file not server by webpack-dev-server HOT 1
- Segmentation fault on Windows 11
- Electron cannot be found after packaging??? HOT 2
- Update expo from 49 to 50 blank white page.
- Can you provide an Example with npm?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from electron-webpack.