Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 1/14/2022 #47724

Closed
DanielRosenwasser opened this issue Feb 3, 2022 · 0 comments
Closed

Design Meeting Notes, 1/14/2022 #47724

DanielRosenwasser opened this issue Feb 3, 2022 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

More Precise TypeFacts for Intersections

#47282

  • TypeFact flags - used during narrowing.

    • For typeof yadda === "string", we have a TypeFlagsEQString.
  • Some bug was reported.

    interface Meta { foo: string }
    interface F { (): string }
    
    function f(thing: (F & Meta) | string) {
        if (typeof thing === "function") {
            // < 4.2+: has type 'F & Meta' - expected
            // >=4.3+: has type 'never' - unexpected
        }
        else {
            // < 4.2+: has type 'string' - expected
            // >=4.3+: has type '(F & Meta) | string' - unexpected
        }
    }
  • With intersections, we compute type facts differently.

    • typefacts(A & B) would calculate as typefacts(A) | typefacts(B).
    • In this case, it's true.
    • With primitive types though, you really don't want that.
      • Tagged types - { __yadda: void } & string, or type variable intersections - T & string
      • You really should know that you have string or never.
  • It's rare to call typefacts on a union, but intersections don't get broken down that way.

    • Could be that some flags combine with an & (and) and some with an | (or).
    • Plain ones combine with |, negated ones combine with &.
  • Conclusion: iterate on implementation

Parsing Files as Modules

#40501
#47237

  • When we added the React transform, we used the existing parser infrastructure - that means the presence of a module construct (import/export) is what determines whether we have a module.
  • Newer JSX transform implicitly imports React. Not true of the old mode.
  • Also have files that always consider themselves to be ESM files, but weren't enforcing them as modules correctly.
  • Have an implementation where if you're in an ESM file or in a new JSX-mode file, then we do consider those files to be modules.
    • New flag - --moduleDetection
    • force, auto, legacy.
    • force is always module (except declaration files - sad)
    • auto - figure it out from the file extension and module usage. Mixes today's behavior, but does the right thing for .mts etc.
    • legacy - everything is global unless you have a disambiguator - even .mts/.mjs or whatever.
  • Does this change the behavior for a getting started experience?
    • Not really - auto is the new default.
  • What's the API change?
    • Breaking change technically - externalModuleIndicator is now potentially boolean.
  • Probably should workshop the name a bit?
    • Also, auto implies the default value. Maybe name the flag differently?
  • Also, do we need the legacy field?
    • Unlikely people will use, but it's plausible.
  • Should we continue emitting export {} in ambiguous files when using --moduleDetection force?
  • JS/TS editors have a concept of an inferred project - when you have loose JS and TS files with no tsconfig.json/jsconfig.json, the editors have default options they use.
    • Should those editors use --moduleDetection force?
    • Maybe! Should talk it over at our next editor sync.
  • Action items:
    • Get implementation together with LS
    • Bikeshed name
    • Editor sync discussion

Preserving Mapped Types Over Tuple Elements

#46741

  • Can re-index into a mapped type with an intersection of its keyof and a type variable.
  • Things go a little crazy once you get a tuple type with a variadic portion in it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant