Compiling in production fails silently and isn't verbose enough

[ameft]

I have a Rails 5.2 app with Webpacker 4.0.0.pre.3 with runs smoothly in development and instead couldn't compile in production: [Webpacker] Compiling… just hanged there for hours (locally and on Heroku, where @schneems helped me a lot), in a similar way as described in #1534, #1217 and #1003.
After many hours of testing and research I found out that the problem was that two dependencies in package.json (@fortawesome/fontawesome-free and expose-loader) were in devDependencies instead of dependencies, that made compiling failing silently.
Running this command put me on the right path to find the solution, giving me some hits of errors NODE_ENV=production ./bin/webpack --progress --config config/webpack/production.js.
Problem is that instad running RAILS_ENV=production NODE_ENV=production bundle exec rails assets:compile didn't give me any indication of errors, and I don't know why but shouldn't be the case.
What do you think?

[jakeNiemiec]

FontAwesome did a writeup on this known issue. Issue terser/terser#50

There is a merged webpacker PR to fix this #1719 #1816 (comment)

[ameft]

Thank you @jakeNiemiec, I don't know if also my issues are related to uglify-es, but Webpacker should return some kind of error in any case I'd say.

[jakeNiemiec]

It's not that Webpacker is erroring out, uglify is incorrectly trying to minify all of the FA glyphs & exports. In other words, it's trying to do an impossible amount of work (memory & cpu wise). This is an issue that is just as hard to diagnose with vanilla webpack.

[ameft]

@jakeNiemiec are you sure that that is what it's happening? Why moving the libraries from devDependencies to dependencies should fix that? Compiling with ./bin/webpack was giving me errors, but Webpacker didn't.
EDIT: I didn't have problems with long compiling times in reality, I think. I had problems with compiling errors not being reported and not halting the process.

[gauravtiwari]

Yeah, we should fix this. Thanks @ameft for reporting. Please feel free to make a PR

[jakeNiemiec]

@ameft Sorry, my mistake, I conflated some of the issues you pointed to with what you were saying. Now my understanding is: FA was in devDeps when it needed to be in deps and webpacker did not alert you to this error.

It looks like webpacker is configured correctly to display errors:
https://webpack.js.org/configuration/stats/#stats

webpacker/package/environments/production.js

Line 34 in 8d496a0

stats: 'normal',

webpacker/package/environments/development.js

Line 43 in 227661b

errorDetails: true

You should also be able to pass custom settings to ensure errors are being displayed. Here is what I am currently using:

  stats: {
    errors: true,
    errorDetails: true,
    colors: true,
    optimizationBailout: true
  }

Edit: @ameft if you wanted to make the PR, I think adding back the line that this commit removed might solve this problem: #483. (errorDetails should be shown with or without the devServer running )

[ameft]

I'll try the stats config and to revert the fix to see if the errors are displayed, thank you @jakeNiemiec!

[gauravtiwari]

@jakeNiemiec I think the issue here is Open3 is hanging for some reason when there is error returned from the shell command. I am looking into alternatives but if someone has ideas feel free to make a PR.

[schneems]

A thing I've had to recommend fairly frequently is to manually run ./bin/webpack --progress.

Can we make this the default output mode of webpacker? Any other documentation or tips on debugging hung or really slow compiles is appreciated.

[jakeNiemiec]

@schneems If you also add --profile, this will give you some insight into where the bottlenecks are:

We use a progress plugin that does this on every build, here is one that a lot of (react/vue/angular)-cli libraries use: https://www.npmjs.com/package/simple-progress-webpack-plugin#minimal

[acrewdson]

+1 to what @schneems said above with respect to making --progress the webpacker default

[masato-hi]

I do not know about that no error output will occur, but this is maybe related #2143

[rossta]

@ameft Can this issue be closed and, if so, could you close it? Thank you!

[ameft]

@rossta I can of course close the issues, but it's not entirely clear to me if now webpacker behaves differently if it encounter certain errors during compiling. I didn't had any more issue on my part but I don't know if the original issue is actually addressed or maybe it's not a real issue to begin with...

[rossta]

@ameft Ah, thanks for pointing that out.

It's my understanding that Webpacker suppressed the compilation output in the version associated with this issue (Webpacker 4.0.0.pre.3 from the description).

Since 4.1.0 with this PR #2224, Webpacker will now print the compilation output to STDOUT by default though this behavior can be disabled in webpacker.yml

webpacker/lib/install/config/webpacker.yml

Line 9 in ac93e12

webpack_compile_output: true

.

[ameft]

@rossta amazing thanks! Issue closed :)