AbortSignal.reason not available in lib.dom.d.ts
#14344
Comments
|
You are using the |
lucacasonato
changed the title
AbortSignal.reason not available in lib.dom.d.ts
|
I'm still confused.
What can we do to overcome this? As far as I can tell I'm not doing anything incorrectly in // @ts-check
/// <reference no-default-lib="true" />
/// <reference lib="dom" />
/// <reference lib="dom.iterable" />
/// <reference lib="dom.asynciterable" />
/// <reference lib="deno.ns" />
/// <reference lib="deno.unstable" />Are you suggesting not writing type safe code that uses the DOM, so as to avoid the |
No your std version also changed. 0.136 was released on 3 hours ago. |
The only thing that makes a difference between working or not is the Deno version. |
Because |
|
Thanks, What can be done in project code to overcome this? I still can't tell what I've done wrong, if anything. Just downgrade Deno and wait for a future version with an updated TS |
|
TS triple slash lib references are only meant to apply to the module with the comment in it and down in the module graph. As far as I can see, no module is referencing that Edit: Maybe that's not true, when you factor in imported types in JSDoc type comments. Also, the React types from esm.sh might set the deno info --import-map=importMap.json useOnClickRouteLink.mjsOutput |
This is due to the new change that is gonna happen in Deno 2.0 (most likely). Typechecking is super slow especially once you get alot of bigger deps. Therefore it will be the modules responsibility to typecheck their code (which they already do because of unit tests, benchmarks and testing their code manually) and your responsibility to typecheck your's rather than you typechecking everything. |
|
@jaydenseric the explanation for |
No, they're global. There's no way to do that in TS at the moment :( |
|
Thanks for the responses. I'm losing confidence there is a workable way to have type-safety in dual Deno/browser codebases, which is one of main practical uses of Deno 😩 It now seems like an anti-pattern to use // @ts-check
/// <reference no-default-lib="true" />
/// <reference lib="dom" />
/// <reference lib="dom.iterable" />
/// <reference lib="dom.asynciterable" />
/// <reference lib="deno.ns" />
/// <reference lib="deno.unstable" />For example: The Just the act of loading the For example, TypeScript accounted for But that won't make it into TypeScript until v4.7, which isn't planned for release until May 24th (a month away): Presumably it won't be available in Deno until a little bit after then: Perhaps we need a totally different approach to using DOM globals in a type safe way. Ideally there would be a way to use typed DOM APIs within just part of a Deno module, for example within a React Maybe make a library of DOM API types that can be imported inline, on demand: // @ts-check
const doc = /** @type {import("dom-types/document.mjs")} */ (
// @ts-ignore This really does exist.
document
);
cost foo = doc.getElementById("bar");This is assuming TypeScript itself couldn't be enhanced to have a way to declare the type of a particular thing in a particular scope. Perhaps a JSDoc // @ts-check
// This module scope sometimes runs in a non-DOM Deno environment.
import { useEffect } from "react";
export default function Foo() {
useEffect(() => {
// This function scope only ever runs in a DOM environment.
/** @typedef {import("dom-types/document.mjs")} document **/
cost a = document.getElementById("b");
cost c = document.getElementById("d");
}, []);
return null;
}We need a documented right way to do universal Deno/browser code ASAP; we can't really have the confidence to practically use Deno or publish Deno modules until there is. |
|
Given the example of code such as this: export const foo = () => {
return document.createElement("div");
};generic TS code with DOM typings is correct in saying that this function is fine and all types are correct. Deno is also correct in saying that the body of the function contains an error and the types reflect that error properly. TS wise the existing ways to work around this issue would be either I wonder if Deno could implement its own Another thing I wonder about is what happens if instead of triple-slash referencing you actually properly import the type declaration file? Would that then keep the type declarations inside the module subtree? EDIT: Direct import does not keep the types inside the module subtree :( |
|
I'm also hitting this and don't know what to do. I'm a relative newcomer to deno, so maybe it's just me. My deps blow up when I uncomment import { Component } from "https://deno.land/x/nano_jsx@v0.0.30/mod.ts";
export type ReactNode = Component | Component[] | string | string[] | number | number[]
export * from "https://deno.land/x/nano_jsx@v0.0.30/mod.ts";
export { tw } from "https://cdn.skypack.dev/twind";
export { default as Prism } from "https://esm.sh/prismjs@1.28.0";
export { escape as htmlEscape } from "https://esm.sh/he@1.2.0";
export { emojify } from "https://deno.land/x/emoji@0.1.2/mod.ts";
export { default as twas } from "https://esm.sh/twas@2.1.2";
// export { CSS, render as gfm} from "https://deno.land/x/gfm@0.1.20/mod.ts";error: TS2339 [ERROR]: Property 'reason' does not exist on type 'AbortSignal'.
return Promise.reject(createAbortError(signal.reason));
~~~~~~
at https://deno.land/std@0.136.0/async/abortable.ts:27:51
TS2339 [ERROR]: Property 'reason' does not exist on type 'AbortSignal'.
const abort = () => waiter.reject(createAbortError(signal.reason));
~~~~~~
at https://deno.land/std@0.136.0/async/abortable.ts:30:61
TS2339 [ERROR]: Property 'reason' does not exist on type 'AbortSignal'.
throw createAbortError(signal.reason);
~~~~~~
at https://deno.land/std@0.136.0/async/abortable.ts:46:35
TS2339 [ERROR]: Property 'reason' does not exist on type 'AbortSignal'.
const abort = () => waiter.reject(createAbortError(signal.reason));
~~~~~~
at https://deno.land/std@0.136.0/async/abortable.ts:49:61
Found 4 errors.Is there a workaround other than not using the |
|
I ended up working around this by adding the following to my declare global {
interface AbortSignal {
reason: string;
}
} |
|
Just trying Deno out for the first time, and ran into this. It seems that deno.json: {
"compilerOptions": {
"lib": [
"dom",
"dom.iterable",
"dom.asynciterable",
"deno.ns",
"deno.unstable"
]
}
}hello.ts: console.log("hello world");Simply turning on For now I've gotten around it by passing in |
Closes: denoland#12558 Fixes: denoland#14344
Something has changed in deno v1.21.0, as upgrading from v1.20.6 has caused TS errors to fail tests that used to run fine:
deno test \ --unstable \ --allow-env \ --allow-net \ --allow-run \ --allow-read \ --allow-write \ --import-map=importMap.jsonThat output implies there is some kind of type check issue in
useOnClickRouteLink.test.mjs, but the Deno LSP doesn't surface any in VS Code when looking at the module, and according to the newdeno checkcommand there are no type check issues with it:The text was updated successfully, but these errors were encountered: