Error messaging when running rake assets:precompile

[djforth]

When running rake assets:precompile if the compile has any issues you don't get any feedback or error messaging.

To give you a bit more info I had accidentally added a package to dev dependencies, so when I ran:

NODE_ENV=production rake assets:precompile

Because the compile step brings in fresh packages and if you specify NODE_ENV=production it won't include the devDependency (or doesn't seem too). The compile was failing because the package couldn't be found. This is fine except the compile step just hung no errors just said compiling...
When I eventually tried:

NODE_ENV=production ./bin/webpack

I realised what the issue was as all the error messages appeared.

What would be handy is if there are any errors in the compile it displays so you can pick up on them faster.

Also whether a way to disable fresh package import might be handy? I find if I compile locally for production I always have to re-install my dev packages. Something like:

NODE_ENV=production rake assets:precompile --no-install

Would be very handy.

[eliank]

Open3.capture3 captures all output, as expected, but since it doesn't return the output is never shown. I patched https://github.com/rails/webpacker/blob/master/lib/webpacker/compiler.rb#L59 so it calls Webpacker::Runner inline instead of using open3. This made the errors visible/fixable for us.

[kirillian]

This appears to be a bug (because all of the debugging information is on stdout instead of sterror, the latter of which is being printed), but an easy workaround (after MUCH searching for it) is to set the following key in your webpacker.yml:

webpack_compile_output: true

In my case, I was compiling assets for production, so it looked something akin to this:

production:
  <<: *default

  webpack_compile_output: true

[jakeNiemiec]

Relavent line:

webpacker/lib/webpacker/compiler.rb

Lines 79 to 81 in 195396f

	if config.webpack_compile_output?
	logger.info stdout
	end

I think there should be more logging, but there is strong disagreement over how much logging should be shown by default: #955 (comment)

[jebw]

Underlying this is webpacker only reports stderr, on the assumption that webpack itself reports errors on stderr. Instead it reports (some ? all ?) errors on stdout.

Either webpack itself needs correcting to report errors on stderr, or the stdout content needs to be included in the logging since it may contain the errors.

[kirillian]

This is a really good point. The mismatched expectations is the root cause. The workaround I provided took advantage of the fact that stdout is captured and just toggles it so that it shows...

The expectation here seems to be that errors show on stdout. Since that expectation is wrong, reevaluating the expectation seems logical to me.

[jackkinsella]

Ran into this today. I had a broken config due to the unavailability of an import from normalize-css. Running webpacker as usual only returned error Command failed with exit code 2.

I then cross-referenced with running webpack pure, separating stderr and stdout:

$ yarn run webpack --config config/webpack/production.js 1>stdout.log 2>stderr.log

Sure enough, stderr.log only had one line of error — the same one as webpacker, whereas the stdout.log had a detailed and helpful stack-trace:

ERROR in ./app/webpacker/stylesheets/application.scss
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/postcss-loader/src/index.js):
Error: Failed to find 'normalize-css/normalize.css'
....

I would have expected webpack to print these errors to stderr, but it doesn't. There is talk about this over in their repo, specifically they mention other tools relying on stderr. This is an area to watch.

Personally I think they should change things, but if they don't I would expect webpacker's compiler.rb to parse stdout on non-zero exit codes and spit out the errors. We in the Rails community pride ourselves on our tools being intuitive.

[jakeNiemiec]

@jackkinsella Can you check if the issue was fixed with #2190

[jackkinsella]

@jakeNiemiec Have confirmed — it's fixed on master/head. Awesome stuff!