Repository navigation
adapter-cloudflare@1.0.0-next.36 ambient.d.ts breaks DOM manipulation function types #8268
Description
Activity
Presumably you can use a
@ts-ignoreor@ts-expect-errorcomment as a workaround and avoiding this blocking an upgrade?Yes, if I litter enough
@ts-expect-errorin the source it stops complaining. I can make progress now, thank you.(It still shouldn't complain, and now it's just a minefield of what web standard API does Cloudflare break next.)
This also broke a place where I do
const result = (await response.json()) as MyType;with eslint complaining
58:18 error This assertion is unnecessary since it does not change the type of the expression @typescript-eslint/no-unnecessary-type-assertionand that seems to be because Cloudflare overrides response.json to be
json<T>(): Promise<T>;while
node_modules/typescript/lib/lib.dom.d.tssaysinterface Body { readonly body: ReadableStream<Uint8Array> | null; readonly bodyUsed: boolean; arrayBuffer(): Promise<ArrayBuffer>; blob(): Promise<Blob>; formData(): Promise<FormData>; json(): Promise<any>; text(): Promise<string>; }This spooky action at a distance property is like the worst part of Typescript :-(
- added a commit that references this issue
on Jan 12, 2023 - added a commit that references this issue
on Jan 13, 2023
Describe the bug
(This bug also occurs with
@sveltejs/adapter-cloudflare@1.0.0, I'm talking about1.0.0-next.36because that's what introduced the issue.)I need a workaround for an ugly Safari bug, which forces me to do some HTML rewriting before I use
@html. I useDOMParser.parseFromStringand some light DOM manipulation for this. This function is only called whenbrowserfrom$app/environmentis true.Upgrading to @sveltejs/adapter-cloudflare@1.0.0-next.36 broke the Typescript DOM API:
That
childthere is of typeElement, andElement.afterabsolutely should take aHTMLDivElement. Looking up the type definition ofchild.afterin an IDE leads tonode_modules/@cloudflare/workers-types/index.d.tswhich has the incorrectIt seems PR #6917 caused ambient.d.ts referencing Cloudflare's types make them override the DOM API types:
kit/packages/adapter-cloudflare-workers/ambient.d.ts
Line 1 in 4b7fc72
It seems this only triggers if the tsconfig workspace contains a file that actually imports
@sveltejs/adapter-cloudflare. In my case, I havesvelte.config.jsadded to tsconfig so I get useful IDE feedback.Reproduction
https://github.com/tv42/sveltekit-issue-cloudflare-dom
The latest commit has
svelte-checkcomplainingYou can checkout the commit before it switched to @sveltejs/adapter-cloudflare@1.0.0-next.36, run
npm i, and observenpm run checkbe happy.Note how triggering this hinges on the commit that edited
tsconfig.json.Logs
No response
System Info
System: OS: Linux 6.0 NixOS 22.11 (Raccoon) 22.11 (Raccoon) CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz Memory: 36.27 GB / 62.60 GB Container: Yes Shell: 5.1.16 - /run/current-system/sw/bin/bash Binaries: Node: 16.18.1 - /nix/store/gqbqpgmr7s8b3km14m54ys5kilx0akcc-nodejs-16.18.1/bin/node npm: 8.19.2 - /nix/store/gqbqpgmr7s8b3km14m54ys5kilx0akcc-nodejs-16.18.1/bin/npm Browsers: Firefox: 108.0.1 npmPackages: @sveltejs/adapter-cloudflare: ^1.0.0-next.36 => 1.0.0-next.36 @sveltejs/kit: ^1.0.0 => 1.0.1 svelte: ^3.54.0 => 3.55.0 vite: ^4.0.0 => 4.0.3Severity
blocking an upgrade
Additional Information
No response