Packaging succeeds despite Webpack compilation errors

[tgds]

• [ 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:

If Webpack compilation has errors (e.g. due to typescript compilation), both electron-forge start and electron-forge package scripts succeed without any warnings.

In case of electron-forge package, no files are emitted as noEmitOnErrors plugin is set up.
The command should fail and display the errors.

For electron-forge start, files are emitted as they should be, but the webpack compilation errors should be displayed.

Here's a repo with the setup: https://github.com/tgds/electrong-forge-webpack-typescript

[nphias]

ok great so that would be perfect.. when we package and create installers using electronforge we also have the source webpacked.. Right now, when I look at the contents of my app under Resources->app i get the node modules and the src files exactly as they were in my IDE.. we dont want this.. we want it all webpacked..
if electron-forge wont / cant do this then we will have to look at this project instead:
https://github.com/lbassin/electron-angular-webpack

(it also does packaging and installers)

[tgds]

@malept what do you imagine would be the ideal UI to show Webpack errors and warnings in development?

Looking at plugin/webpack/src/WebpackPlugin.ts(283), where is tab.log intended to end up logging to?

const cb: webpack.ICompiler.Handler = (err, stats) => {
          if (tab) {
            tab.log(stats.toString({
              colors: true,
            }));
          }

          if (err) return onceReject(err);
          onceResolve();
        };

[malept]

This is more of a question for @MarshallOfSound .

[MarshallOfSound]

@tgds WebPack compiler output is sent to a web logger, when you run electron-forge start it should log a localhost:XXXX url where you can see all the webpack logs nicely. We can't just send them to the terminal as we run multiple webpack compilers

[G-Rath]

I think (based on my understanding on the comments on this issue, which could be wrong - feel free to correct me) that this issue might have jumped the gun a bit, in thinking about how/what to log where from Webpack.

For me, this biggest thing about this issue is firstly the fact that electron-forge continues regardless on if either of the webpack compilers fail.

Secondly, it seems weird that you couldn't output a message saying "Failed to compile Main Process Code", as I have the following in my terminal:

√ Checking your system
√ Compiling Main Process Code
√ Compiling Renderer Template
√ Preparing to Package Application for arch: x64
√ Preparing native dependencies
√ Packaging Application

Note how it says "√ Compiling Main Process Code" followed by √ Compiling Renderer Template, which to me indicates the progresses are being run in series, one after the other, and is where I'd expect to see messages & the command stopping should one of the compiling processes throw an error.

Instead, what I get is main and renderer folders possibly not existing, but otherwise no sign of error (aside from the application not starting).

In regards to what you said @tgds about the web-logger: For me this doesn't work - I get 404 errors when I navigate to that site, and it doesn't happen anyway when you're using package, so I'm not sure how you're meant to see the build log for electron-forge package.

A nice middleground for me in the interim would be if electron-forge had an option to write the output of webpack compiles to a .log file, where I could manually inspect them.

I've just spent a lot of time on this issue, having problems getting things to compile, as I can't actually see the problems typescript is having, since the output from ts-loader is swallowed by electron-forge.

Sorry if I've caused any confusion - I'd love to help to this sorted, so let me know if I should make any new issues or adjust my comments :)

[ghost]

The webpack plugin can start and fail, leaving you with this

Webpack Output Available: http://localhost:9000

Error launching app
Unable to find Electron app at /path/to/app

Cannot find module '/path/to/app'

and by the time you get there, the http server has already closed itself out, so you don't even know if you're say.. missing ts-loader. I couldn't get my app to start, because I didn't know enough about webpack to know I needed it. I had to use @tgds's example repo to find out.

NOTE: I'm only using webpack at all because electron-compile seems unmaintained.

[tgds]

thanks, @MarshallOfSound !!

[G-Rath]

@MarshallOfSound should we make a separate issue to cover the situation highlighted by @jrobeson?

In a nutshell: if something causes webpack-plugin to error out, we can't view the webpack logs as they're not written to file anywhere, and the log server is closed before it's accessible.

[MarshallOfSound]

@G-Rath Can you open a new issue specifically for getting webpack logs when the app quits / crashes / fails to start. Not sure what the solution would look like but would be good to track it

[tgds]

One more question, if I may, @MarshallOfSound. Maybe it warrants discussion in a new issue, but how do you imagine strategy around using native modules and Webpack plugin?
Just had to use one and couldn't find an obvious way, so I worked around it by setting it up as an external module in webpack config and copying the module in afterCopy hook to buildPath's node_modules dir.
Happy to try and tackle it in a PR

[malept]

@tgds see #703

[MarshallOfSound]

@tgds This was opened yesterday --> #703

I hacked a bit on it last night, it's a tough one to solve, I think I'm on a track to a generic enough hack though that might work 😆

It's tough to solve without externals (and I really want to avoid using externals as it defeats the purpose of bundling all JS)

[G-Rath]

@MarshallOfSound I've created #705 for this.

I think my original issue might be have been fixed - I'm at work, so I can't really test everything, but if ts-loader does error, I can access enough of the webpack logs, but it's also quite possible I've forgotten about some situation or another where this behaviour happens for me 😕

Either way, I still think it's a valid issue, and a good one to at least have tracked 😄