Using compiled *.d.ts file produces a type error, but using the same type from the source file doesn't

[gigobyte]

Backstory: A type error bug was reported for a library of mine. I tried reproducing by writing code inside the library source and I couldn't reproduce it. I npm install-ed my library and I could indeed see the error that was reported (I used the same code snippet in both places). Turns out the type error only happens with the compiled type definitions file.

TypeScript Version: 3.2.2

Search Terms: class property, definition file

Code

SSCCE Repo link

To reproduce: Clone the repo. Open src/BUG_HERE.ts. There will be a type error:

Type 'Maybe<never>' is not assignable to type 'Maybe<number>'.
  Types of property ''fantasy-land/alt'' are incompatible.
    Type '(other: Maybe<never>) => Maybe<never>' is not assignable to type '(other: Maybe<number>) => Maybe<number>'.
      Types of parameters 'other' and 'other' are incompatible.
        Type 'Maybe<number>' is not assignable to type 'Maybe<never>'.
          Types of property 'value' are incompatible.
            Type 'number | undefined' is not assignable to type 'undefined'.
              Type 'number' is not assignable to type 'undefined'.

Expected behavior:

Either both functions must have a type error or both should compile, I'm not sure which is the correct behavior, the issue is in that only the imports from the definition file produce an error.

Actual behavior:

Module imported from source has no errors, same module compiled and imported does have an error even though it's used the same way.

Observations from my research:

• It may be related to class properties
• Turning off --strictFunctionTypes fixes the error

[weswigham]

Turning off --strictFunctionTypes fixes the error

Huh. Sounds like something that started as a method (which is checked bivariantly) gets emitted as a property (checked strictly) - potentially as a result of a simplified mapping operation (mapped types don't preserve methodiness of input props).