Hey, thank you for opening your first Pull Request !

CLA assistant check
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.
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• 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 work with T=<name of the linter test file>.go make test_linters. (the team will help to verify that)

.golangci.reference.yml

• The linter must be added to the list 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 Manager.GetAllSupportedLinterConfigs(...) and .golangci.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter doesn't use types: goanalysis.LoadModeSyntax
  • goanalysis.LoadModeTypesInfo required WithLoadForGoAnalysis() in the Manager.GetAllSupportedLinterConfigs(...)
• The version in WithSince(...) must be the next minor version (v1.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The linter should not use SSA. (SSA can be a problem with generics)
• The linter repository should have a readme and linting.
• The linter should be published as a binary. (useful to diagnose bug origins)

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).

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.

Maybe to combine with check from #3488?

Maybe to combine with check from #3488?

I don't want to combine constructor and gofactory because the DDD factory can be a function or separate struct method, not only a constructor.
Also, I think that IssueLoan is more descriptive than NewLoan.

Is there anything else that I can do to get the PR be approved and merged?

Could I resolve the case on Winter Weekends, not now?)
I added unimplemented testcases for the case and also for chan, var declaration, named returned.

2. Case like

type OtherStruct struct {}
type Struct struct {
	Other OtherStruct 
}
func NewStruct() Struct {
	return Struct{
		Other: OtherStruct{}, // warning?
	}
}

Just a reminder for the maintainers: before reviewing the code, the checklist should be handled.

The use of the tests dedicated to linters that need dependencies is not the right way.
The tests should handled as simple linters.

I'm not sure about the pertinence of this linter because Go doesn't require constructors, and data structure is a good pattern, I think this will lead to a lot of false positives.

The use of the tests dedicated to linters that need dependencies is not the right way.
The tests should handled as simple linters.

Do you mean tests should be like this and remove subdirectories?

package gofactory
import "net/http"
func local() {
 _ = http.Request{} // want...
 _, _ = http.NewRequest("GET", "http://example.com", nil)
}

I'm not sure about the pertinence of this linter because Go doesn't require constructors, and data structure is a good pattern, I think this will lead to a lot of false positives.

My motivation was to create the linter for the domain layer with business logic in the factories, which cannot be skipped and where any structures should always be valid.

I agree that using the go-factory-lint in any place is not a good idea, so I added options packageGlobs and onlyPackageGlobs to set domain packages to use the linter only for them.

Should I force set onlyPackageGlobs as true by default and ask to set packageGlobs to run linter?

The use of the tests dedicated to linters that need dependencies is not the right way.
The tests should handled as simple linters.

I removed subdirectories in tests. I'm not sure what you mean.
If not, then you mean that I should remove the use of the WithLoadForGoAnasis option.

I can't because the linter needs this to determine whether it is a function or a type when we cast types like this.

package casting
import (
	"factory/unimplemented/casting/nested"
)
func ToNestedMyInt() {
	_ = nested.MyInt(1) // want `Use factory for nested.Struct`
}