Version 2.8.0 raises ExecJS::ProgramError: TypeError: Cannot read property 'version' of undefined #99
Comments
|
Note: actually I just noticed it doesn't break jekyll, but its plugin jekyll-autoprefixer I also created an issue at jekyll-autoprefixer |
|
I just had the same error during precompilation and we don't use jekyll at all. With 2.7.0 everything is working fine. |
SuwakoMmh
changed the title
|
This is related to using Ruby < 2.7. If you must stay on Ruby 2.6 or earlier, you probably need to stay on Two solutions:
|
|
Well I use ruby 2.7.3 Traceback |
|
This is occurring for me as well on Ruby 2.7.3. Pinning execjs to 2.7.0 fixes the issue. |
|
I use ruby 3.0.1 on Ubuntu, and execjs 2.8.0 raise errors too. |
|
Same ruby 2.7.3. |
|
I've the same issue with ruby 3.0 |
|
Same here for ruby 3.0.1. Rails precompile assets failed. |
|
Expirience the same error on ruby 3.0.1 with this release. |
|
Same error in 2.7.2 |
|
The problem is that autoprefixer tries to detect the node version: ai/autoprefixer-rails#203 A long time ago Let's try to find a solution with autoprefixer, I don't think this version check is the way to go. |
|
Maybe I am missing something here, but couldn't we just use:
to determine the current node version on the system? |
|
We could try yes, but the way ExecJS locate the node binary is quite involved. But that would probably work in 99% of the cases. |
Yeah I thought the same way...so I thought 99% of the cases maybe would be okay for a non breaking version for now, till a more sophisticated fix is ready. |
|
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. |
|
Yeah...that should propably point in the right direction too, I think. |
See GitHub issue here: rails/execjs#99
|
Not sure if it's the same issue, but we're on Ruby 2.7.3 and our CI got errors building assets: |
|
An autoprefixer version which fixed the execjs to 2.7.0 for now, got released yesterday. Also I experience such stuff when updating some asset related gems. |
I am experiencing the same with ExecJS 2.8.0 and Ruby 2.7.3. For me it says |
|
I've also experienced the JSON parser error with both uglifier and terser but in ruby 2.5.x/rails 5.2.6, downgrading to 2.7.0 fixed it. |
|
Could you open a distinct issue about the uglifier/json problem? I really don't think it's the same thing. |
|
[Edit: This change I mention wasn't actually the cause; it seems I just got lucky with timing after making this change and didn't see the error since the flush happened in time. See this comment for the real root cause and what was fixed]
|
I'll happily do it if someone gives me enough informations to repro. |
|
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 |
|
don't know if my issue should be in a different thread, however I have also been able to pinpoint the failure of version Locking at version |
|
Ok, so:
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 |
|
@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! ❤️ |
|
I still have the same issue: |
|
@igorkasyanchuk Please read the discussion above. The issue you point is with autoprefixer, and will be fixed in autoprefixer. |
Yes it’s a good idea but with 100 repos it is a taxing exercise to try out every patch and minor version for every single gem. We generally wouldn’t allow major versions to float but a change from 2.7.0 to 2.8.0 is minor and should be backwards compatible. The change log does not indicate anything scary happening either. I guess this major change falls under “improvements for Ruby 3.0” I was just surprised to see the execjs repo had a failing CI run for the 2.8.0 version and was released anyway. I was also surprised it wasn’t yanked when the problem was discovered to save people like me days of time given that the release clearly didn’t work for many users. It has been yanked now fortunately but it still wasted about a week of time between my coworker and I, so I hope you’ll be quicker to yank failing code next time. |
This was a random CI blurp, nothing concerning.
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.
No it wasn't. |
|
@mrgordon you may want to look into the |
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.
Okay he rolled forward with a new release, I hadn't seen 2.8.1 yet.
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 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. |
|
Thank you @pixeltrix and everyone else for fixing this in a matter of hours/days. Much appreciated. |
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 |
|
@mrgordon what I think you may be missing is that the fix wasn't even known until @byroot took a look, after which it was fixed and released within hours. The speculation about the fix, including my own, had not identified the actual issue, just the symptoms. Looking back at the previous commits to |
|
@md5 Yes I assumed a proper fix could take a while to investigate which is why I suggested removing the change ASAP rather than trying to debug it since so many projects use execjs. Obviously a new release rather than yanking was a better solution but even a simple release to just revert the 2.8.0 changes that were related (or all of them) as soon as the issue was reported would have saved several days (or some debugging) for a lot of people. I guess this repo isn’t changed much anymore so the original maintainers have moved on and there isn’t a big need for day to day maintenance except when a new change breaks something. @byroot actually noticed the issue on his other GitHub account @casperisfine 3 days ago so my point was that a revert release at that point would still have saved about 2 days of brokenness and would have required just a few minutes likely. If he had not had a chance to check in here for a few days (which would be perfectly understandable) then with 43 committers and such an important project it shouldn’t be necessary to wait on one person ideally. It looks like from the contributors tab that he wasn’t even the original author, just someone trying to improve things and keep it up to date. As I’ve hopefully made clear, I’m not trying to give anyone a hard time but it would be good to prevent these kinds of issues in the future. Similar to how no one wants to yank a gem after MimeMagic ;) |
…or execjs issue fix rails/execjs#99
Gems: bump to GBL 2.4.0 and lock execjs at 2.7.0 to avoid "TypeError: Cannot read property 'version' of undefined" error. See: rails/execjs#99 SVG: remove title element Blacklight automatically populates the title popover value from the locales or the filename here. JS: remove unused modules Advanced Search: remove BL config try block. Not using in B1G and it tosses a SystemStackError Locales: add v2.4.0 additions Settings: add v2.4.0 additions
|
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:
Then bingo it all worked for me. |
|
Just for people looking for this using search engines: |
and others
Hi, I don't know much about jekyll or ruby or rails or exec-js
My project won't build with version 2.8.0
here's the traceback :
I don't know if it's a jekyll issue or an execjs issue, meanwhile we're rolling back to 2.7.0.
Best Regards,
SuwakoMmh.
The text was updated successfully, but these errors were encountered: