Why do we build main-process related scripts via webpack and not use them as it?

[alexstrat]

I started my project with this boilerplate (thanks!) and, as I added more main-process specific dependencies, like others (#524, #385 for example), I ran into complications with webpack bundling.

I've managed to get out of trouble by tweaking the webpack.config.electron.js but it was always painful, even more because this type of errors appends only after packaging and not during development.

These are drawbacks of bundling main-process related scripts with webpack, what are the advantages that motivates this choice?

[alexstrat]

(I bumped into #541 and realized it can make things easier)

[amilajack]

Can you be more specific about the kinds of issues you were facing?

[jhen0409]

These are drawbacks of bundling main-process related scripts with webpack, what are the advantages that motivates this choice?

Early discussions: #139 #197

1. It's an option for use babel in production of main process.
2. For package, we can reduce a lot of package size, leaving only allow list. (in app/)
3. Webpack advantages (e.g. dead code elimination)

[alexstrat]

@amilajack to be a bit more specific, I have had issue with googleapis that I did not treat as native dependency like instructed in the README and with form-data (#385) required by node-segment.

@jhen0409 thanks, these were the answers I was looking for.