feat: infer types for waku router

[tylersayshi]

Currently this changeset gets createPages ready to return an inferred type for each response of createPage

TODO:

• Create a union type of all possible paths given the pages
• Pass this union to an override-able interface so waku projects can consume the pages type safety (same as tanstack router's approach)
• Use that type in our <Link /> component
• Update tests and refactor examples to match new api

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
waku	✅ Ready (Inspect)	Visit Preview	Sep 13, 2024 1:50am

[tylersayshi]

@dai-shi & @sandren I just want to mention that while the enforcement of returning the pages here would mean a slight breaking change to createPages, it would unlock theoretically typing anything that is statically defined in each call to createPage

Right now, I am just inferring path, but I intend to follow this up with inferring the full Page object to get things like the staticPaths and render. If we ever wanted to look into things like typesafe query params, this would be an interesting place to add those features in without any further changes to the external api because we have setup the api for returning the static pages which makes them available for inference.

[tylersayshi]

@dai-shi How would you feel about turning noErrorTruncation on in one of the tsconfigs?

I am currently setting this to true locally while developing then leaving it out of my commits, but here is why it is nice for me:

This is without setting noErrorTruncation:

With adding "noErrorTruncation": true,:

[tylersayshi]

Another update here:

All possible paths are being inferred from looking at path, render, and staticPaths on each page response 🥳

[tylersayshi]

Another update here:

...

All possible paths are being inferred from looking at path, render, and staticPaths on each page response 🥳

Just realized that the above screenshot does not handle the catch-all/wildcard static slugs correctly yet, so I fixed that here:

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[tylersayshi]

It's working in the router example now... I plan to revert that example to install from a published node version, but am leaving it in there in case @sandren or @dai-shi want to play around with this in that working example project :)

[dai-shi]

some comments:

[dai-shi]

some more comments 😄

[dai-shi]

hope it makes sense.

[dai-shi]

I was curious about this explicit annotation in other repo.
Does the linked issue commend suggest the explicit annotation?

[tylersayshi]

Yes... it is apparently a known issue with type inference inside pnpm projects with symlinked packages.

After visiting the discord for arktype I was linked to that issue on the Typescript repo that I left in the comments. Here is the summary that I ended up putting on the arktype discord after a chat with their author:

discord link if you'd like to read the full thread

arktype discord if you need a join link

[tylersayshi]

hope it makes sense.

Yep! all makes sense and were simple changes I think. 215e6e2

[tylersayshi]

@dai-shi some idea names for base-types.ts now that it only has the empty interface to be overridden externally:

• external.ts or external-types.ts
• router-types.ts
• public-types.ts

Also, are there other changes you'd like to see with this PR?

[dai-shi]

I'll do a full review later in this week.

[dai-shi]

Otherwise, LGTM. Note that I didn't read the code in detail.

[tylersayshi]

Otherwise, LGTM. Note that I didn't read the code in detail.

Sounds good 👍 - squashed and rebased. Should be good to merge 😄