Move NodePattern into AST namespace about rubocop-ast HOT 9 CLOSED

It's also a bit weird that RuboCop::Error ended up in rubocop-ast. Probably we should just use a different constant in rubocop and rubocop-ast, but that's definitely not a big deal.

from rubocop-ast.

I was about to file the same ticket myself. :D Eventually we should move everything that's under RuboCop currently to RuboCop::AST. We have to be smart about this, however, as it's going to cause breakages - one option would be to utilize some aliasing.

from rubocop-ast.

Looks like a good idea to move NodePattern, ProcessedSource and Token into AST.

Probably best to create the aliases in rubocop gem itself... I'll take care of that.

We could do the same for RuboCop::Error, but I feel it's less sensical. Would be strange that ConfigNotFoundError would be a AST::Error...

I think it's a principle to have a common base class for errors. I don't think we need a rubocop-core/tools/base gem just for that and a few odds and ends, but I'm not against it either.

An alternative solution would be to have RuboCop::AST::Error and have RuboCop::Error be a module that we include (instead of derive from) in rubocop; it would be included in AST::Error from rubocop gem. This way rescue RuboCop::Error would still rescue both AST::Error and ConfigNotFoundError.

from rubocop-ast.

Forgot to mention, but ValidationError doesn't belong in rubocop-ast, my bad. I'll fix that too.

from rubocop-ast.

Nevermind, Error & al. can be moved no problem, my bad.

from rubocop-ast.

👍

Okay, I guess once this is done we can bump rubocop-ast to 1.0.

from rubocop-ast.

I'll release 0.0.3 for now... and we can release 1.0 at the same time as rubocop?

from rubocop-ast.

Sounds good. I guess I can now cut one extra RuboCop release to see if we didn't break anything with the extraction for some external gem.

from rubocop-ast.

That's something I want to add to the github actions... testing with earliest compatible rubocop release (not just master)

from rubocop-ast.