importas: detect duplicate alias or package in the configuration

[ldez]

Produce an error log when a package has multiple aliases:

  importas:
    no-unaliased: true
    alias:
      - alias: netv1
        pkg: "k8s.io/api/networking/v1"
      - alias: networkingv1
        pkg: "k8s.io/api/networking/v1"

Produce an error log when an alias is used for several packages:

  importas:
    no-unaliased: true
    alias:
    - alias: netv1
      pkg: "k8s.io/api/networking/v1"
    - alias: netv1
      pkg: "k8s.io/api/networking/v1beta1"

[bombsimon]

Should unique aliases be an opt in? F.ex. by default the linter supports unaliased imports even if it's added with alias so supporting multiple aliases feels similar (unaliased + alias1 vs. alias1 + alias2)?

Also I think since the linter uses a map this should already report a diagnostic since first adding alias1 and then alias2 will have alias2 override alias1 making imports with alias1 not allowed.

Currently this change makes the linter behave differently depending on if it's run natively or through golangci-lint which I think is nice to avoid. But maybe I'm missing some context here?

[ldez]

Currently this change makes the linter behave differently depending on if it's run natively or through golangci-lint which I think is nice to avoid. But maybe I'm missing some context here?

It's a not different behavior, it's just a better way to detect problems inside the configuration.
For me, it's not related to the behavior of the linter.
The configuration is sent to the linter without modifications related to the detection of duplication, it's just a log.

The provider configuration uses a map just because this is "easier" with CLI flag parsing.

Should unique aliases be an opt in? F.ex. by default the linter supports unaliased imports even if it's added with alias so supporting multiple aliases feels similar (unaliased + alias1 vs. alias1 + alias2)?

As the key of the map is the package, the linter is not able to handle multiple aliases because it will not see them.

The fact to use the same alias for multiple packages is the opposite of the target of this linter: use the same import aliases everywhere for one package.
The package has been mainly made to handle k8s imports: the goal is to avoid ambiguities on imports between files and inside a file.
K8s imports always end with v1, v1alpha1, v1beta1, versioned, fake, externalversions, etc. so when you are using multiple resources you are quickly forced to use explicit aliases and use the same between files.

The no-unaliased option is just because in some cases when you are using CRD inside a package, which mainly targets this CRD, you can want to use it without aliases, it's close to what the . import allows.

[bombsimon]

The configuration is sent to the linter without modifications related to the detection of duplication, it's just a log.

My bad, I thought error severity would affect running or exit code but if it's just logging it makes sense.

Regarding the map, my thought was to change this behaviour if you wanted to support different behaviour and/or have this logic in the linter instead.