Disable js typechecking by default and adjust tsconfig to be more performant and reduce common errors by configuration less strict

[Buckwich]

Proposed Changes

Discussion basis for HOC

In 5bd8d9e a tsconfig was added with invalid keys, this PR fixes that but I want to make the team aware of the implications.
To remove some errors i also added jsx parsing and other configurations to make tsc behave as much as our js codebase as possible. (its still not perfect)

With https://www.typescriptlang.org/tsconfig/#checkJs a lot of ts error will be shown in vscode, due to the strict config also a lot of complaints of implicit any

Until we have improved our type safety I would suggest to be not as strict. Disabling the following strict checks:

"noImplicitAny": false,
"useUnknownInCatchVariables": false,
"strictNullChecks": false,

As discussed in HOC we don't want to force a wave of errors to our developers and make it an opt-in option. With this PR we don't ship with a default tsconfig (same behavior as previous / before 5bd8d9e). but have a simple way to enable it for those who like it: Copy tsconfig.enable.json to tsconfig.json (which is now gitignored)

Try out

Copy tsconfig.enable.json to tsconfig.json

Open a file in an IDE with TS support. To get a full list of errors just run tsc, its configured to not emit:

npx tsc

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[github-actions]

This Pull Request targets develop branch, but contains fix commits.

Consider targeting main instead.

[Buckwich]

Discussed in HOC: We don't want to overwhelm our devs yet with all the errors that would be thrown. I'll try to come up with a minimal starting tsconfig which should solve most of our type errors but not be as strict as this one

[nikku]

@Buckwich If you need help, please reach out. And thanks for fixing the config 🙂. Apparently it works in my editor, independent of the checkJs casing.

[Buckwich]

I tried to reduce the error count as much as possible but its still 1326 errors in 227 files. At least i can run tsc now without running out of memory.

Based on our discussion in HOC I would suggest that those that don't want to get all those errors in their IDE, overwrite the tsconfig and add it to their global git ignore (alternative would be to do it the other way around)

[nikku]

Why do we need this in addition to adding the @types/* dependency?

[Buckwich]

type acquisition does not work for types specified in the tsconfig itself. As we dont import describe/it/expect this tells which types to use for them, basicly all umdglobal imports.

Alternative would be to always import describe/it/expect in all test files.

[nikku]

What do we need this for?

[Buckwich]

for these kind of error:

alternative would be to always import. But i would do that migration per rule in separate PRs (eg one to import sinon everywhere, one to import describe / expect everywhere)

[nikku]

Why do we need this?

[Buckwich]

without it we would need to add a lot more @types packages, at the moment i only have added the test types as they can't be auto acquired. This is also an IDE setting so we could remove it from the default config

[nikku]

This is a performance enhancement, to prevent out of memory?

[Buckwich]

yes, i had issues running npx tsc without it, also vscode complains about too many files to check without it. Because we have nested node_modules/build the default configs don't work

[jarekdanielak]

@Buckwich do we actually want to merge it soon or does it require more discussion?

[Buckwich]

It can be merged if it is approved and accepted by the team that we will get more errors in the code. I'm already using it, its helpful but the errors can be distracting. And we have to accept that we can't fix all errors if we are in a js project

[jarekdanielak]

And we have to accept that we can't fix all errors if we are in a js project

I kinda don't like that and would prefer to work in a setup where each error is meaningful. 🙁

[Buckwich]

would prefer to work in a setup where each error is meaningful.

the errors are still meaningful, its just a lot of work to fix them as it would require a fully typed source. This is the most common error which could be fixed by adding proper interfaces:

[Buckwich]

I've split the PR, this one contains only the tsconfig adjustments, type fixes are in #5251. Now we don't ship with a default tsconfig (same behavior as previous / before 5bd8d9e). but have a simple way to enable it for those who like it: Copy tsconfig.enable.json to tsconfig.json (which is now gitignored)

[jarekdanielak]

From today's Hour of Code:

Consider having one tsconfig.json file with all the proper settings and incrementally adding more files/folders to with include.