feat: add auto detection of module name for goimport

[bosix]

Hi :),

we manage the .golanglint-ci.yml inside a central repo for several projects at our company. The ci/cd-pipeline fetches the current config when the linter is executed (e.g. on branch push).

The problem now is that repo-specific settings like the module name are not possible that way. Currently, golanglint-ci already supports auto-detection of the go version which is determinated via go.mod.

This pr introduces auto detection of the module name for goimport if the user enables it via config. I've thought about setting it be default if local-prefixes is empty but this would lead to a breacking change in linting behaviour. I created this pr as work-in-progress since I want to gather some feedback about this idea before fixing pipeline etc.

[ldez]

Kind of duplicate of #2363

[bosix]

@ldez I agree. It's almost the same.

Do you have changed your mind about the feature? As in #2363 (comment) you wrote that you think the feature has no valid use case.

If you think, it's a valid case, I'll help to make the implementation of sagikazarmark ready to merge.

[ldez]

Do you have changed your mind about the feature? As in #2363 (comment) you wrote that you think the feature has no valid use case.

I still think the same thing

[bosix]

@ldez So the best solution for our centrally managed configuration file would be for the pipeline to determine the module name and inject it into the configuration file, right?
Of course, we could also keep a copy of the configuration file in each repository, but this way changes to the linter rules would not be applied to all repositories immediately.

[ldez]

I have a question: why do you split the module imports and the other imports?
Just to understand the use-case.

[bosix]

@ldez the goal is to make the list of imported modules more cleary. For that reason it's useful to have 3 seperated blocks: one for std-libs, one for 3rd party libs and one for all project internal sub-modules.

[ldez]

Sorry I will deep a bit into the use case: why it's important to show the imported modules more clearly?

[bosix]

@ldez it's most about faster recognizing if we control an importet module or not. Further, we want to make linter rules as strict as possible since we are many developers and want to prevent different formatting which micht be caused by different ides or ide settings.

Theoretically, it would be an option as well if we could enforce that everything has to be in one block but since there is no linter out there which does this our solution is to enforce multiple groups which is stricter than one group.

Allow me one question according to this: why is it ok to auto-detect the go version but not the local go module name? I just want to unterstand the background.

[bosix]

Hi @ldez,

can you give any further information or a notice if there is any chance for this feature to get merged? If not, you can close this pr.

[ldez]

why is it ok to auto-detect the go version but not the local go module name?

I can see several problems related to Go module name: multi-module repo, Go workspaces, runs outside of the root folder, etc.
The Go version is much less problematic, and a "wrong" detection will not change all your code or create a lot of reports.

Also, you are focused on go-import but there is also gci on the same topic.

[bosix]

I therefore assume that the impact of the function, especially if the module detection does not work properly, is too large and therefore not merged.

Thank you for your feedback.