-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include paths evaluate to no files when tsconfig.json is in a sandbox (regression in 5.5) #59036
Comments
Using https://www.npmjs.com/package/every-ts: $ every-ts bisect start
$ every-ts bisect bad main
$ every-ts bisect good 5.4.5
$ every-ts bisect run sh -c 'tsc -p tsconfig.json --outDir .'
c92bd16ac0e75834100ef57daa0083f161470509 is the first bad commit
commit c92bd16ac0e75834100ef57daa0083f161470509
Author: Sheetal Nandi <[email protected]>
Date: Fri Apr 26 13:14:40 2024 -0700
Exclude outDir and declarationDir even if they come from extended config (#58335) |
This was intentional change to exclude the |
It seems like that PR intended to change it for the case where |
For all flags we normally dont care if its in config file or passed on commandLine, so thats what this change did - always exclude |
I think one would expect that these three tsconfigs would have identical behavior: {
"compilerOptions": {}
} {
"compilerOptions": {
"outDir": "."
}
} {
"compilerOptions": {
"outDir": "."
},
"exclude": []
} but (2) is the only one that fails with |
But they are not same:
|
I recognize the behavioral difference, but it seems like something that will be a source of confusion for users. Also I just wanted to get clarification, should this behavior only apply to tsconfig files that have been |
There is no change in behavior for scenario 2 with that PR. That behavior was always there |
I believe that's not correct. Scenario 2 produced Note, the repro is even simpler than I wrote above:
|
Thats not what i see. I believe what you ran is not scenario2 as before my change it really just looked "own config outDir" and not commandLine or extended config. Now its consistent. Wherever the outDir comes from it will be excluded if we are supposed to calculate the exclude pattern.
|
I'm sorry, are you saying that you can't repro the same thing I provided above? |
I am saying that the run you did is not same as scenario 2 described in #59036 (comment) that worked before that change, The change now handles |
@alexeagle is there any additional action needed here? |
Hey @RyanCavanaugh - I'm representing users here, rather than myself. In our examples I was forced to add workarounds https://github.com/aspect-build/rules_ts/pull/643/files and I expect that represents the same thing our users will be forced to do. So the required action depends on how much those folks complain about the changed semantics for when As an example user-reported issue: aspect-build/rules_ts#644 (comment) To be fair, perhaps it's unusual that our Bazel integration passes that command-line flag at all. For reference, here's the spot where we do that. I could imagine we just omit this flag when the value is |
This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
I traveled the same path when I filed issue #60867! PR #58335 fixed a bug where I had a hard time finding out that Since Aspect has decided to pass an explicit value for
|
π Search Terms
symlink tsconfig includes
π Version & Regression Information
β― Playground Link
No response
π» Code
No response
π Actual behavior
Under Bazel, builds are made more hermetic by creating a dedicated folder (an "execroot") and symlinking files into it.
Starting in TS 5.5, we see the following minimal reproduction:
Note that if
--outDir .
is removed, then this command instead succeeds and writesindex.js
.This red PR to Bazel's TypeScript rules demonstrates the problem in the context of running the
bazel
tool: aspect-build/rules_ts#643π Expected behavior
In the prior TypeScript release this was working.
Additional information about the issue
#58042 seems like a likely explanation as it touched the resolution logic for locating files to be in the program, fyi @sheetalkamat
The text was updated successfully, but these errors were encountered: