Design Meeting Notes, 1/19/2024

[DanielRosenwasser]

Exposing TypeChecker#resolveName

#56932

• API hasn't changed in quite a while, we use throughout the services layer.
• The request is to expose it.
• People can kinda accomplish some of the same tasks via
• People use getSymbolAtLocation instead of this.
• Also, want to expose SymbolFlags.All.
  • Is it actually all of them?
    • Apparently NOT?
    • The last two aren't.
      • Never mattered.
  • Why isn't this just -1/~0?
• Conclusion: yes, expose the flag and the API.

Supporting more recursive type aliases

#35017
#35164
#41164
#57034

// Currently doesn't work:
namespace n1 {
 export type Json = null | string | number | boolean | Json[] | Record<string, Json>;
}

// But this *does* work:
namespace n2 {
 export type Json = null | string | number | boolean | Json[] | { [key: string]: Json };
}

• We can allow explicit object types, mapped types, or type references to classes/interfaces.

• We do not have any special handling for instantiations of type aliases to object types or mapped types.

• Have a prototype that makes some of this work.

• Enables some patterns like

  type Func<T> = () => T;
  type RecursiveFunc = Func<RecursiveFunc>;
  
  declare var rf: RecursiveFunc;
  
  rf = rf()()()()()(); // works

• So what we do is that the type references themselves become deferred.

  • But this is tricky because now there is a concept of a type reference that resolves to a type alias in a deferred way, and that makes things a bit more opaque, harder to reason about.

• What currently gets a deferred reference node?

  • type MyArray = Array<Blah>
  • type Blah = Array<Blah>

• If we're instantiating a type alias that's an anonymous type or a mapped type, we can now do something very similar.

  • However, that adds that layer of indirection which means you have to resolve the type in certain locations.

• Object types provide a natural deferral point because property types can be deferred; but generic homomorphic mapped types can expand out into a union. So how is that handled?

Creating a Global Reference to a Module

#57019

• import declarations in a declare global don't implicitly get exported.
  • Can't export it.
• Can you augment the module with export as namespace?
  • No.
• Feels weird.
• Also comes up in JSDoc where you want to just make your notation easier for types.
• Possibly want a namespace alias declaration.
• All that aside, you want to be able to fix a file to make an alias globally accessible, right?
• [[Editor's note: a reasonable solution may exist]]

A /** @nonnull */ tag

#57042

• Or is it "an @nonnull tag"?
• TypeScript allows /** @type */ to cast, but no non-null assertion.
• This tag can be nice - but is a bit verbose, doesn't mix well with optional chaining.
• What about a postfix?
  • Might be expensive to parse that out.

[DanielRosenwasser]

Aliasing namespaces: #10187

[whzx5byb]

import declarations in a declare global don't implicitly get exported.

As I posted in #57019 (comment), since declare global { namespace globalThis { ... } } will have the same effect as declare global { ... }, and the former allow importing/exporting namespace alias inside it, I think it could be a good solution.

[fatcerberus]

People can kinda accomplish some of the same tasks via

The suspense is killing me