-
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
inferring readonly values in projects with path alias #49408
Comments
My configuration using ESNext. {
"compilerOptions": {
"target": "ESNext",
"module": "ESNext",
"moduleResolution": "node",
"strict": true,
"esModuleInterop": true,
"resolveJsonModule": true,
"incremental": true,
"skipLibCheck": true,
"composite": true,
"forceConsistentCasingInFileNames": true,
"sourceMap": true,
"declaration": true,
"declarationMap": true,
"allowSyntheticDefaultImports": true,
"allowJs": true,
"experimentalDecorators": true,
"emitDecoratorMetadata": true
},
} |
Adding a little more information, I ended up finding the cause of this when trying to reproduce this in a repository! I really don't know if this is the expected behavior, but it looks like it's a problem in resolving the ESM modules. As I'm working on a monorepo, my first (functional) build follows this example: for pkg in "${sources[@]}"
do
(
cd ./"$pkg" \
&& yarn tsc -p tsconfig.build.json \
&& yarn tsc-alias -f
)
done The problem here is not that Even though I ensure the incremental build order, the modules order is not resolved correctly, and the other cause is mapped // ✅ It works
import foo from '../foo'
// ❌Already here it breaks
import foo from '@/foo' Using relative imports works, using paths with custom paths ends up no resolving correctly. My current solution was this: Before invoking So the real problem is that the compiler is not solving the modules in the correct order in incremental mode. It can solve only from A to A, but not from A < B. Details:
If the project A uses path alias '@/':
I made an example here, you can test for more details. |
Here is what i tried on your repro: After that in first repro i called Compared both folders and they have same contents except tsbuildinfo which has only diff of After this i have uncommented imports that were commented and commented out corresponding imports that conflct.. Am i missing something. If yes please provide clear steps on what i would need to reproduce the issue. Thanks |
@sheetalkamat did you look at I'll try to describe it better! |
I did .. I compared the folders and every output was same except tsbuildinfo |
can you look again? I just updated the repository |
Looked at your modified repro and as per that issue is not with invoking solutionBuilder but just tsc corect.
I think you want to use reference to bar project in tsconfig for foo to be able to correctly resolve the imports and then things work correctly as it would use
|
Bug Report
🔎 Search Terms
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
I was testing a module just now and I noticed that the typescrit was emitting an error that it shouldn't .. I went deeper and saw that the constants were being emitted but only with the type instead of the declared read value.
using tsc -b works as you can see in example 02, but with SolutionBuilder it is setting it to "string" instead of "redBright".
So I don't think it's some option not defined in my tsconfig, because with tsc it outputs as expected, but my implementation with solution builder doesn't.. I also don't see any parameters, or something like that in the solution settings "createSolutionBuilderHost" or "createSolutionBuilder" that relates to that.
Looking deeper I decided to compare the tsbuildinfo files, and I noticed this change!
I don't know how TS works under the hood, but I can deduce that this loading order here is causing the problem.
The first example builds using TSC from the command line! it works fine, the second one is using SolutionBuilder and it doesn't issue correctly.
What I can imagine is that in the first case "constants.ts" has already been loaded and is available for "plugin.ts" and with that it can output my reading values.
In the second case "plugin.ts" is being loaded before "constant.ts", so my read values are not available yet, and ts is defaulting to "string".
I tested it twice to see if these values would change in both builds, but they don't..
So that's my logic for that.
I also just encountered this similar issue #15881 but no solution.
Looking at the "build" method we don't have asynchronous code implicit there, so I can assume it's all synchronous, the order of references is also correct.. so I'll try to use other methods like "buildReferences" to see if I get something.
🙂 Expected behavior
Correctly issue read-only declarations using SolutionBuilder api.
The text was updated successfully, but these errors were encountered: