Skip to content

Design Meeting Notes, 3/2/2022 #48095

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Platform-Specific Resolutions and Path Mappings

#21926
https://github.com/afoxman/rnts-example

  • React Native uses a priority list of extensions when resolving a path like ./foo

    • e.g. on iOS, ./foo.ios.js, then ./foo.mobile.js, then ./foo.native.js or something like that.
  • Some set of minimal additions that are easy to reason about and would serve React Native users?

  • Union per module?

    • Not always coherent. ❌
  • Single tsconfig for all platforms? Means different resolutions per file per compilation?

    • ❌, complex.
  • A single set of resolutions per tsconfig.json is easier to stomach.

    • moduleFileExtensions?
    • moduleFileExtensionPrefixes
    • "moduleFileExtensions": ["ios", "mobile", "native", ""]
    • Seems weird. Should force the . at the beginnning.
    • "moduleFileExtensions": [".ios", ".mobile", ".native", ""]
    • Then is suffixes, not prefixes?
  • What does it mean to import from a file with a .js extension?

    • Not really coherent?
    • Kinda is, just trim off the extension and try each suffix with the original extension.
    • That's what the prototype/fork is.
  • Next: remapping types

    • Be able to say "this module specifier points to this module."
    • Doesn't path mapping enable this?
      • Can still end up accidentally picking up types from types field.
    • npm overrides?
      • Not sustainable for several build targets.
  • One issue with path mappings was the need for baseUrl

    • No longer need that either.
  • Does react-native rely on react-native-macos? Does that in turn rely on react-native-native?

  • Do we feel like we're compromising on design? Is this general enough?

    • We feel sufficiently motivated by the scenarios. We don't feel bad about the design, the amount of support it requires is not high, and people using RN or specific build tools will use it.
    • We also feel like there might be a bit of a catch-22 - high correlation between RN and TypeScript. If TS doesn't work well with a feature, could be the case that people naturally avoid it.
  • Would be willing to take a PR on this.

Remapping exports Entries to Input Files

#47925

  • Using Node's ESM self-name references can change your output structure.
    • Explicit composite/rootDir?
      • That is more ideal. But usually our logic works pretty well for
    • Idea here is to resolve to the input file based on the output files of the package.json.
    • Does this tie into last week's discussion topic - resolveFromOutDir?
  • In a sense, doing this means that a self-package reference is implicitly a relative import.
  • Feels like there are a lot of footguns, we can say "if you use a self-package-name, you need to set rootDir".
    • But we can usually figure out the correct rootDir!
  • Conclusion: enforce rootDir - don't let people land in the pit of failure.

Re-computing results from nested variance computations

#48080

  • We try to do an up-front variance calculation for generic interfaces and aliases on types using marker types.
    • Compare to and from instantiatons with different markers.
    • This avoids a bunch of structural comparisons of types, which is great for more complex types.
    • But doing this is technically still an up-front structural check. It just allows us to record variance and know which directions to compare types.
    • Sometimes, when calculating variance, we will run into the same type and end up asking "what is the variance?" In those cases, we give a slightly-incorrect answer that the type is "independent" of a given type parameter.
    • This interacts strangely with our deep-instantiation checks. It creates an ordering problem.
  • Idea (I think): record symbols that impacted variance. Also record instances of when we're calculating variance, and that calculation asks for variance of the same thing in a nested context. Come back to any further results that gave more information to recalculate variance here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions