julz / importas Goto Github PK

It seems that the library uses the : token to parse the input causing it to wrongly parse regexes with non capturing groups.

Example:

-alias k8s.io/apimachinery/pkg/(?:api/)?(\w+):k8$1

Error:

importas: error parsing regexp: invalid or unsupported Perl syntax: (?$``

@julz is it possible to use semver based tagging (add tags after adding features or fixing bugs), it can make the life of the maintainers of tools that depend on importas way easier (speaking about myself who is trying to keep tooling updated as much as possible in golangci-lint).

Also, @dependabot can easily track dependencies, which is also a nice thing to have.

I'd like to check if import alias has no CAPS in its name. I wasn't able to find any linter that can do that. Do you think importas can be the one who can provide this functionality? I can contribute if you agree.

Would it be possible to get the order of the rules respected internally? With the rules being put into a map, the order is different from run to run. When utilizing the regexp rules, it would be helpful to be able to rely on the order so you can get progressively broader in the rules.

Looking to leverage both no-unaliased and no-extra-aliased flags in golangci-lint, and end up getting results where un-aliased imports start giving problematic results. Ideally we'd have the restrictions provided by both the flags (consistent, always-defined aliases; rejecting any new aliases that aren't described)

linters-settings:
  importas:
    no-unaliased: true
    no-extra-aliases: true
    alias:
...

Which results in a number of issues, where even standard libraries act as if they have an alias but not in the config:

import "time" has alias "" which is not part of config (importas)
        "time"

Problem:

Importas uses rules to standardize package aliases. But as the project gets bigger, there will be more and more rules and it is difficult to maintain. There may be cases where the same package has different aliases because this package is not covered by the rules. Importas cannot handle this situation because it does not support checking whether there are different aliases for the same package in different go files or in same go file without rules.

solution you'd like.

Checking whether there are different aliases for the same package before checking the aliases according to the importas rules.
Like this :

This little implement, https://github.com/Rodge0/samealias, maybe useful.

Appreciate!

Feature request: add a new flag -no-extra-aliases or -allow-list which only permits aliases passed to importas.
This would effectively make importas aliases an allow list for all aliases in the scanned packages.

Projects which use this setting would force developers to add importas aliases to their lint config settings if they would like to alias a package.

Hi 🙂

Please, bump golang.org/x/tools to v0.7.0 (as minimum) and make new tag in your repo.

It's important to be consistent with new Go 1.20 golangci-lint.
Related to golangci/golangci-lint#3086

Thanks!

P.S. Optionally I recommend

• to move linter to 1.20 totally (go.mod, CI, etc.)
• add support of dependabot