Closed
Description
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.
- e.g. on iOS,
-
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
?moduleFileExtension
Prefixes
"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.
- Can still end up accidentally picking up types from
- 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 onreact-native-macos
? Does that in turn rely onreact-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
- 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
?- Design Meeting Notes, 2/25/2022 #48042
- No way to use composite project where outDir is determined by build tool #37378 (comment)
- No, this is all about
rootDir
. - Here there is a circularity issue. You need to know the set of output files to know how to resolve back to the input so that you can calculate the
rootDir
.- Uh, isn't that the same with
resolveFromOutDir
?- No, because project references.
- There's no strict requirement that they're using project references.
- Maybe they'd need to enforce
composite
to avoid this circularity. - CC @alexeagle
- Maybe they'd need to enforce
- Uh, isn't that the same with
- Explicit
- 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
!
- But we can usually figure out the correct
- Conclusion: enforce
rootDir
- don't let people land in the pit of failure.
Re-computing results from nested variance computations
- 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.