Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

This seems pretty cool, from looking over the documentation. Two things I wish I could do that I don't see in the documentation:

- Replace an import with another import. This is used when forking a go package.

- Rename a package.

It's also pretty unclear from the documentation which operations are "UNIMPLEMENTED", since the label simply falls directly between two different operations. It would be nice if this were made more explicit.

View on HN

It would be great if go.mod file’s replace directive also supported a replace that applies to all downstream users (url to url , not just url to local path) This would allow us to maintain simple forks (ones where you are only fixing a few lines and awaiting PR approval to upstream) but still don’t want to wait for the whole cycle to finish for your own internal company dependencies. I feel this is better than changing all imports.

If you are truly forking with no intention to merge back, isn’t the manual find-and-replace by IDE just fine?

The replace directive does allow you to use a different import path, not just a local path. Unless there's something I'm missing about your use case?

https://golang.org/ref/mod#go-mod-file-replace

Oh I never knew! Thanks. That does simplify a lot

It's important to note that it still doesn't apply to downstream users (those adding your package to their go.mod), only to those building your package directly. I think this decision makes sense, so this is not a complaint.

Can you elaborate? We use `replace` everywhere in our codebase for modules that we've forked + modified.

Assume module A depends on module B, and module B has a dependency on module github.com/C, and a replace rule for github.com/C => company.internal/C.

When you build module A, it will pull module B and module github.com/C, instead of B and company.internal/C, unless A has its own replace directive for C.

The problem I had was that I was forking a monorepo package, so I had to update its internal dependencies to point to the new place. It's possible I missed something, but I don't think I was able to do this with go.mod.

And yes, manually doing the rename "is fine", but I don't think that has any reason to be stated in a discussion about a refactoring tool.

> I don't think that has any reason to be stated in a discussion about a refactoring tool.

Find and replace is the baseline, and for many refactorings is insufficient and fragile, however in replacing a stable, unique, and isomorphic token it is basically as good as it gets, so I think it is relevant. Its probably the least useful thing a refactoring tool could do.

I am not sure. You want to make sure that you are only modifying import statements and those can’t necessarily be identified from just a single line (else you might change an errant URL in a string literal), and you also need to move the files themselves, and update the package line in the files. So sure, you can do it yourself, but why are we building a refactoring tool at all?

Not to mention if the package name itself changes...

Reply on news.ycombinator.com