GeezerVison

I ran RWC on this and saw changes only in elaborations and order of printing union types. No errors were added or removed, and no types changed.

The changes appear to result from better type caching leading to less elaboration. The only interesting result was from the Azure Framework tests, where one incorrectly duplicated error disappeared entirely, maybe because the whole error was already issued just prior.

I'll run DefinitelyTyped next and look for diffs.

Nathan Shively-Sanders (@sandersn) When running DefinitelyTyped, be sure to run both with and without --strict. I'm particularly interested in the results with --strict.

Ah, good point. I forgot --strict the first time around. First I compiled everything using 0ac8406, the commit before this PR. Then I compiled again with this PR's commits and diffed the changes. Interestingly, a few packages on DefinitelyTyped still have more errors even without --strictFunctionTypes. The errors look like they come from tighter variance checking too, so it's likely that some changes are escaping from behind the flag.

Take a look at the test files for recompose, rx-lite and rx.wamp (which depends on rx-lite). Recompose is clearer to see (the rx* errors are obscured by overloads in rx-lite):

recompose-tests.tsx(248,7): error TS2345: Argument of type 'InferableComponentEnhancerWithProps<{ count: number; } & { update: (state: number) => number; }, {}>' is not assignable to parameter of type 'ComponentEnhancer<any, any> | InferableComponentEnhancerWithProps<{}, {}>'.
  Type 'InferableComponentEnhancerWithProps<{ count: number; } & { update: (state: number) => number; }, {}>' is not assignable to type 'InferableComponentEnhancerWithProps<{}, {}>'.
    Type '{}' is not assignable to type '{ count: number; } & { update: (state: number) => number; }'.
      Type '{}' is not assignable to type '{ count: number; }'.
        Property 'count' is missing in type '{}'.

Notice that the direction of assignability switches, I think because of contravariance.

In total, I noticed changes with

• recompose
• rx-lite
• rx.wamp (for nearly the same reason as rx-lite)
• jasmine
• a few other projects had different line numbers for errors in lib.d.ts, which doesn't make sense to me.

I'll take a look at the results with --strictFunctionChecks turned on next. It's only halfway done, but there are already lots of failures, so I'll only provide a summary.

Nathan Shively-Sanders (@sandersn) With the latest commits we revert to always performing a structural comparison when the relationships indicated by getVariances don't hold. In effect, the variance information computed by getVariances is now an indication of which relationships to try first as an optimization, but it doesn't preclude other relationships. In the default checking mode we now behave exactly the same way as before, so I would expect no changes to RWC baselines or DefinitelyTyped. I would expect to see new errors only in --strictFunctionTypes mode.

LGTM but I'd like to see what happens if we run RWC with this forced on

With the latest commits, both RWC and DT crash much more due to running out of memory. I only get about 2/3 of the RWC tests to succeed, and DT crashes at 'bookshelf'.

Nathan Shively-Sanders (@sandersn) Is that with or without --strictFunctionTypes?

With --strictFunctionTypes

Nathan Shively-Sanders (@sandersn) It is likely because we do more structural comparisons of types. There are enough edge cases (e.g. any or void type arguments) where types don't act exactly according to the gathered variance information, so if the optimized first check of the type arguments doesn't succeed we need to do a structural comparison. We'll have to look at the specific cases, but it's not clear what else we could do.

Latest commits address code review feedback. Also, we improve error elaboration for generic types where one or more type parameters are invariant. In some cases generic types that are covariant in regular type checking mode become invariant in --strictFunctionTypes mode because one or more type parameters are used in both co- and contravariant positions with the generic type. In order to make it easier to diagnose why such types are invariant, if any of the type parameters are invariant we reset the reported errors and instead force a structural comparison (which will include elaborations that reveal the reason).

Anders Hejlsberg (@ahejlsberg) do you have feedback on my latest example?

Anders Hejlsberg (@ahejlsberg) Even though you mention only 3% of type packages are affected, I think the real negative impact is in much higher considering that major packages like angular, express, hapi, cucumber, selenium-webdriver etc. are affected. Hopefully the undocummented "skipLibCheck" option can rescue some projects.

xnnkmd The list above doesn't show it, but in practically all cases (including all of the ones you mention) the errors are in the tests associated with the type package, not in the package itself. So, there should be no need to use --skipLibCheck.

the errors are in the tests associated with the type package, not in the package itself

Anders Hejlsberg (@ahejlsberg) Can you post a list of packages where only the package itself is affected? (not the tests)

gentlemen, pardon me, but i don't understand your attitude towards these mighty new features... even if we break 97% of all code out there, even then:

• it's under the flag --strictFunctionTypes, so if you are scared of it, stay away from it! so if you did stay away from it, you are in the old safe TypeScript and nothing brakes

• secondly, the code that breaks is ill and it's a good thing that you see it breaks, it means you know where you weak parts are, so please be grateful, will you?

DefinitelyTyped/DefinitelyTyped#20219 fixes the packages on DefinitelyTyped that break with --strictFunctionTypes. Plus it updates the tests for many "popular" packages whose tests will break so you can take a look to see how you might have to update your code.

Packages fixed by DefinitelyTyped/DefinitelyTyped#20219:

• backbone
• bootbox
• cordova-plugin-appbrowser
• ibm-mobilefirst
• jointjs
• jquery
• knockout
• lodash
• ramda
• react

I also fixed tests in

• node
• log4js
• q
• react-native
• react-redux
• sharepoint
• webpack

Notes:

• Here, "popular" just means a random selection of packages I have heard of. I didn't fix hapi's tests, for example, even though I think it's fairly popular.
• I didn't submit PRs to projects that bundles types with their packages. I don't have a good way to scan all Typescript that eventually ends up on npm.