execjs: Version 2.8.0 raises ExecJS::ProgramError: TypeError: Cannot read property 'version' of undefined

I had rails 5.2 with ruby 2.3.1. To fix this issue I had to downgrade to execjs to 2.7.0. Do the following:

1. Add gem 'execjs', '2.7.0' to your gemfile.
2. Run bundle update execjs

Then bingo it all worked for me.

I use ruby 3.0.1 on Ubuntu, and execjs 2.8.0 raise errors too.

      01 ExecJS::ProgramError: TypeError: Cannot read property 'version' of undefined
      01 eval (eval at <anonymous> ((execjs):1:213), <anonymous>:1:10)
      01 (execjs):1:213
      01 (execjs):16:14
      01 (execjs):1:40
      01 Object.<anonymous> ((execjs):1:58)
      01 Module._compile (node:internal/modules/cjs/loader:1109:14)
      01 Object.Module._extensions..js (node:internal/modules/cjs/loader:1138:10)
      01 Module.load (node:internal/modules/cjs/loader:989:32)
      01 Function.Module._load (node:internal/modules/cjs/loader:829:14)

Not sure if it’s the same issue, but we’re on Ruby 2.7.3 and our CI got errors building assets: …

I am experiencing the same with ExecJS 2.8.0 and Ruby 2.7.3. For me it says JSON::ParserError: 434. Had to downgrade to ExecJS 2.7.0 again to fix it.

@mrgordon yanking a gem has serious side effects - if you analyse the outcome of the mimemagic yanking it left many people unable to deploy their applications and doing the same here was not necessary as there were no legal consequences of leaving it up. The main Rails gem has only been yanked 5 times and 4 of those were RC versions with security flaws. I only became aware of the issue this morning and we pushed the fix out within an hour of it being merged.

I’m sorry you feel you’ve wasted your time but obviously our intention is that it should’ve been backwards compatible. One of the reasons we eventually went with 2.8 as the version number is that we would’ve had to release a new version of Sprockets as well and we didn’t want to have to force people to upgrade that at the same time.

Again, I’m sorry for the time you spent having to debug this.

This is occurring for me as well on Ruby 2.7.3. Pinning execjs to 2.7.0 fixes the issue.

Not sure if it’s the same issue, but we’re on Ruby 2.7.3 and our CI got errors building assets:

[****] building asset: /stylesheets/admin/vendor/fontawesome-all.scss
rake aborted!
JSON::ParserError: 439: unexpected token at '{"css":"/*!\n * Font Awesome Pro 5.12.1 by @fontawesome - (truncated a lot of CSS here for GitHub)
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/json-2.5.1/lib/json/common.rb:216:in `parse'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/json-2.5.1/lib/json/common.rb:216:in `parse'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:68:in `extract_result'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:39:in `exec'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:21:in `eval'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:46:in `call'
/mnt/ramdisk/project/*************/ruby/2.7.0/gems/autoprefixer-rails-8.6.5/lib/autoprefixer-rails/processor.rb:37:in `process'

The problem is that autoprefixer tries to detect the node version: https://github.com/ai/autoprefixer-rails/issues/203

A long time ago process was removed to ensure all runtimes could be swappable: https://github.com/rails/execjs/commit/b0be19c73ded5f20c2c86c8e546558e09da4e2a5

Let’s try to find a solution with autoprefixer, I don’t think this version check is the way to go.

Well I use ruby 2.7.3

Configuration file: /home/---/Documents/colabois.fr/_config.yml
            Source: /home/---/Documents/colabois.fr
       Destination: /home/---/Documents/colabois.fr/_site
 Incremental build: disabled. Enable with --incremental
      Generating... 
                    ------------------------------------------------
      Jekyll 4.2.0   Please append `--trace` to the `build` command 
                     for any additional information or backtrace. 
                    ------------------------------------------------
Traceback (most recent call last):
        43: from /home/---/.rvm/gems/ruby-2.7.3/bin/ruby_executable_hooks:22:in `<main>'
        42: from /home/---/.rvm/gems/ruby-2.7.3/bin/ruby_executable_hooks:22:in `eval'
        41: from /home/---/.rvm/gems/ruby-2.7.3/bin/jekyll:23:in `<main>'
        40: from /home/---/.rvm/gems/ruby-2.7.3/bin/jekyll:23:in `load'
        39: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/exe/jekyll:15:in `<top (required)>'
        38: from /home/---/.rvm/gems/ruby-2.7.3/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
        37: from /home/---/.rvm/gems/ruby-2.7.3/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
        36: from /home/---/.rvm/gems/ruby-2.7.3/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
        35: from /home/---/.rvm/gems/ruby-2.7.3/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
        34: from /home/---/.rvm/gems/ruby-2.7.3/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
        33: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/commands/build.rb:18:in `block (2 levels) in init_with_program'
        32: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
        31: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/command.rb:91:in `each'
        30: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
        29: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/commands/build.rb:36:in `process'
        28: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/commands/build.rb:65:in `build'
        27: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/command.rb:28:in `process_site'
        26: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/site.rb:82:in `process'
        25: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/site.rb:234:in `write'
        24: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/hooks.rb:102:in `trigger'
        23: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/hooks.rb:102:in `each'
        22: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-4.2.0/lib/jekyll/hooks.rb:103:in `block in trigger'
        21: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll-autoprefixer.rb:24:in `block in <top (required)>'
        20: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll/autoprefixer/autoprefixer.rb:20:in `process'
        19: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll/autoprefixer/autoprefixer.rb:20:in `each'
        18: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll/autoprefixer/autoprefixer.rb:23:in `block in process'
        17: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll/autoprefixer/autoprefixer.rb:23:in `open'
        16: from /home/---/.rvm/gems/ruby-2.7.3/gems/jekyll-autoprefixer-1.0.2/lib/jekyll/autoprefixer/autoprefixer.rb:27:in `block (2 levels) in process'
        15: from /home/---/.rvm/gems/ruby-2.7.3/gems/autoprefixer-rails-9.8.6.5/lib/autoprefixer-rails.rb:16:in `process'
        14: from /home/---/.rvm/gems/ruby-2.7.3/gems/autoprefixer-rails-9.8.6.5/lib/autoprefixer-rails/processor.rb:53:in `process'
        13: from /home/---/.rvm/gems/ruby-2.7.3/gems/autoprefixer-rails-9.8.6.5/lib/autoprefixer-rails/processor.rb:170:in `runtime'
        12: from /home/---/.rvm/gems/ruby-2.7.3/gems/execjs-2.8.0/lib/execjs/runtime.rb:64:in `eval'
        11: from /home/---/.rvm/gems/ruby-2.7.3/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:21:in `eval'
        10: from /home/---/.rvm/gems/ruby-2.7.3/gems/execjs-2.8.0/lib/execjs/external_runtime.rb:39:in `exec'
         9: from Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
         8: from Function.Module._load (node:internal/modules/cjs/loader:829:14)
         7: from Module.load (node:internal/modules/cjs/loader:989:32)
         6: from Object.Module._extensions..js (node:internal/modules/cjs/loader:1138:10)
         5: from Module._compile (node:internal/modules/cjs/loader:1109:14)
         4: from Object.<anonymous> ((execjs):1:58)
         3: from (execjs):1:40
         2: from (execjs):16:14
         1: from (execjs):1:213
eval (eval at <anonymous> ((execjs):1:213), <anonymous>:1:10): TypeError: Cannot read property 'version' of undefined (ExecJS::ProgramError)

This is related to using Ruby < 2.7. If you must stay on Ruby 2.6 or earlier, you probably need to stay on execjs < 2.8. The other option is to upgrade to Ruby 2.7 or above. Adding this here for posterity and anyone else running into that rough error message 😃

Two solutions:

1. Upgrade to Ruby 2.7 or later
2. Downgrade to execjs 2.7 or earlier.

Thank you @pixeltrix and everyone else for fixing this in a matter of hours/days. Much appreciated.

It’s out: https://rubygems.org/gems/execjs/versions/2.8.1

This gem needs to be yanked or fixed ASAP. Like many people in this thread, my coworker and I spent several days digging into why our complicated pull request was suddenly failing only to discover that a minor version upgrade of 2.7.0 to 2.8.0 on this library had been causing the arcane error vJSON::ParserError: 419: unexpected token at '{"code":"/*!\n * Flat UI Free v2.2.2 during asset compilation. This is really wasting a lot of time for no reason.

Ok, so:

• The issue with autoprefixer will be fixed in autoprefixer at some point, in the meantime it’s locked to 2.7.0
• The ParseError is fixed by a6abf130c721ca6ec05cfc7ed79cf2e87a7dcc35

I’ll ask for a release, hopefully it should happen soon. In the meantime as many mentioned you can lock to 2.7.0, or use another runtime, e.g. add the mini_racer gem.

@mrgordon Ouch, several days. I realise it won’t work for every project or for every update, but we update deps daily in our main project precisely so it’s easier to pinpoint regressions like this one. In this case we upgraded 3 gems that day, got CI errors from that commit, noted execjs was the only one that seemed related to assets, rolled it back to confirm, then locked the version down. Maybe 40 minutes all in all.

@byroot Thank you! ❤️

Same here for ruby 3.0.1. Rails precompile assets failed.

@mrgordon yanking a gem has serious side effects - if you analyse the outcome of the mimemagic yanking it left many people unable to deploy their applications and doing the same here was not necessary as there were no legal consequences of leaving it up. The main Rails gem has only been yanked 5 times and 4 of those were RC versions with security flaws. I only became aware of the issue this morning and we pushed the fix out within an hour of it being merged.

I’m sorry you feel you’ve wasted your time but obviously our intention is that it should’ve been backwards compatible. One of the reasons we eventually went with 2.8 as the version number is that we would’ve had to release a new version of Sprockets as well and we didn’t want to have to force people to upgrade that at the same time.

Again, I’m sorry for the time you spent having to debug this.

No problem, I understand yanking may not have been the right approach. I appreciate your time certainly and I only commented to let people know the extreme downstream effects in hopes that broken code could be removed as quickly as possible in the future. Certainly if you just learned of the issue then you did everything you could. It just felt like after a few days with the issue being open here it was possible that it wasn’t being reverted while it was looked into as there were a number of comments already including some recommending people upgrade their Ruby version (which didn’t even resolve the issue). People saying the solution was to upgrade the Ruby version made it feel like it wasn’t a “minor” change but in retrospect it seems it was just a bug

I’m just not convinced this check is even necessary. It seems to me that it was added to help users figure out why autoprefixer might not work.

I feel like autoprefixer could just not check and add a message to any error that is raised to hint at checking the node version.

This is not what gem yanking is for. It would have created an even bigger mess, especially since only peopke using the node runtime were affected.

You think it would create a bigger mess than people finding a mysterious bug and spending four days looking for it? I somehow doubt it would have taken four days for me to notice that the gem was yanked, maybe 15 seconds. Regardless rolling forward to 2.8.1 was also a fine solution and allows people to use 2.8.0 in the meantime if it works for them (until they run the wrong command and it stops working…). I was trying to provide an immediate solution and it was clear 2.7.0 worked. Its unreasonable to expect bugs to be fixed immediately but if they completely break functionality for many users then at least reverting out the change is usually polite.

It has been yanked now fortunately

No it wasn’t.

Okay he rolled forward with a new release, I hadn’t seen 2.8.1 yet.

I hope you’ll be quicker to yank failing code next time.

Don’t you feel a bit entitled ?

I think after 10+ years we could expect the main Rails project to not leave a majorly broken “minor” upgrade in the current release for like 4 days when people are saying its breaking their projects and is hard to even find the problem. You can consider it entitled, but I consider it a basic aspiration for any well-functioning project. I appreciate all the hard work people put into execjs but I also know that small improvements to process can save people thousands of hours.

@mrgordon you may want to look into the bummr gem to automate some of this: https://github.com/lpender/bummr

I was just surprised to see the execjs repo had a failing CI run for the 2.8.0 version and was released anyway.

This was a random CI blurp, nothing concerning.

I was also surprised it wasn’t yanked

This is not what gem yanking is for. It would have created an even bigger mess, especially since only peopke using the node runtime were affected.

It has been yanked now fortunately

No it wasn’t.

@igorkasyanchuk Please read the discussion above. The issue you point is with autoprefixer, and will be fixed in autoprefixer.

don’t know if my issue should be in a different thread, however I have also been able to pinpoint the failure of version 2.8.0 at building a container based solution in the step rails assets:precompile as it gives a JSON::ParserError: 434: unexpected token at ... error

Locking at version 2.7.0 solves the issue.