BA
Better Authβ€’4w ago
n00ki

TypeScript error with sveltekitCookies after updating to v1.3.4

Hey everyone! πŸ‘‹ I'm experiencing a TypeScript error with the sveltekitCookies plugin, which seems like a regression after updating to the latest versions. I'm getting a type mismatch error when using sveltekitCookies(getRequestEvent):
Argument of type '() => RequestEvent<LayoutParams<"/">, any>' is not assignable to parameter of type '() => RequestEvent<Partial<Record<string, string>>, string | null>'.
Argument of type '() => RequestEvent<LayoutParams<"/">, any>' is not assignable to parameter of type '() => RequestEvent<Partial<Record<string, string>>, string | null>'.
This started happening after updating to the latest version, which includes a change to sveltekitCookies (no longer requires a Promise). I guess i can use as any with a @ts-ignore comment for now, but I'm looking for the proper solution. I believe this error is triggered by TypeScript's strict flag. specifically, the strictNullChecks option. Is this a known breaking change in the recent version? Should the type signature be updated, or is there a different recommended approach? - Better-Auth version: ^1.3.4 - SvelteKit version: ^2.26.1 - Using TypeScript in strict mode - Have svelteKitHandler properly configured in hooks.server.ts - Need the plugin specifically for server action cookie handling Any guidance would be much appreciated! πŸ™
10 Replies
Duki
Dukiβ€’4w ago
Strange I am not getting this error, even tho when hovering over getRequestEvent I can see the same type as you have πŸ€”
But yea, the type seem to have changed/improved on svleteKit's side since 2.26.0 Also, I would recommend adding the comment // @ts-expect-error getRequestEvent type mismatches with what sveltekitCookies is expecting above the plugin line. This way if it ever gets fixed, the IDE will show you a red squiggly line underneath that comment and you can safely remove it then. Its a bit cleaner than casting with as any.
n00ki
n00kiOPβ€’4w ago
@Duki thanks for trying to help! my guess is that you don't have strict: true in your tsconfig.json...am i right?
Duki
Dukiβ€’4w ago
I do
n00ki
n00kiOPβ€’4w ago
i see...this is strange. in my case, when i set the strictNullChecks option to false - the error goes away.
Duki
Dukiβ€’4w ago
I didnt have that in my tsconfig at all, but even when I set it to true I still don't get the error πŸ€” weird πŸ™ˆ
officialankan
officialankanβ€’3w ago
this is happening to me too!
Ping
Pingβ€’3w ago
Mind sharing your tsconfig?
n00ki
n00kiOPβ€’2w ago
i am still unable to resolve this issue. any ideas? @Ping my tsconfig:
{
"extends": "./.svelte-kit/tsconfig.json",
"compilerOptions": {
"allowJs": true,
"checkJs": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true,
"skipLibCheck": true,
"sourceMap": true,
"strict": true,
"strictNullChecks": false, // TODO: remove this once we deal with Better-Auth sveltekitCookies type issue
"moduleResolution": "bundler"
}
}
{
"extends": "./.svelte-kit/tsconfig.json",
"compilerOptions": {
"allowJs": true,
"checkJs": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"resolveJsonModule": true,
"skipLibCheck": true,
"sourceMap": true,
"strict": true,
"strictNullChecks": false, // TODO: remove this once we deal with Better-Auth sveltekitCookies type issue
"moduleResolution": "bundler"
}
}
Ping
Pingβ€’2w ago
This looks fine, can I see the ./.svelte-kit/tsconfig.json?
n00ki
n00kiOPβ€’2w ago
@Ping sure.
{
"compilerOptions": {
"paths": {
"$components": [
"../src/lib/components"
],
"$components/*": [
"../src/lib/components/*"
],
"$models": [
"../src/lib/db/models"
],
"$models/*": [
"../src/lib/db/models/*"
],
"$queries": [
"../src/lib/db/queries"
],
"$queries/*": [
"../src/lib/db/queries/*"
],
"$lib": [
"../src/lib"
],
"$lib/*": [
"../src/lib/*"
],
"$app/types": [
"./types/index.d.ts"
]
},
"rootDirs": [
"..",
"./types"
],
"verbatimModuleSyntax": true,
"isolatedModules": true,
"lib": [
"esnext",
"DOM",
"DOM.Iterable"
],
"moduleResolution": "bundler",
"module": "esnext",
"noEmit": true,
"target": "esnext"
},
"include": [
"ambient.d.ts",
"non-ambient.d.ts",
"./types/**/$types.d.ts",
"../vite.config.js",
"../vite.config.ts",
"../src/**/*.js",
"../src/**/*.ts",
"../src/**/*.svelte",
"../tests/**/*.js",
"../tests/**/*.ts",
"../tests/**/*.svelte"
],
"exclude": [
"../node_modules/**",
"../src/service-worker.js",
"../src/service-worker/**/*.js",
"../src/service-worker.ts",
"../src/service-worker/**/*.ts",
"../src/service-worker.d.ts",
"../src/service-worker/**/*.d.ts"
]
}
{
"compilerOptions": {
"paths": {
"$components": [
"../src/lib/components"
],
"$components/*": [
"../src/lib/components/*"
],
"$models": [
"../src/lib/db/models"
],
"$models/*": [
"../src/lib/db/models/*"
],
"$queries": [
"../src/lib/db/queries"
],
"$queries/*": [
"../src/lib/db/queries/*"
],
"$lib": [
"../src/lib"
],
"$lib/*": [
"../src/lib/*"
],
"$app/types": [
"./types/index.d.ts"
]
},
"rootDirs": [
"..",
"./types"
],
"verbatimModuleSyntax": true,
"isolatedModules": true,
"lib": [
"esnext",
"DOM",
"DOM.Iterable"
],
"moduleResolution": "bundler",
"module": "esnext",
"noEmit": true,
"target": "esnext"
},
"include": [
"ambient.d.ts",
"non-ambient.d.ts",
"./types/**/$types.d.ts",
"../vite.config.js",
"../vite.config.ts",
"../src/**/*.js",
"../src/**/*.ts",
"../src/**/*.svelte",
"../tests/**/*.js",
"../tests/**/*.ts",
"../tests/**/*.svelte"
],
"exclude": [
"../node_modules/**",
"../src/service-worker.js",
"../src/service-worker/**/*.js",
"../src/service-worker.ts",
"../src/service-worker/**/*.ts",
"../src/service-worker.d.ts",
"../src/service-worker/**/*.d.ts"
]
}
OK so it took me some time to figure out, but i think i now understand why this happens... due to recent changes in SvelteKit's type system, the RequestEvent parameters are now more strictly typed. for routes without parameters (like "/"), LayoutParams<"/"> can now be undefined, which doesn't satisfy the previous constraint Partial<Record<string, string>> (see commit https://github.com/sveltejs/kit/commit/a8cc450). as sveltekitCookies only uses event.cookies, i believe we should be able to update the RequestEvent type parameters to use any (RequestEvent<any, any> or something) . i will try my best to submit a PR later todayπŸ™

Did you find this page helpful?