[HN Gopher] We automatically fixed thousands of Ruby 2.7 depreca...
       ___________________________________________________________________
        
       We automatically fixed thousands of Ruby 2.7 deprecation warnings
        
       Author : kiyanwang
       Score  : 106 points
       Date   : 2022-03-06 10:16 UTC (12 hours ago)
        
 (HTM) web link (about.gitlab.com)
 (TXT) w3m dump (about.gitlab.com)
        
       | WJW wrote:
       | Rubocop is an amazingly powerful tool for refactoring ruby
       | codebases. The ability to add custom linting rules and associated
       | autocorrectors basically makes it an AST-level find-and-replace
       | tool.
       | 
       | You do need comprehensive testing of course, but that should be
       | table stakes anyway for any large Rails codebase.
        
         | ch4s3 wrote:
         | I really like Rubocop, but it's quite slow and resource
         | intensive. I was trying to set up tooling for someone doing The
         | Odin Project recently and couldn't get Rubocop or Solargraph
         | working in VSCode in their VM, on a pretty high end XPS.
        
           | [deleted]
        
           | ckolkey wrote:
           | The trick with speeding up rubocop (and most other linters,
           | for that matter) is to run it as a daemon. There's a rubocop
           | daemon gem available. Or with solargraph, rubocop is kept in
           | memory so you only pay the startup cost once. With that setup
           | you can get a lint/fix on save in sub 300ms.
        
             | ch4s3 wrote:
             | I tired that and it was still a little too sluggish to use.
        
         | kayodelycaon wrote:
         | Rubocop is awesome. The amount of configuration allows it to be
         | tailored to a company's preferred rules. (Rubocop's defaults do
         | not match the common stylings I see in the Ruby in Rails
         | community.)
        
       | john_cogs wrote:
       | Hey, GitLab team member here. In the post, the author mentions
       | boring solutions. This is actually one of our subvalues at
       | GitLab. You can read more about them here:
       | https://about.gitlab.com/handbook/values/#boring-solutions
        
       | brigandish wrote:
       | Good for them. I have found these warnings and others in Ruby so
       | obnoxious that I started to look for alternatives, on the command
       | line and as a language. I no longer support putting warnings into
       | a code base in this way anymore as a result. I'm sure those
       | who've experienced unwanted output from colors.js might feel
       | similar.
       | 
       | On a brighter note, my ability with awk and sed is much better
       | now, so it's not all bad!
        
         | __float wrote:
         | How can you legitimately compare this to the colors.js thing?
         | This is a language evolving, and warning you of something that
         | in Ruby 3 will be a _breaking change_.
         | 
         | This is a _good_ change, too, and if you 're just writing small
         | one-off Ruby scripts, why not start writing compliant Ruby?
        
         | KerrAvon wrote:
         | Deprecation is an essential part of language and SDK
         | maintenance. If you find a programming language that hasn't
         | done it, you've found a trivial or dead language. (Or one
         | that's just gone ahead and removed the features without any
         | warning.)
        
         | jrochkind1 wrote:
         | If anyone else who hasn't yet abandoned ruby wants to suppress
         | ruby-language-level warnings, this gem is super helpful:
         | https://github.com/jeremyevans/ruby-warning
         | 
         | Personally, I'm really happy that 2.7/3.0 is the biggest
         | backwards change ruby has had in years, and still wasn't really
         | that bad, was pretty easy to update codebases for. I'm happy
         | that ruby committers are taking avoiding breaking changes
         | pretty seriously.
         | 
         | (the deprecation warnings are part of a standard of making what
         | breaking changes do occur easier to handle, I don't think I'd
         | agree with removing them. In this case, gitlab would have had
         | to change their code for 3.0 with or without the warnings in
         | 2.7; the warnings helped them do so reliably. There may be ways
         | to make them less annoying without being less useful. I do
         | think the breaking changes themselves should be kept as
         | infrequent as feasible. )
        
           | noneeeed wrote:
           | Agreed. One of the things I like about both Ruby and Rails is
           | how well deprecations and changes are managed. Significant
           | changes occur over multiple versions with really good
           | prewarning.
        
       | qrush wrote:
       | Going to need to do this real soon. Thanks for posting this!
        
       ___________________________________________________________________
       (page generated 2022-03-06 23:01 UTC)