Configurable option for isolated type-checking of modules

[jsejcksn]

If it's helpful, you might think of this like the isolatedModules compiler option, but for types.

In order to allow for the modules in a type-checked program's graph to use incompatible and exclusive ambient types, it is necessary to offer the ability to type-check modules in isolation. That way, when different modules use triple-slash references (or—even better—separate deno configs!), those types don't leak into other module code (causing type-checking conflicts and/or the potential for uncaught runtime errors).

This primarily addresses the use of Deno as a compiler (and/or bundler) of code which is then executed in another runtime environment (like a browser with puppeteer, or for evaluation by Node.js in a subprocess, etc.).

Refs:

• Types and execution context (evaluation functions): suggested patterns lucacasonato/deno-puppeteer#46
• disable certain global types for specific files, or specify type roots for specific files. microsoft/TypeScript#37053
• Support deno.config in a multi-root workspace vscode_deno#501
• [Feature Request] Support multiple tsconfigs in the same repository vscode_deno#488

[bartlomieju]

@kitsonk please take a look

[bartlomieju]

I believe this is impractical to do. We should be converging on a single configuration instead of adding possibility to use separate configs per file.

Besides very hard implementation it would be also very hard to configure for users. I can see the appeal of this feature, but I believe it's the opposite direction the ecosystem should be going. This is actually the same problem as import maps per "library" - there is no support for merging import maps and it's questionable how that would work - ie. how do you specify that your library/package requires concrete import map (or TS configuration file) to work properly.

[jsejcksn]

We should be converging on a single configuration instead of adding possibility to use separate configs per file.

I believe it's the opposite direction the ecosystem should be going.

@bartlomieju Can you link to information about the project that informs your opinion (or will you explain that here)? I'd like to better understand why you don't think that Deno should provide the ability to execute scripts (in a type-safe way) which act as a top-level instruction set for orchestration of tasks (which may or may not execute in other runtimes). I was always under the impression that Deno existed to fulfill purposes just like this.

I agree that implementation wouldn't be trivial (and — AFAIK — it would actually be novel in regard to a compilation ability: making Deno even more useful/desirable as a runtime).

In regard to your import map analogy: I expect this to be used by end-users: meaning that if a library provider utilizes this feature somehow, it would be only an implementation detail (e.g. running in a forked process), opaque to any downstream users (for exactly the reason you mentioned).

[jsejcksn]

I haven't thought extensively about implementation, but I imagine that it would require the ability to instruct the compiler to "reset" its type environment at certain points in the module graph (using either a config file or some kind of inline module directive, like a deno directive or yet-to-be-invented triple-slash reference): so that, in those branches downstream of those points in the graph (for those modules and their participating dependencies), an isolated type environment can exist which would potentially have conflicts with the upstream type environment.

According to my current (limited) understanding of the the TypeScript compiler API, this is impossible: so it would mean forking new compiler instances at these points in the graph, and then somehow forwarding the results upstream.

This would mean that, even though the conflicting ambient types could be used without issue in the modules being evaluated in the forked compiler process, they probably couldn't be used in the public-facing types of any exports (what would appear in a compiled declaration file) because those would need to be forwarded back upstream.

(I can put together a simple example of modules from such a conflicting graph: just let me know if you think it's needed.)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[jsejcksn]

Not stale

[swandir]

Some options, like jsx, can already be configured on a per file basis. It could make sense for other options too.

TypeScript has the Project References feature, which together with skipLibCheck allows for compilation isolation.

But global definitions, once added in the compilation, will leak through project boundaries via imports.

I wish something like type narrowing for the global scope existed 😅

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[jsejcksn]

Not stale

Edit: I think stale bot might be broken.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.