Strategy for evaluating page files or reading their AST

[tatethurston]

Next's documentation notes the following:

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.

If we import/require the transpiled page files (or read the AST), we can detect whether a page will be optimized. This will also unblock #132 and possibly #39.

A few considerations:

• 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.

[eddiesholl]

Just wanted to add I've created a solution, or you might describe it as a workaround, for the issue. If you can guarantee that the page is not being pre-rendered, then it is safe to assume the router query is always ready. To do this, I've created a helper function that casts the query keys to not undefined, and a custom eslint rule to ensure the helper is only called on pages that also have getServerSideProps defined as well.