fix(deps): downgrade tsconfck

[dmitry-stepanenko]

Description

tsconfck has been updated as part of #15803. New version of the package causes qwik build to fail when tsconfig is used with "references". It might affect other frameworks or use cases, but I haven't tested those.

Looks like this is a known issue on the package's side dominikg/tsconfck#154, however it remains not fixed as of now. The suggestion is to keep the dependency on the lower version that does not cause any issues

Please see reproduction details on the related issue #15870

Additional context

closes #15870

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines, especially the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Update the corresponding documentation if needed.
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[dominikg]

the newer version fixes a bug that could lead to silent use of incompletely extended tsconfig so i don't think this is the right way.

[dominikg]

see this comment how to restructure tsconfig with references to avoid it until fixed aleclarson/vite-tsconfig-paths#132 (comment)

[dmitry-stepanenko]

see this comment how to restructure tsconfig with references to avoid it until fixed aleclarson/vite-tsconfig-paths#132 (comment)

The main problem is in the qwik-nx package, that creates a few tsconfigs per qwik project. Of course I could fix it for my own project, but I don't think it is the right way to propagate workarounds to the consumers of the package.

There might be bugs that are fixed by the 3.0.2 patch release, but now applications does not compile at all. Having all projects to implement a workaround is definitely wrong way of working around this.

Right now I'm limiting the vite version there to the ~5.0.0 on qwik-nx's side, but that will work only temporarily..

[dominikg]

regardless of the outcome here qwik-nx should not create these loopy references+extends combination in my opinion. typescript itself does not use this pattern.

users who are affected by the new issue it created are few in comparison to all users affected by the fix. and they have 2 workarounds. downgrade vite or improve their tsconfig setup

[dmitry-stepanenko]

@dominikg AFAIK this works as expected.

nx projects are using TS solution config. learn more here https://github.com/microsoft/fluentui/blob/master/rfcs/shared/build-system/02-solution-style-ts-configs.md#detailed-design-or-proposal

[dominikg]

i feel like we are talking past each other. tsconfck supports solution style tsconfig files. https://github.com/dominikg/tsconfck/tree/main/packages/tsconfck/tests/fixtures/parse/solution

the bug only affects solutions that have a loop where a referenced tsconfig extends the same file that references it, not all solutions.

if you have solutions without a loop that get stuck please file a new bug with reproduction on tsconfck.

[dmitry-stepanenko]

@dominikg I understand this

the bug only affects solutions that have a loop where a referenced tsconfig extends the same file that references it, not all solutions.

Along with that you're saying

users who are affected by the new issue it created are few in comparison to all users affected by the fix

My point is that the amount of users who rely on this approach is not small in any sense, this is a pattern that is widely used by nx itself. I feel like this bug hasn't fully reached everyone as vite@5.1 is very recent and that's why it does not get broader attention.

Just hear me out: if a bugfix creates a regression that is barely fixable on the consumer's side, it's not a right bugfix. TS itself works just fine with extends/references loops, so this is something that tsconfck should also support.

From my understanding, in Nx's setup, the combination of references and extends serves two purposes:

1. tsconfigs are extended from the base one to more specific ones in libs (tsconfig.base.json with global settings => tsconfig.json with library-specific settings in lib => tsconfig.(lib|spec).json with build/test target-specific settings).
2. tsconfig.(lib|spec).json files are referenced by the library's tsconfig.json in order to help code editors determine which configurations should be applied to the given file.

So I wouldn't say it should be "fixed" as it is a functional setup that does the job

[zettlrobert]

@dominikg I understand this

the bug only affects solutions that have a loop where a referenced tsconfig extends the same file that references it, not all solutions.

Along with that you're saying

users who are affected by the new issue it created are few in comparison to all users affected by the fix

My point is that the amount of users who rely on this approach is not small in any sense, this is a pattern that is widely used by nx itself. I feel like this bug hasn't fully reached everyone as vite@5.1 is very recent and that's why it does not get broader attention.

Just hear me out: if a bugfix creates a regression that is barely fixable on the consumer's side, it's not a right bugfix. TS itself works just fine with extends/references loops, so this is something that tsconfck should also support.

From my understanding, in Nx's setup, the combination of references and extends serves two purposes:

1. tsconfigs are extended from the base one to more specific ones in libs (tsconfig.base.json with global settings => tsconfig.json with library-specific settings in lib => tsconfig.(lib|spec).json with build/test target-specific settings).
2. tsconfig.(lib|spec).json files are referenced by the library's tsconfig.json in order to help code editors determine which configurations should be applied to the given file.

So I wouldn't say it should be "fixed" as it is a functional setup that does the job

I agree with @dmitry-stepanenko

The nx migrate latest command also automatically pulls the new version which now leads to a broken project - so most issues will only arise when people pull up there versions.

Nx has the global tsconfig.base.json
In every generated library/application there is a tsconfig.json with library specific settings.

The tsconfig.json (of a library or application) references a set of 'configurations' tsconfig.spec.json and tsconfig.lib.json.

These configurations tsconfig.spec.json/tsconfig.lib.json (there even used to be a tsconfig.storybook.json extend the libraries/applications tsconfig.json but are also referenced in the it - which leads to the problem, right?

If the references to tsconfig.spec.json/tsconfig.lib.json in the tsconfig.json are removed the typescript configuration with the details for vitest is not 'included (for a lack of better term)' how would you suggest to get around that issue?

The above suggested solution aleclarson/vite-tsconfig-paths#132 (comment), is to move the base config from for example tsconfig.spec.ts to the tsconfig.base.json - that would work for some of many libraries but as soon as they have different configurations that would lead to issues.

[dominikg]

1. this situation is not permanent, there will be a fix in tsconfck as soon as i find the time
2. affected users have 2 workarounds: keep using vite 5.0.x or restructure their tsconfig to avoid the loop

this new bug is very visible and easy to avoid. The bug that was fixed is not. It silently used an incompletely extended tsconfig, possibly leading to build output you don't expect. It also affects all users using extends, not only those that use a combination of extends and references that create a loop.
So this revert would reintroduce a more insidious bug that affects more users and has no workaround.

I'm done arguing here.

Maybe you could spend time investigating how to contribute a fix to tsconfck instead of just reverting to a known broken state just because it might not break yourself?

If this can't be solved in the short term, another possibility is to reduce the amount of caching done inside tsconfck to sidestep the freeze. I'd take degrading performance over reintroducing a bug.

[dmitry-stepanenko]

If this can't be solved in the short term, another possibility is to reduce the amount of caching done inside tsconfck to sidestep the freeze. I'd take degrading performance over reintroducing a bug.

I agree that would be the best solution for now. I saw an opened PR in the tsconfck repo which does exactly that, can I assume this is something that you're going to release in the nearest future?

[sapphi-red]

Closing as #16124 is merged (released in 5.1.6).