Ability to specify type checker version

[dsherret]

Problem: Coupled runtime to specific type checker version

Relates to https://twitter.com/robpalmer2/status/1260863112086982656

Summary: Type checking improvements are not backwards compatible. Coupling users to a runtime with a specific type checker limits them and may cause headaches.

I think coupling the runtime to type checking will be a huge pain for users in the future. Type checking is not backwards compatible—upgrading to a new TS version often means having to fix a decent amount of code. This is especially true since deno uses --strict by default, as that option pulls in any new strict features the TS team adds to the type checker. Once a new strict functionality gets pulled in there, the entire Deno community is going to need to update everything.

Another problem is when a maintainer stops updating their TS code. Previously with Node.js this was less of an issue because the TS compiler would only type check the public API (and now they've disabled even doing that in their default tsconfig.json), but Deno type checks even the private implementation of all imported TS code. I don't want to know about type checking errors buried in someone else's code because of a new version of TS. That said, I'm sure this must have been discussed somewhere (?) and there are mitigation solutions that could be done for this with the existing design.

Most importantly, the current state of affairs also means that teams are coupled to a certain runtime and with a specific type checker. They can't always easily upgrade the runtime to get new runtime features without needing to possibly spend hours fixing type checker errors (ex. I just spent 30 minutes upgrading a very small project to 3.9 today). It would be nice to be able to flip back and forth between different runtime versions without having to worry about type checking errors. That said, something like --no-type-check would solve this.

Solution 1: Specify ts version for deno run?

deno run my-file.ts --ts-version 3.8.3

On first run, this would download TS 3.8.3, store it in a cache, then type check the files with that compiler version.

Solution 2: Separate command?

Something like what I mentioned in #4323 (comment):

# or something along these lines
deno type-check --ts-version 3.8.3

Same deal of downloading and caching the version. This has the added benefit of code being run in the runtime would be super fast and the executable size would go down.

[kitsonk]

Personally, I would prefer the option to not type check TypeScript versus maintaining multiple versions of TypeScript in Deno. It is already hard enough keeping one version. It is like trying to continue to support ES3 or IE6... I know it breaks code, but that is a good thing. If folks have a no-check option, they can just choose to abandon type safety but still use TypeScript code.

[dsherret]

If Deno went the second way, I think it could probably just be a very thin wrapper around tsc. That API has been consistent. I get making it work with deno run would probably be challenging... perhaps there could be a range of supported versions.

[ry]

Presumably if new type-check errors show up in new versions of your code, you would want to address those. We should definitely have a way of bypassing the type-checker... but I'm not sure I want to add infrastructure to specify which version of TS you're checking against. Sounds arduous with little gain.

[dsherret]

@ry The main pain point is not necessarily problems in my code, but new type checking problems in the private implementations of libraries being depended on. Now that I think about it more this morning, there are probably better solutions and I don't think specifying a compiler version solves my concerns because some dependencies might work in one compiler version and others another version.

For example, what might be better is (and perhaps deno supports a way of doing this already?):

1. Not type checking the private implementations of downloaded modules.
2. Having something like skipLibCheck that skips type checking of downloaded modules or the ability to disable type checking for certain downloaded modules.

Yeah, I think this would only be viable if if type checking worked the second way I mentioned. Anyway, this issue was mainly exploratory.

[dsherret]

I've opened #5460. I think that solves most of my concerns.

I'm going to close this as I don't think it's a viable/practical solution.