Deno complains about the Dom

[JorchRL]

The compiler will throw errors because there are no HTML elements (obviously) but that is fine. We are not gonna run three.js on Deno itself, but we will use Deno to bundle it, so it has to compile.

I’ll need to research how. I’ve read about using /// <reference lib=“dom” /> but it doesn’t seem to work as expected. Maybe I messed something up 🤔

[JorchRL]

I added /// < reference lib="DOM" /> to the type definitions on commit 5065e16

But I get type definition conflicts between TS's dom and Deno's (ie. those for Deno's global, web, fetch APIs) :(

My guess is to find a way to let the TS compiler know I only want it to use those of the DOM ?

[JorchRL]

From the Deno docs at targeting deno and the browser

"dom" - The main browser global library that ships with TypeScript. The type definitions conflict in many ways with "deno.window" and so if "dom" is used, then consider using just "deno.ns" to expose the Deno specific APIs.

So the way to go seems to be to let TS know that we don't wan to use "deno.window"

Because by default Deno's compiler behaves as if a tsconfig.json file looked like this

{
  "compilerOptions": {
    "allowJs": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "inlineSourceMap": true,
    "isolatedModules": true,
    "jsx": "react",
    "lib": ["deno.window"],
    "module": "esnext",
    "strict": true,
    "target": "esnext",
    "useDefineForClassFields": true
  }
}

[JorchRL]

I'll try using a deno.json config file with

{
    "compilerOptions": {
        "target": "esnext",
        "lib": [
            "dom",
            "dom.iterable",
            "dom.asynciterable",
            "deno.ns",
            "deno.unstable"
        ]
    }
}

[JorchRL]

It was solved with the solution on the previous comment. On commit 5acbd2e

[JorchRL]

Wait! GitHub closed this automatically from my commit's message! That's cool! :D