Update module name to include version 3

[r6q]

Issue: We want to use latest version of this module as part of toolchain, but the latest version is greater than v0 or v1 and the module name does not specify higher version.

How to reproduce: execute go get github.com/antham/ghokin

Expected:

require (
    github.com/antham/ghokin/v3 v3.1.0
)

Actual:

require (
    github.com/antham/ghokin v1.7.0
)

Another option would be do release latest code under v1.8.0 and disregard updating major version in the future and stick to v1

I'd make a PR myself, but the repo doesn't have Makefile, I am too lazy to launch it myself.

[antham]

Hi, thanks for reporting .

This repository is not designed to be used as a library so that's why we have that, I didn't pay attention to the api so I don't know if it's really convenient to use.

There is no need for a Makefile, usual go command are enough, there is no special setup.

This is fixed in the v3.2.0.

[r6q]

No, no, not as a library, but rather a developer tools as module dependency

tldr; you would have github.com/antham/ghokin as dependency in go.mod and two targets in Makefile

install-tools:
    go install github.com/antham/ghokin # add more tools below or shell for loop to iterate over tools.go file

format:
    ghokin fmt replace features/

And company new joiners just clone the repo, run make install-tools once and they have correct version binary installed on their machine.

This is the most common approach for 3rd party binaries. I would never install a binary manually.

Anyways, big thanks for a quick reaction on this issue.

[antham]

I don't see the point of cloning the repo when you can just go in the release and pick the binary, it's the purpose of a release otherwise you need to install the whole go toolchain to get the tool plus you do not take the advantage of having a language that compile to static binaries.

But you are right on the fact that we miss an easy install with most common packaging tool and I realize i did not take in account the fact that now mac os run on an arm architecture as well.

[r6q]

I don't see the point of cloning the repo when you can just go in the release and pick the binary

By cloning the repo I didn't mean cloning this repo, I mean a person joins company X, then goes to company's git repo, clones whatever project they will be working on, and afterwards the new joiner just needs to execute one make command which automatically installs this binary. That is the primary option and the best option.

The next next one would be just running go install github.com/antham/ghokin so it installs the binary into the go path if you are doing some prototyping work in go in your free time.

The the last resort would be as you said downloading binary manually from github and moving it to /usr/local/bin or whatever location. Which should be only used if you don't use go, but still want a formatter for java or whatever project.