Description
Mark call and new expressions as intra-expression inference sites
- Have a concept called intra-expression inference sites.
- Allows us to walk within an expression to infer from inner expressions, in case one of the inner expressions relies on prior inner expressions.
- The change is to consider calls and
new
s as possible locations that may contain intra-expression inference sites. - Need time to look over and review this.
Isolated Declarations
-
--isolatedModules
says: you may only use features that can be "trivially" compiled to JS. -
Idea:
--isolatedDeclarations
says: you may only declare entities that can be "trivially" transformed into declaration files. -
Benefits: alternative tools can generate declaration files, and the project system graph is not a bottle-neck in parallel checking.
- Includes using very fast compilers, declaration file bundlers.
- Allows writing tools to generate all the
.d.ts
files in a fully parallel manner, and then run however many type-checkers as you want on all of your projects.
-
Some issues:
- Subset is somewhat restrictive - can be painful.
- Alleviated by carving out a subset of JSON-y expressions.
- 3rd party transformers may want to build off a superset of features of
--isolatedDeclarations
.- However, people writing external transformers have provided explicit feedback that they would not want to implementa declaration file transformer.
- Subset is somewhat restrictive - can be painful.
-
Given that there was a big feature list of other things, is this stable? Should it initially be marked as
experimental
?- Possibly!
-
Coming back to a point: should this be an external tool?
- Could see this being a compiler API rather than a top-level flag.
- The biggest use-case is build tools, and many of them are relying on TypeScript itself too.
- Having this at the API level.
- You really do want diagnostics and quick fixes as you adopt this feature.
- Could see this being a compiler API rather than a top-level flag.
-
Is this 5.4 ready?
- Close the 5.4 beta deadline, so risky.
- But there is time before RC/stable.
- Some places where the implementation is not what we would've expected.
- For example,
isolatedDeclarations
doesn't use a separate path, this does. - Effectively a separate binder.
- Larger footprint in general.
- For example,
- Close the 5.4 beta deadline, so risky.
-
We have raised all of these points in the past. It's okay if we want to revisit, but need to make feedback actionable and avoid churn.
-
Is
isolatedModules
a mistake even though we tell everyone to use it?isolatedModules
was based on 3rd party tools needing to emit- Maybe ahistorical - people might've just wanted this for
transpileModule
. - Regardless, there's a bit of chicken/egg.
-
The feature is a few things
- Errors
- Quick fixes
- Fast declaration emit via API
- Fast declaration emit via tsc
-
Has all the optimistic stuff been removed?
- Mostly, yes.
-
Can this exist out of band?
- Feels like the concept doesn't keep its head above water if it's not in the compiler.
-
One set of ideas:
- Take the isolated declaration emitter and move it out of band.
- Keep the
isolatedDeclarations
flag in the compiler in some capacity.