Report the whole build failure, not just its first line for classic (non-Vite) blueprint

[tricknotes]

Closes #484.

EmberCli::BuildError was raised with build_errors.first, so everything the build tool wrote after the first line was dropped. The line naming the file that failed to build is rarely that first line — a Handlebars parse error leads with Build failed. and names the file on the next line — which left the error reporting a line number with no file to look it up in, exactly as #484 reports.

Scope: the classic blueprint only

BuildMonitor is reached by the classic (non-Vite) blueprint only, so that is the only case this changes.

Path	How a failure is reported	Changed here
Classic blueprint, development (ember build --watch in the background, standard error redirected to the build error file)	BuildMonitor turns the error file into EmberCli::BuildError	yes
Vite blueprint, development	Vite's development server rebuilds; nothing is built ahead of time	no
Shell#compile — rake ember:compile, assets:precompile, and the development/test build of a Vite application	Runner#run! raises `<command>` failed with status N before BuildMonitor is consulted	no

Reporting the failure on the Shell#compile path is a separate concern and is left for its own change.

Approach

Report the whole filtered failure rather than parsing out the file name. File: x, in x and Build Error (...) in x are all used across build tools and versions, and matching them is fragile — a concern already raised in #318. Joining the lines surfaces the file wherever the tool happens to put it.

The existing filtering is untouched, so blank lines, JavaScript stack frames ( at ...), DEPRECATION: warnings and Building notices still never reach the message. build_errors now chomps the lines it keeps, so a failure read from disk no longer carries the file's newlines into the message.

Before / after

Verified end to end against a classic application (ember-cli 5.12.0, ember new blueprint) whose app/templates/application.hbs is missing a {{/if}}, served in development so that the ember build --watch path runs:

Before:

:legacy has failed to build: Build Error (Babel) in legacy-frontend/templates/application.js

After:

:legacy has failed to build: Build Error (Babel) in legacy-frontend/templates/application.js
/path/to/legacy-frontend/templates/application.js: Parse error on line 7:
...er</h2>{{outlet}}
--------------------^
Expecting 'OPEN_INVERSE_CHAIN', 'INVERSE', 'OPEN_ENDBLOCK', got 'EOF'
Stack Trace and Error Report: /tmp/error.dump.<hash>.log

The file, the line, the offending source and the caret all survive now; the at ... frames are still filtered out.

Tests

Three examples added to spec/lib/ember_cli/build_monitor_spec.rb: the multi-line report, the backtrace contents, and that lines read from disk do not carry their trailing newlines. No existing example needed changing.

• bin/rspec spec/lib/ember_cli/build_monitor_spec.rb — 13 examples, 0 failures
• bin/rspec spec/lib — 166 examples, 2 failures. Both (app_spec.rb:192, app_spec.rb:200) fail identically with this branch stashed; they need node_modules installed to find the ember binary.

Open questions for review

1. set_backtrace(errors) is a straight generalisation of the old set_backtrace(build_errors.first), but it now duplicates the message. Setting the backtrace to the at ... frames the filter discards would be more faithful to what a backtrace is — left out here as a larger behaviour change.
2. No cap on the output. Stack frames are filtered out, so the bulk of the noise is gone, but a build error with a large context block will produce a long message. In the verification above ember-cli wrote its error block to standard error twice, and both copies reach the message. Truncating to the first N lines is an option.
3. CHANGELOG.md gains a new main section, since 0.14.0 is released.
4. Should this close The error message displayed when compiling a template, doesn't contain location / file information #318 as well? It is the same root cause, though it was already closed as completed on 2026-09-04.

🤖 Generated with Claude Code