question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Add `extendsExact: bool` property to tsconfig.json

See original GitHub issue

Search Terms

Lerna monorepo, extends, config inheritance, disable relative path.

Suggestion

According to design choise of extends property to make paths relative - it brings some problems for monorepos with multiple packages with different configs.

I suggest to add extendsExact: bool property to tsconfig.json which will keep paths as is (without resolving relative paths)

It quite simple to implement with current codebase and allows to developers use different scenarios.

Use Cases

We cannot use base template for all packages (we have 20 packages and need to fix in every config includes and excludes sections). It quite hard to track. If we add something to base template, we should to change all tsconfigs in every package.

My real use case is quite complex. We have boilerplate repo, where defined all configs, dev packages and code conventions. I maintain this MAIN repo. All other developers fork my repo and adds their code to packages folder (in Lerna way) where use some of config from root folder for their packages. So at any time I may update my boilerplate (MAIN repo) and all other teams may easily merge my changes without affecting their code in packages folder.

Examples

We have a base configs:

// tsconfig.server.json
{
  excludes: ["node_modules"],
  includes: ["src/**/*.ts", "server.globals.ts"]
}
// tsconfig.client.json
{
  excludes: ["node_modules", "__tests__"],
  includes: ["src/**/*.ts"]
}

And in Lerna monorepo developers may use these tsconfig as real dumb template:

tsconfig.server.json
tsconfig.client.json
lerna.json
packages/
 - pkg1-server
     - tsconfig.json { extends: '../../tsconfig.server.json', extendsExact: true } 
 - pkg1-client
     - tsconfig.json { extends: '../../tsconfig.client.json', extendsExact: true }      
 - pkg1-client-admin
     - tsconfig.json { extends: '../../tsconfig.client.json', extendsExact: true } 
 - pkg2-node-driver
     - tsconfig.json { extends: '../../tsconfig.server.json', extendsExact: true } 
 - ... tons of other packages ...

So with such monorepo I can just change root config file, and all packages gets new config with EXACT paths for (files, includes, excludes) like they are in root config files.

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.

Issue Analytics

  • State:open
  • Created 5 years ago
  • Reactions:26
  • Comments:5

github_iconTop GitHub Comments

2reactions
NoelAbrahamscommented, Mar 25, 2019

I think this will also fix #29172.

1reaction
zheeengcommented, Oct 30, 2019

It is useful to the monorepo project which its sub packages all have a same tsconfig.json configuration but need they own outDir and typeRoot

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found