Add a option of type inheritance from extended tsconfig #57616
Description
🔍 Search Terms
- tsconfig inheritance
- tsconfig paths merge
- tsconfig extend paths
- TypeScript configuration extension
- TypeScript path resolution
✅ Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/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, new syntax sugar for JS, etc.)
- This wouldn't change the runtime behavior of existing JavaScript code
- This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Introduce a mergePaths option for tsconfig.json that would be false by default allows for the merging of paths from the extended tsconfigs files and the current configuration.
📃 Motivating Example
In a monorepo setup, there's often a base tsconfig (e.g., tsconfig.base.json) at the root, containing global paths that are accessible to all packages (package public API). However, individual packages may also require their own, package-specific absolute paths for various reasons, such as linting or to simplify imports.
Currently, when a package's tsconfig.json extends the root tsconfig, any paths defined in the package's tsconfig overwrite those from the base. This behavior requires developers to replicate the base paths in every package's tsconfig, leading to maintenance overhead and potential for inconsistency.
💻 Use Cases
- What do you want to use this for?
- Monorepo Management: In a monorepo setup, managing shared and package-specific paths efficiently without duplication.
- Simplified Configuration: Reducing configuration overhead and potential for errors by not having to duplicate shared paths across multiple tsconfig.json files.
- Enhanced Developer Experience: Streamlining the development process within monorepos by ensuring smooth path resolution across packages.
- What shortcomings exist with current approaches?
- Duplication of path configurations across multiple tsconfig.json files.
- Increased maintenance overhead and potential for inconsistency.
- The current need to manually merge paths in each package's tsconfig.json, which is error-prone and cumbersome.
- What workarounds are you using in the meantime?
There are currently few workarounds that I know:
- manually duplicating shared paths in every package's tsconfig.json, adjusting as necessary to avoid conflicts
- utilizing scripts to dynamically generate tsconfig.json files with merged paths, which adds complexity
- just adding the path to the monorepo root tsconfig (not really workaround)