Option to respect closest tsconfig.json of imported files

[alshdavid]

Search Terms

use nearest tsconfig.json for imported packages

Suggestion

When importing source files which have source that is expected to be compiled using a different tsconfig.json, the compiler will throw errors if the imported source has code which conflicts with the compiler options which the compiler was initialized with.

eg:

/consumer
   index.ts
   tsconfig.json
/target
   index.ts
   tsconfig.json

consumer imports target. consumer has strict: true while the target has strict: false

Add an option to the compilerOptions such as useNearestTSConfigInImports: boolean.

This will help to avoid the necessity of the complex build systems, symlinks and project structures we see in modern multi-package TypeScript projects.

Use Cases

When working with projects that contain multiple services, it's beneficial to abstract and share dependencies which are used across the multiple consumers.

While TypeScript source can be imported from folders arbitrarily, this assumes the source conforms to the configuration in the compilerOptions of the current context.

As soon as the source needs to be shared between consumers developers must:

• Extract the source
• Configure a new compiler
• Compile the source to JavaScript
  • it's important to mention that this is required even if the package isn't being published to npm
• Symlinks created to that package
  • This can get quite complicated if there are post build steps, such as moving folders, etc.

Examples where that might be the case:

• Integrating older, less safe code which doesn't have strict: true yet
• Integrating source which contains uncommon configuration (eg strictBindCallApply)
• Consumer services that use multiple frameworks (react/preact)

This complexity is introduced pretty quickly in projects and would be easily mitigated by allowing the TypeScript compiler the capacity to use the nearest tsconfig as the source of truth for the files nested in the folders below it.

It enable projects written in TypeScript with no consideration of JavaScript until the service was to be published. This results in very clean and easy to traverse repositories.

Something like this is currently possible using comments, eg: adding /** @jsx y */ will override the jsx pragma in the current file.

Examples

Here I have an example repository which breaks, but demonstrates the feature proposal.
https://github.com/alshdavid-sandbox/respect-nested-ts-config

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

Too many flags have global effects that don't make sense to change on a per-file basis. We've discussed this before; see #8405

[alshdavid]

A shame, TypeScript is better than JavaScript in every way but the inability to consume external modules written in TypeScript directly without compilation is a source of massive frustration

[conartist6]

@alshdavid My interpretation is that the javascript module ecosystem is only really expected to work well for sharing javascript module code. Whenever you violate this assumption, much of the tooling that could otherwise help you breaks.

I have encountered similar problems and am working on a solution: simply check the generated .js and .d.ts files into your git repo alongside the .ts sources. Such a setup means that every commit is also an npm package (and one that is interoperable with all other systems and projects which can consume pacakges).

The approach comes with some technical liabilities, like the possibility of stale or malicious checked-in built assets. Your CI server still needs to be able to rigorously verify build correctness. And you really want a bulletproof watcher that doesn't require babying to work. I am currently working on the solutions to these problems in a tool called macrome designed to make the experience safe and seamless. I'm looking for collabs on the project too!