-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
docs: add note about installing workers types #11731
Conversation
|
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.
Unless something has changed the using the Cloudflare adapter will already install these types for you and make them globally available - I suggested a similar change to the docs a while back but we didn't go for it because of that
Doesn't seem to be working for me either 🤔 @benmccann any ideas? You mentioned this to me last time |
I'm really not the person to ask about TypeScript intricacies. Certainly if the types were available just from installing the adapter that would be nicer than if the user had to manually set things up. I do see they're listed in the |
Additionally, the types are missing for the other properties declared by the adapter. I can get it working if I reference at least
- import { Cache, CacheStorage, IncomingRequestCfProperties } from '@cloudflare/workers-types';
+ /// <reference types="@cloudflare/workers-types" />
declare global {
namespace App {
export interface Platform {
context?: {
+ /**
+ * Extends the lifetime of the fetch event. It accepts a Promise-based task which the Workers runtime will execute before the handler terminates but without blocking the response. For example, this is ideal for caching responses or handling logging.
+ * @param promise
+ */
waitUntil(promise: Promise<any>): void;
};
+ /**
+ * The [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) API
+ * allows fine grained control of reading and writing from the [Cloudflare global network](https://www.cloudflare.com/network/) cache.
+ */
caches?: CacheStorage & { default: Cache };
+ /**
+ * Contains information about the [request](https://developers.cloudflare.com/workers/runtime-apis/request/#incomingrequestcfproperties)
+ * provided by Cloudflare’s global network.
+ */
cf?: IncomingRequestCfProperties;
+ /**
+ * Contains your project's [bindings](https://developers.cloudflare.com/pages/functions/bindings),
+ * which consist of KV namespaces and other storage objects.
+ */
+ env?: {
+ [key: string]: D1Database | DurableObjectNamespace | KVNamespace | R2Bucket;
+ };
}
}
}
+
+ export {}
// this file is generated — do not edit it
/// <reference types="@sveltejs/kit" />
// maybe only include the reference if the adapter is found in package.json?
+ /// <reference types="@sveltejs/adapter-cloudflare" />
... |
@Rich-Harris this will need a rebase since I merged #11732 |
Recently, I used TypeScript nightly in VSCode and this wasn't an issue anymore. Maybe I'll need to check again if it was just a fluke or if it also works without TypeScript nightly. |
Alright. So apparently I was importing something from So the minimum someone would need to do is add a reference to the adapter package in their + /// <reference types="@sveltejs/adapter-cloudflare" />
// See https://kit.svelte.dev/docs/types#app
// for information about these interfaces
declare global {
namespace App {
// interface Error {}
// interface Locals {}
// interface PageData {}
// interface PageState {}
interface Platform {
env: {
example: D1Database; // we get our types!
}
}
}
}
export {}; But it'd be even nicer if we could get rid of this step and just have the types available by including a reference to them in the generated sveltekit ambient declaration file. |
Adding a note here from #12088 (comment) It was suggested to not automatically include the cloudflare types globally because they pollute the ambient types namespace. |
preview: https://svelte-dev-git-preview-kit-11731-svelte.vercel.app/ this is an automated message |
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.
We already explicitly import the Cloudflare types in the docs. Therefore, people should know about installing the workers types package. The types can be made available globally if the user sets it up themselves. We also decided not to do this automatically because it pollutes the ambient namespace
stumbled on this while working on #11730