inferring readonly values in projects with path alias

[hiukky]

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.

[hiukky]

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]

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 tsc was doing the right job (in this repository I found the same problem), but the tsc-alias! resolving imports with full path .js

Even though I ensure the incremental build order, the modules order is not resolved correctly, and the other cause is mapped paths.

// ✅ 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 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:

• ✅ Emission works correctly in A.
• ✅ Emission works correctly on B which depends on A.

If the project A uses path alias '@/':

• ✅ Emission works correctly in A.
• ❌ Emission does not work correctly on B which depends on A.

I made an example here, you can test for more details.
https://github.com/klaby/ts-solution-builder

[sheetalkamat]

Here is what i tried on your repro:
Created two copies of the repro.
In both i did yarn, followed by npm i typescript@next

After that in first repro i called node node_modules\typescript\lib\tsc.js -b
In another one i called node build.js

Compared both folders and they have same contents except tsbuildinfo which has only diff of dtsDate as expected.

After this i have uncommented imports that were commented and commented out corresponding imports that conflct..
Ran build script and tsc --b and 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]

@sheetalkamat did you look at packages/foo/dist/src/sample/index.d.ts and packages/bar/dist/src/sample/index.d.ts before and after switching imports?

I'll try to describe it better!

[sheetalkamat]

I did .. I compared the folders and every output was same except tsbuildinfo

[hiukky]

can you look again? I just updated the repository