-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
feat: typed route ids #13864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: typed route ids #13864
Conversation
🦋 Changeset detectedLatest commit: de26113 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Haha noice! Would you consider two more things ?
export const params = {
limit: 11,
search: ''
}
|
Typing search params would be great but I think that's a separate issue and it shouldn't hold up this PR. As for |
had to bump the test timeout quite a bit, might be worth running unit tests in a separate workflow |
Perfect to have a follow-up PR for searchParams, yeah, let's do this step by step ;) I like to have a common way to manage ALL links (internal & external). <!-- 🤞 before, hardcoded string, error prone -->
<a href="https://bsky.app/profile/jyc.dev">Bluesky</a>
<!-- ✅ after, typechecked route, no more errors -->
<a href={route('bluesky', { handle: 'jyc.dev' })}>Bluesky</a> Today, I just need to feed the config like this: (similar path structure to "create" params) plugins: [
// ...
kitRoutes({
LINKS: {
bluesky: 'https://bsky.app/profile/[handle]',
}
}),
], Of course, it can be a separate issue to think a bit how to feed this info. But in general, what's your feeling ?
|
Not tonight, but let me know where/how I can contribute to this feature. |
@@ -7,7 +7,8 @@ | |||
"target": "es2022", | |||
"module": "node16", | |||
"moduleResolution": "node16", | |||
"baseUrl": "." | |||
"baseUrl": ".", | |||
"skipLibCheck": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need skipLibCheck
? I've tried running pnpm check
without it and didn't bump into any issues for the adapters.
EDIT: Alright, I'm seeing the errors now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of looking into dts-buddy
to see if we can get it to keep the // @ts-ignore
comments in the generated types so that we don't need skipLibCheck
here. It seems like the best way to tell TypeScript "this type doesn't exist yet but will be generated" until something like microsoft/TypeScript#31894 comes along. Do you think this is worth looking into?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth a shot I guess, though dts-buddy is operating on emitted declaration files and I'm pretty sure the comments are lost by that point - might be tricky to correctly recover them from the source
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I managed to get it working in sveltejs/dts-buddy#110 . This should remove the need for the hack in generate-dts.js
to preserve the @ts-ignore
comment.
The ts-ignore is only preserved if it meets these two rules:
- It has to be a multi-line comment
/** @ts-ignore ... */
so that it gets recognised as jsdoc - It has to be above the start of a statement instead of in the middle of it such as in line 26 here https://github.com/sveltejs/kit/pull/13864/files#diff-a174e22e6d675073a963705b97687d42e219c2e05eb1cd6d5811c2581d416a8e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah nice. I don't have time to review that PR right now but I left a comment over there to remind myself to come back and clean this up later
For external links: I could imagine a future addition like this, which should be all that's needed from a configuration perspective: // svelte.config.js
export default {
kit: {
paths: {
external: {
bluesky: 'https://bsky.app/profile/[handle]'
}
}
}
}; |
Just realised that |
Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
#13881 is a PR against this branch that adds additional tests |
Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this only get docs on types? I couldn't figure out anywhere else we reference it.
The following code no longer works when using
link.svelte
href = If using Please let me know if I'm wrong and should do a work around this issue. |
I'm using |
Please open an issue rather than commenting on a closed PR, where it will get lost |
resolves #11386
This is long overdue, but @jycouet goaded me into working on it with the 1.0 release of
vite-plugin-kit-routes
🎉Everyone should have type safety when dealing with routes!
This PR adds a new generated
$app/types
module which exports three types:RouteId
is a union of all the routes in your app ('/' | '/about' | '/blog' | '/blog/[slug]'
etc)RouteParams<T extends RouteId>
is a utility that gives you the type of the params for a given routeLayoutParams<T extends RouteId>
is the same, but also gives you the type of any children ofT
(for example, if you're in the/blog
layout, the route could be either/blog
or/blog/[slug]
, soslug
is an optional paramMost of the time you won't use these types directly, but via things like
page.route.id
andresolveRoute
:I couldn't figure out a sensible way to add a test for this. Maybe someone else can, if not then I'm not too worried about it.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.Edits