github.com/go-chi/chi breaking changes

Major update to chi library with many exciting updates, but also some *breaking changes*

Support for regexp for routing patterns, in the form of `/{paramKey:regExp}` for example:

Add `Method` and `MethodFunc` to `chi.Router` to allow routing definitions such as

Add support for LINK/UNLINK http methods via `r.Method()` and `r.MethodFunc()`

Moved the chi project to its own organization, to allow chi-related community packages to

*NOTE:* please update your import paths to `"github.com/go-chi/chi"`

Deprecating `mux#FileServer` helper function. Instead, we encourage users to create their

For me, the aesthetics of chi's code and usage are very important. With the introduction of Go's module support (which I'm a big fan of), chi's past versioning scheme choice to v2, v3 and v4 would mean I'd require the import path of "github.com/go-chi/chi/v4", leading to the lengthy discussion at https://github.com/go-chi/chi/issues/462. Haha, to some, you may be scratching your head why I've spent > 1 year stalling to adopt "/vXX" convention in the import path -- which isn't horrible in general -- but for chi, I'm unable to accept it as I strive for perfection in it's API design, aesthetics and simplicity. It just doesn't feel good to me given chi's simple nature -- I do not foresee a "v5" or "v6", and upgrading between versions in the future will also be just incremental.

`chi` dates back to 2016 with it's original implementation as one of the first routers to adopt the newly introduced context.Context api to the stdlib -- set out to design a router that is faster, more modular and simpler than anything else out there -- while not introducing any custom handler types or dependencies. Today, `chi` still has zero dependencies, and in many ways is future proofed from changes, given it's minimal nature. Between versions, chi's iterations have been very incremental, with the architecture and api being the same today as it was originally designed in 2016. For this reason it makes chi a pretty easy project to maintain, as well thanks to the many amazing community contributions over the years to who all help make chi better (total of 86 contributors to date -- thanks all!).

My apologies to the developers who will disagree with the decisions above, but, hope you'll try it and see it's a very minor request which is backwards compatible and won't break your existing installations.

Cheers all, happy coding!

(2020-11-12) - now with go.mod support

Chi has been a labour of love, art and engineering, with the goals to offer beautiful ergonomics, flexibility, performance and simplicity when building HTTP services with Go. I've strived to keep the router very minimal in surface area / code size, and always improving the code wherever possible -- and as of today the `chi` package is just 1082 lines of code (not counting middlewares, which are all optional). As well, I don't have the exact metrics, but from my analysis and email exchanges from companies and developers, chi is used by thousands of projects around the world -- thank you all as there is no better form of joy for me than to have art I had started be helpful and enjoyed by others. And of course I use chi in all of my own projects too :)

For existing projects who want to upgrade to the latest go.mod version, run: `go get -u github.com/go-chi/[email protected]`, which will get you on the go.mod version line (as Go's mod cache may still remember v4.x). Brand new systems can run `go get -u github.com/go-chi/chi` or `go get -u github.com/go-chi/chi@latest` to install chi, which will install v1.5.0+ built with go.mod support.