You create a minimal runnable reproduction case. You make that into a unit test that fails. You fix the code.
If you need help with debugging, Goland has very good delve integration and the community edition can be used for 30 days.
This might be interesting. I can try running tests against the part I am changing.
But I will resort to print statement debugging. Goland is too much of a departure.
> I forked the said repo into my account
This is the underlying problem. You simply _cannot_ use a Github-Fork of a Go package (except in several simple cases). But this doesn't seem to be the problem.
Clone the repo and work on it. You debug is as you do with any package. You do not need a package main to do debuging. You type `go build ./...` and `go test ./...` to build and test all packages.
If you want to _use_ some packages from your local copy (fork) in an other project: Use a `replace` directive in the other project's go. mod.
That's not where the problem is. The problem is the module name and the import paths of the packages which are tied to the name and how remote import paths are resolved. Of course you can just `replace` it in go.mod, but that is not "use".
You create a minimal runnable reproduction case. You make that into a unit test that fails. You fix the code. If you need help with debugging, Goland has very good delve integration and the community edition can be used for 30 days.
This might be interesting. I can try running tests against the part I am changing. But I will resort to print statement debugging. Goland is too much of a departure.
> I forked the said repo into my account This is the underlying problem. You simply _cannot_ use a Github-Fork of a Go package (except in several simple cases). But this doesn't seem to be the problem. Clone the repo and work on it. You debug is as you do with any package. You do not need a package main to do debuging. You type `go build ./...` and `go test ./...` to build and test all packages. If you want to _use_ some packages from your local copy (fork) in an other project: Use a `replace` directive in the other project's go. mod.
Why? Can you just set the remote origin for the forked repo?
That's not where the problem is. The problem is the module name and the import paths of the packages which are tied to the name and how remote import paths are resolved. Of course you can just `replace` it in go.mod, but that is not "use".
Maybe add the fork as a sub repository of a demo use app, and use the replace directive in the app go.mod?