Ability to get parsed tsconfig from `parse()`

[Princesseuh]

Describe the feature

When using parse, we only get the resolved configs (and all the extended configs that contributed), but it's not possible to get the actual config that was parsed.

I'll note that doing config.extended[0] might seems equivalent, but it actually is not because some things are resolved (ex: baseUrl: '.' becomes a filepath)

A Usecase

In Astro, we load the config both for usage to power Vite-stuff like resolving paths and stuff, but also for codemods when using astro add (ex: astro add solid adds the tsconfig.json settings required for Solid). When doing so, we need to operate on the raw config and not on anything modified.

Alternatives Use a second fs.readFile call with toJSON, but it's a bit wasteful.

Additional context Add any other context or screenshots about the feature request here.

[dominikg]

codemods to tsconfig.json are very hard because it can contain non-json characters like comments or dangling commas. (basically the reason toJSON exists and it's not pretty :/) To pull this off you not only need the raw content string, you also need a sourcemap from raw to the output of toJSON so that you can safely write back modifications&additions :thinking:

that would be out of scope for tsonfck itself and the cost for an extra fs.read should be neglegible in the context of astro add.

Remember that in case you use tsconfck with a cache, you are responsible for flushing the cache every time a config changes. This also include removed or added config files within the scope of the app.

[dominikg]

That being said, it it turns out to be just a small amount of code without dependencies and updating tsconfig files is a general need, it could be a nice addition as an extra util outside of parse.

[Princesseuh]

codemods to tsconfig.json are very hard because it can contain non-json characters like comments or dangling commas. (basically the reason toJSON exists and it's not pretty :/) To pull this off you not only need the raw content string, you also need a sourcemap from raw to the output of toJSON so that you can safely write back modifications&additions 🤔

that would be out of scope for tsonfck itself and the cost for an extra fs.read should be neglegible in the context of astro add.

Remember that in case you use tsconfck with a cache, you are responsible for flushing the cache every time a config changes. This also include removed or added config files within the scope of the app.

Oh sorry if this was unclear, we already have all the codemod part done in Astro. I'm not suggesting for that part to be added to tsconfck.

I'd just want parse() to return me fs.readFile(tsconfig).toJSON(). Essentially, here: https://github.com/dominikg/tsconfck/blob/2c61ec7ef228e9bfce3517e19f61ceba0319c8f0/packages/tsconfck/src/parse.js#L76-L84 I'd like to see parsed (without the applied default) be part of the returned object.

[dominikg]

ahh, that would end up in tsconfck cache too, staying in memory all the time. Codemods should be a rare one-time action, i believe it would be less wasteful to just read the file immediately before you want to do the codemod. This also ensures there is no stale cache involved.

[Princesseuh]

ahh, that would end up in tsconfck cache too, staying in memory all the time. Codemods should be a rare one-time action, i believe it would be less wasteful to just read the file immediately before you want to do the codemod. This also ensures there is no stale cache involved.

Okay, that's perfectly fine by me. Thank you for your answers!