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.

[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.

[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. Still waiting for feedback.

[kitsonk]

The feedback was "it was impractical to do". It is not something the core team would pursue and likely would not accept a PR for this. Respectfully declined.

[jsejcksn]

@kitsonk I was waiting for your feedback especially.

While I have no trouble with accepting a decision from the core team, it's difficult to understand the rationale behind decision making here, especially after asking for clarity and being met with silence.

It is not something the core team would pursue

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

Terse responses like the ones above don't help me (and everyone else who finds this issue) understand what about the idea is misaligned with the core team's vision for Deno.

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

This comment provides more detail, but is still not clear: is the core team against configuration? Why is it uninteresting?

[kitsonk]

Bartek's comments represented a conversation we had within the core team. You didn't agree with that and wanted to debate it. That is mainly why I didn't provide further comment, because there have been several issues where when given an explanation you want to get into a detailed debate, which I personally find not productive.

We left the issue open to see if there was any other additional feedback from the community. There was one comment in April which said "it would be nice" but didn't fundamentally change anything. There has been no other comments or support for this, which is a clear signal that the cost to implement (high) to the value to the community (low) doesn't make any sense.

[jsejcksn]

Bartek's comments represented a conversation we had within the core team. You didn't agree with that and wanted to debate it.

@kitsonk Is the conversation that you mentioned available for review? I think you're misinterpreting a desire to better understand the rationale behind a decision as desire for debate. There's clearly some additional context beyond what's here in this issue and I'm just trying to learn about that so I can have a more complete perspective.

[swandir]

TypeScript 4.9 iteration plan (microsoft/TypeScript#50457) has two items that might be of interest in context of this issue:

• Investigate Per-File Settings
• Investigate --isolatedDeclaration Emit Mode