feat: no longer use tsconfck #892
Conversation
Co-authored-by: Willhoit <[email protected]>
|
QA Looks good. Nice work on the integration tests, I cannot think of another case that we would need to cover. Sidenote: Do we want to account for the fact that |
| const result = await parse(path) | ||
| const tsNodeOpts = mergeNestedObjects(result.extended ?? [result], 'tsconfig.ts-node') | ||
| return {...result.tsconfig, 'ts-node': tsNodeOpts} | ||
| } |
There was a problem hiding this comment.
Do you think anyone in the oclifverse would be using this util? Removing it would be a breaking change. You could leave the export and have it call readTSConfig from src/util/read-tsconfig.ts
There was a problem hiding this comment.
It was never export from src/index.ts so we're able to remove it without it being a breaking change
There was a problem hiding this comment.
Good point. They could grab the export from this file but what we export from src/index is our "contract".
I would wait until someone needs this before taking the time. I generally like to avoid adding support for something that there's not an immediate use case for |
Drop use of
tsconfcklibrary for resolving extended tsconfigs.Fixes #878
Fixes #907
@W-14526758@