Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple superclasses #98

Merged
merged 7 commits into from
Feb 20, 2024
Merged

Conversation

mfmmq
Copy link
Contributor

@mfmmq mfmmq commented Nov 9, 2023

Add support for linting detection for multiple model super classes without introducing breaking changes. Allow config to take either a list or a string for model super class. Update the README.md and specs to reflect this change.

Also fix some miscellaneous unrelated linting/rubocop offenses being flagged in checks.

anony.gemspec Outdated Show resolved Hide resolved
return unless (superclass = node.children[1])

superclass.const_name == model_superclass_name
superclass = node.children[1]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you consider looking for all leaf nodes that include ApplicationRecord or ActiveRecord::Base in their hierarchy instead of just looking at immediate children?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So unfortunately it's not this straightforward because this is not a Ruby object, it's an AST node. As far as we could see this only has the context of the current file, so you'd have to do a bunch of finnagling to be able to look at the class hierarchy outside of that context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 , happy to have another look into some ways around this if blocking though :~)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably fine. I guess we could potentially add a spec in payments-service to ensure all classes that inherit from ApplicationRecord and have children of their own are included in the ModelSuperclass list, but I think as @benk-gc says there's a limit to what we can check from a cop without a lot of extra work.

Maybe something that can be looked into another time. "Good enough" is better than not improving things because they're not yet perfect after all :)

Copy link
Contributor

@Tabby Tabby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me, and thanks for making the change. It seems like there's a good reason to revert the change to how the dependencies are specified so if we do that, I think we can get this merged

Lint/DefineDeletionStrategy:
ModelSuperclass:
- Acme::Record
- UmbrellaCorp::Record
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope UmbrellaCorp get a high risk rating XD

anony.gemspec Outdated Show resolved Hide resolved
return unless (superclass = node.children[1])

superclass.const_name == model_superclass_name
superclass = node.children[1]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably fine. I guess we could potentially add a spec in payments-service to ensure all classes that inherit from ApplicationRecord and have children of their own are included in the ModelSuperclass list, but I think as @benk-gc says there's a limit to what we can check from a cop without a lot of extra work.

Maybe something that can be looked into another time. "Good enough" is better than not improving things because they're not yet perfect after all :)

@Tabby Tabby merged commit 606a664 into master Feb 20, 2024
12 checks passed
@Tabby Tabby deleted the support-multiple-superclasses branch February 20, 2024 17:56
Tabby added a commit that referenced this pull request Feb 20, 2024
Should have been done in #98, but I missed that it hadn't been
@Tabby Tabby mentioned this pull request Feb 20, 2024
Tabby added a commit that referenced this pull request Feb 20, 2024
Should have been done in #98, but I missed that it hadn't been
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants