Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

• The CLA must be signed

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description of the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter (the team will help to verify that).
• It must have a valid license (AGPL is not allowed), and the file must contain the required information by the license, ex: author, year, etc.
• It must use Go version <= 1.23.0
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid semver tag, ex: v1.0.0, v0.1.0 (0.0.x are not valid).
• It must not contain init().
• It must not contain panic().
• It must not contain log.Fatal(), os.Exit(), or similar.
• It must not modify the AST.
• It must not have false positives/negatives (the team will help to verify that).
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must have integration tests without configuration (default).
• They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

• The file .golangci.next.reference.yml must be updated.
• The file .golangci.reference.yml must NOT be edited.
• The linter must be added to the lists of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the lintersdb/builder_linter.go and .golangci.next.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter uses goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
  • if the linter uses goanalysis.LoadModeTypesInfo, it requires WithLoadForGoAnalysis() in lintersdb/builder_linter.go
• The version in WithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The file jsonschema/golangci.next.jsonschema.json should be updated.
• The file jsonschema/golangci.jsonschema.json must NOT be edited.
• The linter repository should have a readme and linting.
• The linter should be published as a binary (useful for diagnosing bug origins).
• The linter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
• A tag should never be recreated.
• use main as the default branch name.

The golangci-lint team will edit this comment to check the boxes before and during the review.

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

The reviews should be addressed as commits (no squash).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

This checklist does not imply that we will accept the linter.

I feel like it should be a part of importas.

The cited references are distorted from their meaning: package names are not package aliases.

The cited references are distorted from their meaning: package names are not package aliases.

It is for package name.

Primarily the linter checks the package name to be Go idiomatic. Also put the same rule if in configimport-alias set to true, but it is an extra feature/optional.

From the official Go resources, this Go idiomatic is only for package naming not for package alias. That is why the import-alias made optional. I feel that package alias will be use just like we using package name, so that giving this as an extra feature.

importas seems has different goal, focus on alias consistency through pattern enforcement:

A linter to enforce importing certain packages consistently.

What is this for?

Ideally, go imports should avoid aliasing. Sometimes though, especially with Kubernetes API code, it becomes unavoidable, because many packages are imported as e.g. "[package]/v1alpha1" and you end up with lots of collisions if you use "v1alpha1".

This linter lets you enforce that whenever (for example) "pkg/apis/serving/v1alpha1" is aliased, it is aliased as "servingv1alpha1".

pkgname doesn't force import package to use same alias like what importas do.

I recommend avoiding reopening a PR before having feedback.

May I know whether this is final or need more justification to move forward?

I am working on something else, I will provide feedback later

Related: https://revive.run/r#var-naming

Related: https://revive.run/r#var-naming

Interesting. @alexandear I haven't use it before. I read the doc seeing that this is rule for var naming and optionally for package naming? How it behave?

Related: https://revive.run/r#var-naming

Interesting. @alexandear I haven't use it before. I read the doc seeing that this is rule for var naming and optionally for package naming? How it behave?

It has the same rules as your readme around package names and you can combine it with import-alias-naming.

› head -n7 **/*.go
==> badName/badName.go <==
package badName

==> bad_import/bad_import.go <==
package badimport

import (
        badImport "fmt"
        bad_import "fmt"
        okimport "fmt"
)

==> bad_name/bad_name.go <==
package bad_name

› cat .golangci.yaml
---
version: "2"

linters:
  default: none
  enable:
    - revive

  settings:
    revive:
      rules:
        - name: var-naming
        - name: import-alias-naming

› golangci-lint run
badName/badName.go:1:9: var-naming: don't use MixedCaps in package name; badName should be badname (revive)
package badName
        ^
bad_import/bad_import.go:4:2: import-alias-naming: import name (badImport) must match the regular expression: ^[a-z][a-z0-9]{0,}$ (revive)
        badImport "fmt"
        ^
bad_import/bad_import.go:5:2: import-alias-naming: import name (bad_import) must match the regular expression: ^[a-z][a-z0-9]{0,}$ (revive)
        bad_import "fmt"
        ^
bad_name/bad_name.go:1:9: var-naming: don't use an underscore in package name (revive)
package bad_name
        ^
4 issues:
* revive: 4