Open kozak opened 8 years ago
Thanks for opening this issue and bringing this to our attention!
This behavior is odd. The gem doesn't do anything with the ember-cli
generated error / stack trace.
The way we handle inter process communication between rails s
and ember b --watch
is by depending on EmberCLI to write build errors to STDERR, which we redirect to an error file that Rails is watching.
Outside of that, we don't have any logic around including / excluding error messages or stack traces.
TL;DR:
What version of Ember CLI are you using?
What version of the gem are you using?
What version of the addon are you using?
On the surface, this sounds like a bug in the way EmberCLI writes errors.
Thanks for a speedy reply, sorry for not including this information in the first place: package.json: ember-cli: 1.13.13 ember-cli-rails-addon: "^0.5.2"
gem: most recent version from github, from Gemfile.lock
GIT
remote: git@github.com:thoughtbot/ember-cli-rails.git
revision: 7badc2581e0158bb8017cf5a24a39ea8d50b77df
specs:
ember-cli-rails (0.5.6)
cocaine (~> 0.5.0)
non-stupid-digest-assets (~> 1.0.0)
railties (>= 3.2, < 5)
sprockets (>= 2.0)
When doing:
%node_modules/ember-cli/bin/ember b app/app.js 2>errors.txt
version: 1.13.13
Build failed.
the generated errors.txt includes the file information, here is the output: errors.txt
@kozak would you mind pulling down https://github.com/thoughtbot/ember-cli-rails/pull/324 and seeing if that corrects this issue?
Bad news: Unfortunately, it doesn't.
Good news: it appears that Ember creates its own tmp/error.txt file that overwrites the one Ember cli rails is creating from stderr redirection. If I change the error file name here https://github.com/thoughtbot/ember-cli-rails/blob/master/lib/ember_cli/path_set.rb#L75 to be something different than error.txt
the whole information is preserved in the log.
This also includes deprecations, so the first backtrace will not necessary be the actual ERROR. I am working on a Pull request.
@seanpdoyle How do you want to approach filtering out deprecations from the error file ?
Unfortunately, tmp/error.txt
isn't an EmberCLI generated file. The file is generated by the ember-cli-rails-addon addon.
When the gem executes the ember build --watch
command, the addon's error monitoring gets clobbered by redirecting STDERR
to tmp/error.txt
(and vice versa).
To correct this, we can change how the addon behaves.
Unfortunately, this fix is blocked by EmberCLI writing DEPRECATION
warnings to STDERR
.
Once a fix for that improper behavior lands, we can merge https://github.com/rondale-sc/ember-cli-rails-addon/pull/24
@kozak bad news: there isn't a good approach to prevent writing DEPRECATION warnings to STDERR
.
good news is that @rwjblue has written https://github.com/rwjblue/ember-cli-template-lint, which delays throwing deprecation warnings, pushing them out of build tools and into the browser.
Would you mind adding that addon in combination with https://github.com/rondale-sc/ember-cli-rails-addon/pull/24?
If that works for you, I could merge and release, documenting the new dependency.
Tangentially related, I received:
[BABEL] Note: The code generator has deoptimised the styling of "/home/templates..." as it exceeds the max of "100KB".
Which is a warning of a stupidly long template, but causes the rails server to throw an error even though the build was technically successful. This is with https://github.com/rondale-sc/ember-cli-rails-addon/pull/24
@seanpdoyle Sorry for getting back so late. Your suggested setup works fine and displays the correct error message!
@kayakyakr addressed in https://github.com/babel/babel/pull/3156
@kayakyakr according to to maintainer of Babel:
This is an error though. You shouldn't be passing such large files to the code generator as it's not currently suited for it. There's no stack trace because it's useless as the call stack depth is already too deep to show any useful debugging information.
https://github.com/babel/babel/pull/3156#issuecomment-163938591
I've stopped receiving the error, though, so I can't dig deeper right now...
The worst thing is that it's coming from a handlebars template that's around 10k in size. A 250 line, 8000 character template explodes into a 99,000 character js file. Yikes.
I had an error in a handlebars template (there is a href="#" and also a binding to href):
The error I got, didn't include the file information that is normally included in
ember build
This is what was displayed:When I run
ember build
I get a huge stack trace (which also includes deprecation information) and the file name: