Latest uglifier, 4.2.0 prevents runtime uglifier asset compilation #7835
Conversation
ExecJS 2.8.1 requires uglifier 4.2.0 to defer uglifier asset compilation until asset compilation time, see: rails/execjs#105 Trying to compile the uglfier assets in production mode in an environment with dynatrace was causing conflicts with the execjs node runtime and the dynatrace reporting mechanism. We should be able to avoid this entirely if we only call out to node for asset compilation when we do explicit asset compilation at build time in a controlled environment without dynatrace instead of at runtime, which we cannot control.
|
@Fryguy I'm not sure how to test this since it's a build/test time only set of changes. We can do your idea of raising an error if it tries to hit this code in production: https://github.com/lautis/uglifier/blob/v4.2.0/lib/uglifier.rb#L183-L184, but I'm not sure how to verify the uglifier upgrade doesn't change behavior since the underlying UglifyJS changed with most version changes from 3.0.4 to 4.2.0: https://github.com/lautis/uglifier/blob/master/CHANGELOG.md#420-25-september-2019 |
There was a problem hiding this comment.
I put into an rpm and installed on an appliance
I verified:
- the right version of
uglifierwas installed - the rpms were built fine
- the ui came up and the dashboard and new provider form were in tact
- no error messages
grep ugl logs/*.log - javascript console showed no errors
|
If the RPM build works that's good enough for me, not sure the container build side would be any different |
|
This requires changes to Gemfile.lock.release in the core repo. |
|
@jrafanie A conflict occurred during the backport of this pull request to If this pull request is based on another pull request that has not been marked for backport, add the appropriate labels to the other pull request. Otherwise, please create a new pull request direct to the Conflict details: diff --cc manageiq-ui-classic.gemspec
index 757932268d,855bb98183..0000000000
--- a/manageiq-ui-classic.gemspec
+++ b/manageiq-ui-classic.gemspec
@@@ -21,8 -21,7 +21,12 @@@ Gem::Specification.new do |s
s.add_dependency "rails", "~> 6.0.0"
++<<<<<<< HEAD
+ s.add_dependency "coffee-rails"
+ s.add_dependency "execjs", "2.7.0" # HACK: 2.8.1 is causing node to exit 1 when compiling uglify's sourcecode in some environments. See https://github.com/rails/execjs/issues #105
++=======
+ s.add_dependency "execjs", "2.8.1" # Note: 2.8.1 requires uglifier 4.2.0 to defer uglifier asset compilation until asset compilation time: https://github.com/rails/execjs/issues/105
++>>>>>>> 16df3d8cbe... Merge pull request #7835 from jrafanie/update_to_latest_uglfier_execjs
s.add_dependency "font-fabulous", "~> 1.0.5"
s.add_dependency "high_voltage", "~> 3.0.0"
s.add_dependency "more_core_extensions", ">= 3.2", "< 5" |
|
@jrafanie I'll manually backport as this is trivial. |
Latest uglifier, 4.2.0 prevents runtime uglifier asset compilation (cherry picked from commit 16df3d8)
|
|
ExecJS 2.8.1 requires uglifier 4.2.0 to defer uglifier asset compilation until asset
compilation time, see: rails/execjs#105
Trying to compile the uglfier assets in production mode in an environment with
dynatrace was causing conflicts with the execjs node runtime and the dynatrace
reporting mechanism. We should be able to avoid this entirely if we only call
out to node for asset compilation when we do explicit asset compilation at build
time in a controlled environment without dynatrace instead of at runtime, which
we cannot control.