DOM Errors: Document is not defined

[ebebbington]

Possible to use any tsconfig with deno lint, or any other way to bypass these errors?

$ cat my_file.ts

...
const prevBody = document.body.children.length;
...

$ deno lint --unstable my_file.ts

(no-undef) document is not defined
    const prevBody = document.body.children.length;

[magurotuna]

As far as I know, there's no way of configuring what variables are defined globally.
Currently the list of global variables is constant, being managed in this file. This list doesn't contain document, so no-undef error was triggered in your example.

I'm not really sure document should be listed here, but I guess it should.
@bartlomieju what do you think about it?

[ebebbington]

Thanks for the response :) I was curious if there's a way about it, currently i am just slapping // deno-lint-ignore no-undef on, and if it helps, my use case is I have code that talks to the DOM (not client side code im trying to lint),and this is exposed via the modules API

So linting is a big part of the project, i guess it isn't 'breaking', but it would be really nice to have :) Though saying that, it seems like document is something that shouldn't be a thing thats enabled by default so a. --config flag. could work well maybe?

But the above is just my opinion

[bartlomieju]

I'm leaning towards accepting more configuration in Rust API for the linter so we can synchronize list of globals based on the lib value in tsconfig.json users are using. I guess we need to use more of the available sets from https://www.npmjs.com/package/globals and add proper API to the Linter; then we can handle that in deno to sniff out what libs user wishes to use.

[kitsonk]

We need to find a way to integrate the linter with TypeScript in the long term so that tsc can be queried and get type information. Maintaining lists of global variables is intenrsincly a bad idea, as any number of things can be changed which impact the global variables.