https://github.com/Zegocover/next-route-resolver
There is a bug right now related to query strings being hidden from the visible URL (they're still there as far as Next is concerned), but we'll be fixing that pretty soon.
Not sure if you've seen this guide here, but there is a way to setup dynamic routing with clean URLs that doesn't require adding your own server handler if you use Now v2 for deployments:
https://zeit.co/guides/custom-next-js-server-to-routes/
Also, I recently wrote about how I locally develop Now v2 apps with an example of SSR dynamic routes:
https://medium.com/digital-surgeons-engineering/how-to-set-u...
[1] https://github.com/fridays/next-routes/issues/244#issuecomme...
This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...
Your apps should not be affected at all.
The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.
We're not even "rewriting everything in Typescript at once". We're slowly converting files over one by one. No public APIs are changed. Furthermore, we have an extensive test suite of end-to-end tests for both development and production behavior.
The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app [1] because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon.
Another thing not mentioned in the blog post is they started to rewrite the core of Next.js in TypeScript too, which is a big move!