chi v4

[pkieltyka]

chi is a pretty minimal library and has been hardened over the years, so v4 won't introduce any big changes other then a few minor things like..

• chi's Go support will be inline with Go's own support - Bring supported versions inline with Go release policy #366 - therefore, we remove support for Go 1.7 and 1.8, and stop tracking 1.9
• return 404 for mux with empty routes Chi should not panic when no routes #362
• additional check to ensure wildcard is at the end of a url pattern Wildcard must be the last pattern in a route but it is not enforced in some cases #333
• middleware: deprecate support for CloseNotifier - http.CloseNotifier is deprecated #347
• Optimal Go module handling Add go.mod file #302 - some community submissions: Bump module version to v3 (again) now that support is backported #364 Add support for go-module #370 [WIP] chi v4 + Go modules #379

:)

[SamWhited]

Hello,

Chi v4 was released, but it still doesn't have module support. Does this mean modules and the proper import path won't be supported until v5 for compatibility?

[pkieltyka]

as mentioned in other issue with the same question.. but for others who follow commits + PR history, will repeat answer here..

@SamWhited yea, it would be chi v5 when we support go modules. I don't see this happening for another 6+ months until go 1.13 is available, in hope the go modules is standard and robust for packages. We had hopes to use go modules now, but ran into a bunch of complexity that didn't make sense to put onto chi which literally has zero dependencies to run, lol.

[SamWhited]

Thank you for your answer; in my previous question I was told v4. I will find an alternative to chi for my own projects and for our corporate projects and reevaluate when Chi v5 is released. Thanks for all the hard work you've put in here.

If you need any help with module support feel free to ping me; there's really not all that much complexity to deal with and I'd be happy to walk you through it if support in v4 is still an option.

[cristaloleg]

I will find an alternative to chi for my own projects

why +incompatible is a problem for you? (just curious).
It's the same version pinning AFAIK. Am I missing something?

[pkieltyka]

@SamWhited good luck!

[SamWhited]

We have several tools in the same codebase that may not all be updated at once. Without the import compatibility rule we have to update them all at the same time to a single version of Chi instead of having one import chi and one import chi/v4, for example. TL;DR — Modules make incremental updates much easier.

[cristaloleg]

What about forking chi (adding Go modules which is trivial) and using replace keyword in go.mod to use the fork?

(probably this is out of scope of this issue)

[SamWhited]

I suspect it will be more overhead to maintain a fork than to just find another router that supports modules, but it's a fair point, we'll have to evaluate both options.

[SamWhited]

@pkieltyka I meant to say: I don't want to ask you for more work, but if you'd be willing to discuss or write up your thoughts on why modules were hard to implement I'm sure the Go team would really appreciate it. You could stick it on the https://github.com/golang/go/wiki/ExperienceReports page, or submit an issue and I can get it in the right hands and make sure it's seen.

[VojtechVitek]

@SamWhited Well, Go modules were not "hard" to implement. See the working prototype for v4.0.0-rc1 tag at #379.

However, @pkieltyka didn't like that this release would would be suddenly forcing all the chi users to change the import path to the /v4 suffix everywhere. The worry was about the amount of support tickets this could generate; and also the additional complexity thrown at chi users.

Chi v4 doesn't differ from v3 very much. In fact, it's backward compatible from the API perspective and backward compatible functionally for 99% of use cases too. However, we dropped support for Go 1.7 and Go 1.8 and we consider that a breaking change; and that's why we preferred releasing v4.0 over v3.4.

We have several tools in the same codebase that may not all be updated at once. Without the import compatibility rule we have to update them all at the same time to a single version of Chi instead of having one import chi and one import chi/v4, for example. TL;DR — Modules make incremental updates much easier.

This is a fair point and Go modules would be "technically" the only right choice for you if you really wanted to have both chi v3 and chi v4 side by side in a single codebase. But as I mentioned previously, we didn't really break the API in the v4 release. So, you should be able to update all of your tools at once without any trouble, either if it's a large monorepo, or if it's a bunch of small repos. Please, correct me if I'm wrong.

As Peter mentioned before, the chi router doesn't have any external dependencies. So, technically, we don't need to define any minimal versions in a go.mod file at all. So, I think this is strictly a choice of taste and simplicity, since the +incompatible flag will work just fine for now.

[SamWhited]

So, you should be able to update all of your tools at once without any trouble, either if it's a large monorepo, or if it's a bunch of small repos. Please, correct me if I'm wrong.

In this case, that is not a risk that we feel is acceptable. I don't know what problems might occur, but that's exactly the point, I don't know. Even if the libraries maintain full API compatibility updating all at once instead of incrementally means there's no time to monitor each component as it comes online for unexpected behavioral changes, panics, or any other bug or minor problem that might have been introduced as part of the upgrade. I'd much rather one service go down than the whole platform.

[VojtechVitek]

@SamWhited That feels like a concern of your deployment strategy rather than of a Go pkg dependency to me.

Anyway, I think you'd have to fork either chi v3 or chi v4 to make a gradual change to your codebase. There's no other way around for now.

[SamWhited]

That feels like a concern of your deployment strategy rather than of a Go pkg dependency to me.

That's correct; previously we were performing gradual updates using vendoring and GOPATH hacks. Now that we've updated to Go Modules this is much simpler, but we have two dependencies outstanding; one of which is Chi. I was waiting on v4, but if Modules are not going to be implemented I'm not sure if we can maintain both upgrade paths, but we'll have to experiment and decide if it's less risky to slowly migrate to something else that uses Modules, or maintain a second way of doing incremental upgrades on top of Modules. Any advice you have on doing this with Chi would be welcome.

Anyway, I think you'd have to fork either chi v3 or chi v4 to make a gradual change to your codebase. There's no other way around for now.

Right.