Utilities for refactoring and upgrading Ruby code based on ASTs | Hacker News Reader

Utilities for refactoring and upgrading Ruby code based on ASTs

github.com

56 pointsmooreds20 comments

Tools like this seem like a great way to manage breaking changes if done right. Far too often, frequently with JavaScript, I'll find myself with a project whose dependencies are 2-3 major versions out of date, and the documentation of these versions' breaking changes is of course very poor and lacking in sufficiently detailed examples.

That's definitely one of the core motivations is to capture, contextually, as much of an upgrade as possible in hard code.

It's also a perniciously hard problem I'm very far from solving well quite yet.

https://github.com/baweaver/refactor#why-not-rubocop

Deflects the obvious without a cogent explanation because Rubocop's S-expressions are sufficiently powerful and general, already work, and don't require reinventing the wheel.

I find Rubocop extremely over-opinionated and enforcing style conventions I actually disagree with. You can disable rubocop rules, but as far I know you can't specify which style in rubocop you want code refactored to, so in those instances this tool could be of use.

I would suggest invest more time in configuration and developing cops where missing. Almost/all cops can be turned on or off as per the configuration[0], many have several alternative choices, and numerous options. It takes time and diligence to configure it for a particular coding standard, environment, or for personal preferences. You can make it enforce whatever coding style you want, and with a great deal of nuance and to including codemod transformations. This later bit was used extensively for large scale codemods.

Furthermore, writing a cop is surprisingly painless.

0: https://docs.rubocop.org/rubocop/configuration.html

The testing utilities are also great. The difficulty, I'd say, is inherit to working with ASTs and simplifying it is hard. They tried with Node Pattern, synvert tried with NQL, and I wanted to try with pattern matching and potentially more in-Ruby approaches.

Nothing particularly wrong with any of them, but trying to sort out what's not matching and getting an answer for now "close" a node was is a bit involved. Go far enough down that hole and you hit tree edit distance and Zhang Sha Sha algorithms.

> you can't specify which style in rubocop you want code refactored to

You can, with the per-cop `EnforcedStyle` configuration key.

I hate browsing the Rubocop doc so I just put the cop name with that config key set to a bogus value, then Rubocop yells at me about the invalid value and lists the available ones.

There can be more than EnforcedStyle, e.g see these for Style/HashSyntax (scroll up for examples), which autocorrect will respect:

https://docs.rubocop.org/rubocop/cops_style.html#configurabl...

Worse than that, Rubocop will complain about things that change the meaning of your code.

For example, Rubocop’s default configuration insists on calling “.zero?” over using “== 0”. Not all objects have a “.zero?” method, and even if they did it isn’t guaranteed to be the same as “== 0”.

It's just a thing someone pushed just yesterday to see if they can try and do better. It's explicitly marked as experimental. They don't need to write any rationale on why they made it, much less a detailed one. Nothing was "deflected"; what an awful choice of language.

If it's not fully formed and doesn't offer a specific advantage, then why is it here?

Because someone posted it and others upvoted the post. I know that's stating the obvious but that's the reason and there doesn't need to be any other.

I was unaware that you're only allowed to publish something if it's fully complete, to the satisfaction of randos on hacker news. Are you actively trying to discourage people from posting their projects or is that just an accidental side-effect?

To be fair I didn't post it :)

Yeah, it's still very very early in the process and I released it as I have a talk at Ruby Kaigi going over some of how this works next Tuesday, so I wanted something out even if it's simple for now.

> They don't need to write any rationale on why they made it

Just next tho the "experimental" moniker, and within an actual section about Rubocop, they in fact did provide a simple rationale anyway.

Checks out for me (even if they didn't have to provide any).

(emphasis mine)

> Why Not RuboCop?

> In most cases you likely want to use RuboCop as it has more robust support and testing. This gem is currently more experimental and focused exclusively on refactoring and AST manipulations in a more minimal sense.

Yes, that was what was linked. I can read. What is your point?

Merely that however succinct there's a clear-cut rationale, I read your comment as if there were none but that may be due to lack of caffeine on my side.

In that context, the quoting was just for highlighting.

I just meant "they don't need to address every possible concern; in fact, they're not required an explanation at all".

(my previous comment was probably a bit sharp; sorry – I'm just so tired of there always being this one person who has to crap all over people's personal projects)

Consider it a sandbox and a more minimal syntax around what Rubocop already does well. If anything I may try and upstream some of it later after it takes more shape.

It's also used to wrap a lot of AST tools for a talk I have next week, hence the earlier release even if it's fairly simple.

https://github.com/rubocop/rubocop/issues/8091#issuecomment-...

perhaps they are biased against the tool from participating in a campaign to police the name in the past.

But also, there's nothing wrong with more tools in this space. This is clearly an experiment, it should be welcomed.

You know I'm friends with @bbatsov right? That's reaching pretty far. I've actively funded the maintainers in the past as well, doesn't mean I agree with everything or every name, but I respect their work.

Reply on news.ycombinator.com