[Bug]: "Recursive tsconfig file extension" error on non-recursive TS configs

[etlovett]

What happened?

@mattem is looking to upgrade our monorepo from aspect-cli v5.10.14 to v5.10.15, and we're running into one issue with Gazelle and JS. When we run Gazelle after the upgrade, it errors out with Recursive tsconfig file extension: "bazel/js/typescript/config". Our setup is that we have a root TS config at bazel/js/typescript/config/tsconfig.json, we ship that internally as an NPM package with "main": "tsconfig.json", and we use it in other TS config files as "extends": "our-first-party-tsconfig-package". This worked fine in v5.10.14 but is now failing in v5.10.15. I believe this is a valid pattern, as the TS docs for extends say "The path may use Node.js style resolution."

Looking through the git history, it looks like the logic around config resolution changed in 7a418ec, and resolution changed in d58ded8, in case either of these are related. It also looks to me like there's no test case in place for a TS config coming from an NPM package (tests).

Is it expected that this handling might have changed in this patch version? Is this pattern one that should be supported by Gazelle, or should we change our code to not use an NPM package for the TS config, or what?

Thanks in advance!

Version

Development (host) and target OS/architectures:

Output of bazel --version: bazel 7.1.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: our upgrade includes aspect-cli v5.10.14->v5.10.15 and bazel-gazelle v0.36.0->v0.39.1

Language(s) and/or frameworks involved: Gazelle, rules_js and/or rules_nodejs

How to reproduce

Any other information?

No response

[jbedard]

I thought this was supported already and it should even generate the ts_config(deps) to reference the package being extended, see tsconfig_pnpm_ref.

Any idea how your scenario might be different then that test (or the test beside it)?

[etlovett]

@Aghassi Is this still an issue? Thoughts on this?