There's not a lot we can do about this.
We rely upon the types given to us by typescript itself.

If typescript cannot find a type, then it just reports the type as any - it provides no public signal to the consumer that it's an error.

cc @uniqueiniquity - I vaguely remember that vscode can now read the source files if a project (that's referenced in tsconfig) is unbuilt, is that something we should get "for free", or is there some work we need to do to make that work?

VS Code does not rely on the built declarations. Maybe this is relatively new.

In fact, VS Code never uses the .d.ts file (by default?). In fact, you can change a function in one "project", and you don't even need to save the file to see the changes reflected in references to that function from another "project".

I have created another repo of the problem too, as I was running into false positives for the same reasons:

https://github.com/justinbhopper/eslint-issue

1. Run yarn to install dependencies
2. Run yarn lint, observe two false positive lint errors (require-await and restrict-plus-operands)
3. Run yarn build to compile with tsc
4. Run yarn lint, observe no errors
5. Run yarn clean to remove compiled .d.ts files
6. Run yarn lint, observe errors are back

This is a big problem for monorepos and means we end up having to disable ALL rules that require type checking. I think it would help if we could brainstorm on what information would be needed in order to solve the problem.

VS Code does not rely on the built declarations.

Sorry, i think you misread my comment.
I said "vscode can now read the source files if a project (that's referenced in tsconfig) is unbuilt"

This is a "relatively" recent change.

we end up having to disable ALL rules that require type checking

I don't understand, why do you need to disable the rules? If you build the projects, it will work as expected.
We are a monorepo and we use type information rules.

I think it would help if we could brainstorm on what information would be needed in order to solve the problem.

TS provides many compiler APIs for different use cases. The API VSCode uses supports this. The API we use doesn't. We have specific needs which mean we cannot use a different API.

So we need support within typescript for this.
I've been talking offline to the TS team for a little while now about OOM issues and the problems we have juggling many projects.

They've been working on helping alleviate memory issues. There's a number of optimisations that are landing as part of 3.9.

Also, as I found out yesterday, to help with the OOM issues, they've already been working on bringing support to this API for uncompiled project references (which is similarly landing in 3.9)!
microsoft/TypeScript#37370

So what needs to happen? We need to now build out support within this project for the new features.

Unfortunately, the core, volunteer maintainers won't have time to do so for a month or more. So if it's important to you, we'd appreciate the help.

@uniqueiniquity is currently preparing a little guide for this work so that any community member can pitch in.

I don't understand, why do you need to disable the rules? If you build the projects, it will work as expected.

@bradzacher Sorry I wasn't more clear - we have to disable the rules because they give false positives or false negatives during local development, because the compiled definitions end up stale.

The alternative is to only allow linting if a compile occurs first or we use tsc -w during development. Both of which makes no sense to me given that we've setup the typescript-eslint parser.

Closing in favour of #2094