Closed
Description
Acknowledgement
- I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.
Comment
-
/// <references>
inisolatedDeclarations
- Reference synthesis/ellision is confusing and impossible for ID
- Goals
- Stop synthesizing, ever
- Preserve, always(ish?)
- How breaky is this?
- Many people synthesize
react
types directives, seemingly for not much reason since these alsoimport
react
- Also many refs to
node
- Some to
jest
- Very few seemed actually necessary in any way
- There was one interesting one in the top 200
vercel/swr/src/core/index.ts
- Input file writes
import 'client-only';
- This causes an
env.d.ts
reference path
to be synthesized above it- Because it's an ambient module that didn't load via resolution
- This would (in theory) cause a resolution failure
- Except! resolution failures are silenced if no identifiers get bound from that import
- This package clearly has some declaration bundler magic going on
- So still a concern in theory, just not in practice from the top200
- Footgunish since you can't detect these potential problems at build-time
- Matching/subsetting config is an existing problem, not novel
- This is a subtle misconfiguration, if it's a misconfig at all
- Figuring out if it's even possible to downstream an output is difficult, let alone what the mandatory config option(s) are
- Emit as-is, preserve always, do not synthesize
- Depending on a transitive dependency is wrong!
- Many people synthesize
- 5.5 or 6.0?
- Enable this behavior in isolatedDeclarations only?
- Or introduce
--verbatimReferenceSyntax
? - Is this actually liable to break anyone in a real way?
- Feels like no (for synthesis)
- The reverse (preservation) seems riskier
- Could pull in files that are missing, or are conflicting globals
/// <reference path="foo" />
/// <reference path="foo" preserve />
- We were smart and can parse this in old versions
- 5.5
- Let's run a PR to check for re-print of directives just to sanity check
-
Propagation outer type parameters of single-signature types Propagate outer type parameters of single signature types #57403
- nested generic function inference causes unbound type parameter leak #55467 has a type parameter leak
- Repro depends on several factors
- Requires trafficing through outer type parameters on the function expression
- Instantiation of these gets deferred
- Deferred too long (forever)
- Needs to be instantiated with the type parameters of the outer call
- PR fixes this to capture the outer type parameters correctly
- PR fixes another problem where we captured a candidate of the form
A = [A[0]]
, which would tautologically arrive to the constraint (unknown
) and spoil the inference- Because the tuple type and argument form aren't instantiations of the same type
- How did this even work in the first place? i.e. What's special about this case?
- Read the PR notes; too complex to fit in this margin