Design Meeting Notes, 10/18/2019

[DanielRosenwasser]

• Preface: Obligatory "is that you climbing the rock" joke about Daniel's wallpaper.

TC39 Updates

• TC39 update
  • globalThis to stage 4
  • New in stage 3: Promise.any, String#replaceAll, formalized for-in object iteration
  • New in stage 2: Map#upsert
  • New in stage 1: A bunch of stuff
    • Readonly collections
    • Records and tuples #{ x: 0 }

Optional Chaining and Narrowing

#33736

• Have been iterating on feedback around narrowing optional chaining.

• type Header = { headers: Record<string, any> };
  type Options = { config : any };
  
  function getHeader(input: Header | Options,   key: string, def?: any) {
     return ('headers' in input ? input.headers  [key] : undefined) || def;
  }

• Today, in adds a property to the original type.

• type Header = { headers: Record<string, any> };
  type Options = { config: any };
  
  function getHeader(input: Header | Options,   key: string, def?: any) {
     return input.headers?.[key] ?? def;
  }

• Uhh.

Correcting Loose Assignability Rules for Intersections to Index Signatures

#32484

declare let s: { a: string } & { b: string };
declare let t: { [key: string]: string };
t = s;

• Our assignability rules say that if any constituent of an intersection is assignable to an index signature, the types are assignable.
  • UHH.
• Happens when you work on dictionary-like objects.
• We don't have a concrete rule yet, but have been observing some pain.
• Technically even { a: string } being assignable to Record<string, string> is wrong because { a: string } can contain more properties than it declares.
  • Otherwise it would be extremely difficult to deal with dictionary-like bags of properties.
• Probably 3.8-bound at earliest.

devDependencies in @types Packages

microsoft/types-publisher#655

• Problem: today, an app can't have both @types/node and @types/react-native in the same dependency tree.
  • This is because they both define globals.
• Solution 1: "Just let them coincide"?
• Solution 2: Give a blessed configuration for web and for react native?
• Solution 3: Be careful about the @types in your dependency trees.
• But then other problems...
• Problem: a library that wraps both react and react-native components can't have a dependency on either!
  • Proposed solution in Allow using dev dependencies in a package json types-publisher#655: devDependency specifies that a package works with these packages,
    • Adding these as devDependencys means that you can't use types from these in output positions.
• The whole situation is a mess: react depends on react-dom, react-native depends on react, some of these APIs use Buffers when you're in Node.
• What about a forward-declaration mechanism?
  • Placeholder Type Declarations #31894
• Are there libraries with these problems in DefinitelyTyped otherwise?
  • Yes!
• With Placeholder Type Declarations #31894, is the idea that you just say "there's a Buffer"?
  • Yes, "don't care what it is, but I'll take one!"
• Anything else you can't do with interfaces instead of forward declarations?
  • Well you can't forward-declare a type alias to a union type or tuple.
  • IteratorResult ended up with this issue, meant we needed to do typesVersions.
• What happened last time we chatted about placeholder types?
  • Tried to see if we could break the feature down into different functionality.
• What about conditional inclusion?
  • Something like type polyfills?
  • Swift potentially has something like this.
  • But how do you explore versioning?
• Feels like this has turned into a discussion about many different problems.
  • Original problem: devDependency to check on DefinitelyTyped, let users install the correct peer types.
• Does this stand up to other future solutions?
  • Unclear if this paints us into a corner.
  • How do you tell users "you have to also install @types/node now"?
• Also, there's an excludeTypes (Placeholder Type Declarations #31894) - a way to say "no, please don't add @types/node from being included".
  • But someone asked for those types to be included indirectly.
• Aside: .NET has had this problem since...forever and solved it with...not working correctly? :(
• What if @types packages could fulfull lib settings, and then we could provide lib?
• Conclusion: We will scope down and isolate the concerns in a separate meeting.
  • Also, of all the types that rely on @types/node, what do they rely on?

[Jessidhia]

I think TypeScript's behavior of just reading everything inside node_modules/@types/* by default is exacerbating the problem with conflicting declarations. Adding a compilerOptions.types: [] option to your tsconfig.json basically makes all problems (besides disk space / download size) with e.g. styled-components go away unless you need globals.

[DanielRosenwasser]

On the other hand, we might have a lot of users who benefit from not needing to configure their projects. I dunno if @RyanCavanaugh has any thoughts on this, but changing the default would probably break quite a bit.

[Bnaya]

The default can be to load only whats appear in package.json, and not the whole types/*

[alexanderjarvis]

I think that a larger issue here is the incompatibility with how npm modules can have a tree of dependencies of different versions (e.g. many packages depending on lodash). And TypeScript does not mirror this concept and only expects one version of a type.

Regarding @types/react-native – perhaps the type definition should be fixed so that it shares common globals rather than redefining them?

[orta]

I took a look at trying to make common globals before, but it's tricky because there are declared consts which are different between the environments - there isn't really a reconciliation process for that in today's typescript

People can definitely take a look, maybe I missed something!