Type does not follow workspace since 4.3.2

[bodinsamuel]

Bug Report

Hello team,
Not sure if it's a limitation or a bug, but when using types across workspaces, some of them are not following along.
I can not explain why, but I have a small repro

🔎 Search Terms

types, express, workspaces, references,

🕗 Version & Regression Information

• This changed between versions 4.2.4 -> 4.3.2
• Still happening with @next

⏯ Playground Link

• A working example without workspaces: https://www.typescriptlang.org/play?ssl=21&ssc=3&pln=13&pc=1#code/JYWwDg9gTgLgBAUwB5iggzuuAzKERwDkyqG6hA3AFBUAmCAxgDYCGaOArgHYMzARc46GGxgAJGDDABlBFABucgBQBvKnDiRYAGnVwO6DLo0swYXQF8AXHDUatMG1w4gARnLgAfITCjAuAObUGgYYAPw2AEqM0LQAPMJ+gdqIKGiYAHQAgmZMwAwsfAJeqaSZ0QCOHBjiLFy0THJxdQCeAHxtwXCmYBGl6ejZufmF-ILezkxM1BYAlDYACnggwIbNXO3UNMKiElKyCsp2mtCOcAAcAAzXxvqG6DbHGoTYEBAZACpIMIQ2SmgVFLpWZwAC8bVseg0GjQMA4UEEhFcbEoULgFj0GLmQA
• The repro: https://github.com/bodinsamuel/ts-workspace-typing-issue

git clone https://github.com/bodinsamuel/ts-workspace-typing-issue.git
cd ts-workspace-typing-issue
yarn
yarn tsc -b

$ /Users/samuelbodin/code/test-ts-workspace/node_modules/.bin/tsc -b
test2/index.ts:6:17 - error TS7006: Parameter 'req' implicitly has an 'any' type.

6     'foo.Txt': (req, res) => {
                  ~~~

test2/index.ts:6:22 - error TS7006: Parameter 'res' implicitly has an 'any' type.

6     'foo.Txt': (req, res) => {

🙁 Actual behavior

Express req and res are typed as any

🙂 Expected behavior

Correct express typing

[RyanCavanaugh]

Condensed as far as I felt needed, this is a 4.2 -> 4.3 regression

type StringFunc = (a: string) => void;

declare function startHttpServer(x: { uses: Record<string, NumberFunc | StringFunc>; }): void;

export interface BoolFunc {
  (req: boolean): void;
}

export interface NumberFunc extends BoolFunc {
  (req: number): void;
}

startHttpServer({
  uses: {
    'foo.Txt': (req) => {
      
    }
  }
})

[bodinsamuel]

Amazing @RyanCavanaugh !
So no relation to workspaces actually? :D

[orta]

Shrunk it down even further, seems to be specific to the contextual typing when there's a union of functions in that position

type StringFunc = (a: string) => void;

declare function startHttpServer(x: { uses: Record<string, NumberFunc | StringFunc>; }): void;

export interface BoolFunc {
  (req: boolean): void;
}

export interface NumberFunc extends BoolFunc {
  (req: number): void;
}

startHttpServer({
  uses: {
    'foo.Txt': (req) => {
      
    }
  }
})

[RyanCavanaugh]

@orta that's not a regression, though - longstanding behavior

[orta]

This seems off.

It feels like previously working before is a bug though, on 4.2 it the contextual arg is a string but it 'ideally' should be string | number | boolean in your example, there's nothing which should narrow it down to the single union participant of arg:string => void except that two members are overloads of the same func

The 4.3 changes might have just brought it inline with the rest of the type system?

[typescript-bot]

👋 Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the repro in this issue running against the nightly TypeScript.

---

Comment by @orta

❌ Failed: -

• Parameter 'req' implicitly has an 'any' type.

Historical Information

Comment by @orta

Version	Reproduction Outputs
3.9.2, 4.0.2, 4.1.2, 4.2.2, 4.3.2, Nightly	❌ Failed: - Parameter 'req' implicitly has an 'any' type.

[bodinsamuel]

Hi,

My opinion is probably not highly relevant because I lack a lot of information here, and I'm not sure wether it's a bug or a correction. But the fact the this behavior changes between 2 minors is maybe an issue in itself.
I'm fine with breaking cahnges between major, especially if it's documented why and how to solve it,
but here it's a clear regression between 4.2.4 -> 4.3.2 (on my repro).
If it really need to happen, would be better to introduce it in 5.0.0 imo.

Best Regards,

[orta]

Both Major and Minors are effectively major versions for TypeScript, see for the general reasoning #14116 (comment) which is why you see long release notes for every major/minor combo.

I chatted with one of the engineers who I figured might have made the changes for this and they said this change is intentional, ignoring the other functions in the type system because they had an overload was a bug fixed in #42620

[bodinsamuel]

Make sense for the majors thanks.

---

For the rest I'm not sure I agree with the fix then. In the repro provided by you, the req become any while it should be perfectly okay to be number | boolean, it's not string or object or whatever, I'm not just sure why it becomes any.

More than that, I can not help the typing, if I put (req: number) the function now complain that Type 'boolean' is not assignable to type 'number', which is fair warning but a bit annoying.
You will say I need to check the typing with a type guard, which is fair too but with number | boolean a simple if req === true) would have restrained the type very closely to the actual type, while any is hardly doable.
In the end users will do req as boolean | number and now the type is no longer in sync with the initial definition. So tomorrow the definition change to string | number and typescript will not complain.
Playground

Anyway, in the end if it's to align the typing system, I have no say in this.
However I would have loved a union or unknown more than any. any let you do a lot of mistake, while unknown at least complain a bit more. I guess a even better type would be unguessable