During prerendering, the router's query object will be empty since we do not have query information to provide during this phase. After hydration, Next.js will trigger an update to your application to provide the route parameters in the query object.
To ensure type safety, nextjs-routes assumes every page is optimized. This requires that clients always use router.isReady to narrow the router.query type when using useRouter.
We may need to use the user's webpack configuration, to handle arbitrary ast extensions (JS/TS/JSX/TSX are examples). Those examples may be sufficient coverage, rather than supporting any possible ast extension.
In development, next lazily transpiles source files, so we may not have the full route picture. We shouldn't force evaluation of all page files, instead any code generation should likely become iterative. This will require updating the generated file via ast tooling rather than rewriting the whole file.
There will be some tradeoffs here wrt complexity, we may need to investigate a few different solutions to minimize the amount of complexity this package takes on.
Next's documentation notes the following:
To ensure type safety, nextjs-routes assumes every page is optimized. This requires that clients always use
router.isReadyto narrow therouter.querytype when usinguseRouter.If we
import/requirethe transpiled page files (or read the AST), we can detect whether a page will be optimized. This will also unblock https://github.com/tatethurston/nextjs-routes/issues/132 and possibly https://github.com/tatethurston/nextjs-routes/issues/39.A few considerations:
There will be some tradeoffs here wrt complexity, we may need to investigate a few different solutions to minimize the amount of complexity this package takes on.