5 ms·
We automatically fixed thousands of Ruby 2.7 deprecation warnings
- WJW 5y agoRubocop 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.
- kayodelycaon 5y agoRubocop 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.)
- ch4s3 5y agoI 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 5y ago[deleted]
- ckolkey 5y agoThe 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 5y agoI tired that and it was still a little too sluggish to use.
- john_cogs 5y agoHey, 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 https://about.gitlab.com/handbook/values/#boring-solutions
- brigandish 5y agoGood 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!
- phendrenad2 5y agoI maintain a monkey_patch.rb file that patches the warning spam out of common gems. It really helps with my sanity when looking through logs.
- brigandish 5y agoI made the mistake on the command line of wrapping it in a alias and dumping the output to dev null, missed something actually important and wasted time! Won't make that mistake again, your monkey patch sounds a much better idea. STDOUT/ERR is just the wrong place for information other than what my code is outputting.
- jrochkind1 5y agoIf 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 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. )
- 5y ago
- qrush 5y agoGoing to need to do this real soon. Thanks for posting this!