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

Rule: messy-imports #781

Open
anderseknert opened this issue Jun 1, 2024 · 1 comment
Open

Rule: messy-imports #781

anderseknert opened this issue Jun 1, 2024 · 1 comment

Comments

@anderseknert
Copy link
Member

I think it was @johanfylling who suggested that we should have a style category rule to enforce ordering of imports, as well as grouping based on the "base path" in the imports. Something along the lines of:

Avoid

package policy

import data.alpha.omega
import rego.v1
import data.beta.b
import data.alpha.beta
import data.beta.a

Prefer

package policy

import rego.v1

import data.alpha.beta
import data.alpha.omega

import data.beta.a
import data.beta.b

Logic is fairly simple: imports of language "directives" like rego.v1 should always come first. After that follows alphabetically ordered imports, where the "base" attribute, like "alpha" in "data.alpha" is used for grouping. This is 100% compatible with opa fmt, and if implemented, we should also ensure that we implement this in regal fix so that this convention can be applied automatically to a project.

@anderseknert
Copy link
Member Author

One thing that I hadn't considered is comments. While it's hard to imagine scenarios where commenting imports adds much of value, and don't think it's common, we'd still need to deal with it I guess. And we'll need to do it in a way that's compatible with the formatter, which currently always separates a comment from the line above with an extra newline. Presence of comments will also make it much harder to rewrite the imports using regal fix...

We could either spend 90% of the effort here catering to that 1% of policies, or we could just bail out when we find comments somewhere between the first import and the last. As long as we document that behavior, I think that's good enough for a first implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: TODO
Development

No branches or pull requests

1 participant