Repository navigation
inferring readonly values in projects with path alias #49408
Description
Bug Report
🔎 Search Terms
- Declaration emit widens literal types in readonly properties.
🕗 Version & Regression Information
- This is a crash no
- This is the behavior in every version I tried : 4.7.3 and nightly build (4.8.0-dev.20220606)
- I reviewed the whole FAQ
⏯ Playground Link
Playground link with relevant code
💻 Code
const instance = {
program: ts.createSemanticDiagnosticsBuilderProgram,
host: options?.watch
? ts.createSolutionBuilderWithWatchHost
: ts.createSolutionBuilderHost,
builder: options?.watch
? ts.createSolutionBuilderWithWatch
: ts.createSolutionBuilder,
};
const host = instance.host(
ts.sys,
instance.program,
reportDiagnostic,
undefined,
undefined
);
const builder = instance.builder(host, options.references, {
verbose: false,
incremental: true,
force: false,
traceResolution: false,
});
builder.build();🙁 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.
Activity
hiukky commentedon Jun 6, 2022
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 }, }hiukky commentedon Jun 10, 2022
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:
The problem here is not that
tscwas doing the right job (in this repository I found the same problem), but thetsc-alias! resolving imports with full path.jsEven though I ensure the incremental build order, the modules order is not resolved correctly, and the other cause is mapped
paths.Using relative imports works, using paths with custom paths ends up no resolving correctly.
My current solution was this:
Before invoking
build, I iterate over each project, build individually, resolve the imports so I can move on to the next one and get my build successfully and inferring the types correctly.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 '../' relative imports:
If the project A uses path alias '@/':
I made an example here, you can test for more details.
https://github.com/klaby/ts-solution-builder
[-]API SolutionBuilder: issuing declarations with read-type properties[/-][+]Inferring readonly values in incremental mode[/+][-]Inferring readonly values in incremental mode[/-][+]inferring readonly values in projects with path alias[/+]sheetalkamat commentedon Jun 24, 2022
Here is what i tried on your repro:
Created two copies of the repro.
In both i did
yarn, followed bynpm i typescript@nextAfter that in first repro i called
node node_modules\typescript\lib\tsc.js -bIn another one i called
node build.jsCompared both folders and they have same contents except tsbuildinfo which has only diff of
dtsDateas expected.After this i have uncommented imports that were commented and commented out corresponding imports that conflct..
Ran build script and
tsc --band there is no diff again except dts time.Am i missing something. If yes please provide clear steps on what i would need to reproduce the issue.
Thanks
hiukky commentedon Jun 24, 2022
Sheetal Nandi (@sheetalkamat) did you look at
packages/foo/dist/src/sample/index.d.tsandpackages/bar/dist/src/sample/index.d.tsbefore and after switching imports?I'll try to describe it better!
sheetalkamat commentedon Jun 24, 2022
I did .. I compared the folders and every output was same except tsbuildinfo
hiukky commentedon Jun 24, 2022
can you look again? I just updated the repository
sheetalkamat commentedon Jun 27, 2022
Looked at your modified repro and as per that issue is not with invoking solutionBuilder but just tsc corect.
I looked at your config for foo and it is incorrectly configured.
"@/color"and"@/types"indist/src/helpers/index.d.tsdo not get resolved pertraceResolutionsbecause it the path mapping is configured incorrectly.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
bar/tsconfig.jsonto do the mappings.