Issue #19352 has been updated by Milella@Hotmail.com (Scott Milella). sawa (Tsuyoshi Sawada) wrote in #note-15:
Milella@Hotmail.com (Scott Milella) wrote in #note-13:
Again what is the BENEFIT of removing those methods? I understand they have been deprecated but if it is so obvious then why would webpacker have used those methods since it's creation date (December 07, 2016) which was after the deprecation? Can the deprecation of those 2 methods be reversed if it doesn't make sense to do so?
You seem to be presupposing/suggesting that:
1. If there is some benefit to deprecate a Ruby's feature, then that should have been so obvious to the developers of webpackers, That was not what I meant; my meaning was that if those RUBY methods were deprecated over 12 years ago and EVERYONE should have knew about as it was suggested then webpacker would have most likely used the non depreciated methods instead. My meaning was that it must not have been as obvious as it was being implied. I in no way fault the makers of webpacker for anything.
2. If the benefit is so obvious, then the developers of webpacker must have become aware when the feature became deprecated. Not what I meant at all, I do not fault the makers of webpacker in anyway. Webpacker came into existence after those methods were deprecated and reached end of life before those methods were removed from Ruby v3.2.
3. If the developers of webpacker used a deprecated feature, then it didn't make sense to deprecate the feature, Rails v6.1.7 with webpacker was the first issue I ran across using Ruby 3.2. I learned it was due to those 2 deprecated methods that were removed. My meaning was why remove 2 methods from Ruby that WE KNOW WILL causes an issue with Rails 6.1.7 using webpacker if it offers no benefit? I said above "Could even be a lot of gems that use those methods.". I reported the issue as soon as I ran across it because I didn't want to see issues with Rails 6.1.7 and Ruby 3.2 AND potentially other gems/apps as well. I don't know how far reaching the issue goes. It could only be an issue with Webpacker/Rails 6.1.7 and Ruby 3.2 for all I know.
all of which is a logical leap, and does not make much sense to me.
Again to be clear I don't have ANY issue with Ruby, Rails or Webpacker or ANYONE in the Ruby/Rails community at all.. I simply didn't want to see Ruby 3.2 have a problem with Rails 6.1.7 with webpacker if it could be avoided. I reported it in hopes of it being fixed so that the issue would not exist and affect anyone. I DID question the fact of removing 2 methods that don't offer a clear benefit if we KNOW it WILL cause a problem. I apologize if I miscommunicated that in any way. Scott ---------------------------------------- Bug #19352: Feature #17391 was not such a good idea because now Ruby 3.2 can not install Rails v5 or v6 if they use webpacker. https://bugs.ruby-lang.org/issues/19352#change-101587 * Author: Milella@Hotmail.com (Scott Milella) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- Hello, I tried logging a GitHub issue to Rails to make them aware of this issue but they said they are no longer bugfixing Rails v6.1 anymore. So since this IS a Ruby issue at its core this might be the best place for this. You removed 2 methods from Ruby 3.2 namely: Dir.exists? [Feature #17391] File.exists? [Feature #17391] The reason cited was that it was deprecated since v2 and MAYBE it might be a good idea to remove it in v3. I disagree. It will alienate Rails v5 and v6 from at the very least making a new rails app because when the webpacker install is called it uses one or both of those methods. take a look at this log: Here is what I did: ``` Windows 10/11 Installed prerequisites: NodeJS, Yarn, Git, SQLite3 etc. Install Ruby on Windows using RubyInstaller v3.2.0 filename: "rubyinstaller-devkit-3.2.0-1-x64.exe" Installed newest rails via gem install rails (installed v7.0.4.1 and it successfully installed) Install rails via gem install rails -v 6.1.7 (successfully installed) rails _6.1.7_ new testapp Here is the install log around the failure point: Bundle complete! 15 Gemfile dependencies, 78 gems now installed. Use bundle info [gemname] to see where a bundled gem is installed. run bundle binstubs bundler rails webpacker:install create config/webpacker.yml Copying webpack core config create config/webpack create config/webpack/development.js create config/webpack/environment.js create config/webpack/production.js create config/webpack/test.js Copying postcss.config.js to app root directory create postcss.config.js Copying babel.config.js to app root directory create babel.config.js Copying .browserslistrc to app root directory create .browserslistrc rails aborted! NoMethodError: undefined method `exists?' for Dir:Class Tasks: TOP => app:template (See full trace by running task with --trace) ``` Is there any way we can reverse the removal of those 2 methods? Otherwise you are again alienating Rails v5 (with webpacker) and v6 which a L O T of Rails apps runs on. Why would you want to release a new version of Ruby that PREVENTS backwards compatibility. It does work properly on Ruby 3.1, but if you try Ruby 3.2 you will get the method error on exists?. Thank You, Scott -- https://bugs.ruby-lang.org/