tsdx ignores tsconfig.json "extends" keyword

[justingrant]

Current Behavior

There's an extends feature in tsconfig which allows configuration inheritance across multiple tsconfig files. This however isn't recognized in tsdx, which parses tsconfig here:

https://github.com/jaredpalmer/tsdx/blob/4f6de1083393057903a1837fb6658f8058ee832f/src/createRollupConfig.ts#L46-L49

The JSON object is used as-is, instead of drilling up to resolve parent config.

Expected behavior

tsdx should process extends just like tsc does.

Suggested solution(s)

In a quick look through TypeScript's source code I couldn't find the place where extends is handled, but it's possible that TypeScript's exported tsconfig parsing functions might handle extends for us automatically. See https://github.com/microsoft/TypeScript/blob/760393f893358a462b00eef7e8fb92342b0f71ad/lib/typescript.d.ts#L3639-L3647 what what TS offers in its API. The implementation is here: https://github.com/Microsoft/TypeScript/blob/6487d1ffe0d903b1e55a187ddeb973fe0d445a2f/src/compiler/parser.ts#L717

Additional context

This problem is similar to #483 in that both this issue and that one are caused by parsing tsconfig differently than tsc does.

Your environment

| Software | Version(s) |
| ---------------- | ---------- |
| TSDX | [email protected]
| TypeScript | [email protected]
| Browser | n/a (this is a build issue)
| npm/Yarn | [email protected]
| Node | v12.13.1
| Operating System | MacOS Catalina 10.15.2

[sw-yx]

great qtn. we'll probably want to handle this.

[justingrant]

Hey @sw-yx, what's a "qtn"?

[sw-yx]

qtn = question

[ncphillips]

👍 this would be great for typescript monorepos. Some of the tinacms packages use tsdx for builds. Ideally most of the config would be in the root tsconfig.json with the occasional special case in the package's.

[justingrant]

Echoing @ncphillips, I originally ended up here at tsdx because my project depends on the https://github.com/reach/reach-ui monorepo that uses tsdx and uses extends in tsconfig.json. I wanted to help reach-ui get its declaration maps fixed in its monorepo. But without extends support any fix will involve making changes to ~20 different packages' tsconfig.json files, which is not ideal.

Luckily the only rollup settings pulled direct from JSON by tsdx are esModules (which doesn't actually use tsconfig because of #469) and useTsconfigDeclarationDir (once #468 is merged). In other words, currently this issue has no impact... but it will have impact once those other two issues are resolved.

[sw-yx]

anyone want to tackle this?

[agilgur5]

anyone want to tackle this?

Oh, I already did hah. @justingrant said he didn't have time for this in https://github.com/jaredpalmer/tsdx/issues/483#issuecomment-581238335 so I made the solution myself (see above reference). Still need to add a test for the extends case, hence the draft, but will do that in a day or few as I have to focus on some other things

[sw-yx]

ok. @agilgur5 we're piling up quite a few PR's for jared to review, lets slow down so that we dont swamp him with too much stuff.

[jaredpalmer]

Hrmmm. I thought this worked? Maybe a false positive. Let’s fix

[agilgur5]

Hrmmm. I thought this worked? Maybe a false positive. Let’s fix

@jaredpalmer see https://github.com/jaredpalmer/tsdx/issues/484#issuecomment-581680349 . #483 also has a more detailed description. This is specifically for TSDX-specific options like esModuleInterop. It is already handled by rollup-plugin-typescript2 for the most part, but some tsconfig options affect TSDX too.
Also already made a PR yesterday as I mentioned and referenced above (#489)

[agilgur5]

ok. @agilgur5 we're piling up quite a few PR's for jared to review, lets slow down so that we dont swamp him with too much stuff.

@sw-yx think that might be the first time I've been asked to contribute _less_ 🤔 🤔 🤔

[sw-yx]

i mean i just want to keep it manageable for jared. its not my name on the repo heheh

[ncphillips]

On the mention of contributing _less_, I'm just going to leave this reference to theory of constraints here 😄

[jessekrubin]

This issue drove me absolutely bananas today. Didn’t realize it was happening till I checked out this issue.

[agilgur5]

@jessekrubin are you sure you were facing _this_ issue? As written above a few times, currently this only affects the esModuleInterop setting, and that actually has a bug (#469), so this issue currently has 0 impact on anything (it only has future impact like #468 )

[jessekrubin]

@jessekrubin are you sure you were facing _this_ issue? As written above a few times, currently this only affects the esModuleInterop setting, and that actually has a bug (#469), so this issue currently has 0 impact on anything (it only has future impact like #468 )

I think so. I have several chained tsconfigs; i thought it would be a cool experiment to move a monorepo I have been working on to use tsdx, but it was not as easy as I had hoped. I can do mo reading/fiddling and get back to you. Maybe its possible that my tsconfig extends spaghetti (family recipe) has a problem in it somewhere... the repo does not have the issue with my current rollup setup tho. I do not know. Configuring stuff is far and away my least favorite thing.

[agilgur5]

Sorry, perhaps I should have been more explicit -- whatever your issue is (you didn't provide a repro or describe it), it _can't_ be this.

As was written above already, extends is parsed properly by rollup-plugin-typescript2, which is used under-the-hood. I'll repeat, more explicitly, that TSDX's own processing currently has no impact on userland.

---

i thought it would be a cool experiment to move a monorepo I have been working on to use tsdx, but it was not as easy as I had hoped

There's a few issues around on monorepos, but no one has contributed a PR so far. I don't have any monorepos, so I can't really comment on that.

(family recipe)

this was subtle 😆

[jessekrubin]

As was written above already, extends is parsed properly by rollup-plugin-typescript2, which is used under-the-hood. I'll repeat, more explicitly, that TSDX's own processing currently has no impact on userland.

But what if I am trying to use the babel-loader via extending the tsdx config? uncharted territory?

this was subtle 😆

let me know if you want the recipe. It is quite good, but it makes no sense.

[agilgur5]

But what if I am trying to use the babel-loader via extending the tsdx config? uncharted territory?

No, that still has no impact. The source of this is literally only 5 LoC as you can see in OP and the PR (which makes it even less LoC).

---

As this is almost certainly off-topic, if you're having some issue I'd suggest investigating further and if you strongly believe it's a TSDX bug, making a minimal repro to submit as a separate issue. Talking in hypotheticals isn't really productive.

Here's some possible tips for your debugging.

• I'm not sure if you meant adding a babelrc file or a tsdx.config.js file, but a babelrc file won't have any impact on tsconfig.json as Babel is only run after the TS has been transpiled (TS -> rollup-plugin-typescript2 -> ESNext -> @rollup/plugin-babel).
• If you've added some Babel plugin that _also_ parses tsconfig.json (like @babel/preset-typescript) for some reason, then that's of course a userland issue, not in TSDX.
• Same can be said if you're using tsdx.config.js and added your own tsconfig.json parsing somewhere, that would be in userland, not in TSDX.

[agilgur5]

Repeating here from #483 :

Merged in #489 as I'm now a collaborator. Turns out that ts.parseJsonConfigFileContent is needed to parse extends, but ts.readConfigFile is enough for comments and commas. These are not remotely well documented, so I had to search around other repos to figure out how to do this simply and properly. Can read the PR comments for what I searched through