Design Meeting Notes, 8/16/2024 (original) (raw)
Navigation Menu
- GitHub Copilot Write better code with AI
- GitHub Models New Manage and compare prompts
- GitHub Advanced Security Find and fix vulnerabilities
- Actions Automate any workflow
- Codespaces Instant dev environments
- Issues Plan and track work
- Code Review Manage code changes
- Discussions Collaborate outside of code
- Code Search Find more, search less
- Explore
- Pricing
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Appearance settings
Description
API for exposing inferred type arguments of calls
- Is the proposed API correct? A signature is the target of the call, but is independent and the specific type arguments correspond to the signature itself.
- Is
Signature -> Type[]right? Or do you need something else? You have type arguments of signatures, but there are other type parameters in question. - What is it?
- Whatever the language service does. Go to definition can be used for this.
- Go to definition isn't a stable API for this.
- If you have a way to get the signature as it is, you can get the type arguments.
- Can basically use
getResolvedSignature, grab the type arguments, followed byinstantiateTypeswith the original signature's mapper? As suggested in the isssue. - Yes, that sounds like the suggestion for the API.
Flag for Banning TypeScript-Specific Runtime Constructs
- Opt-In Language Features to prevent Embrace and Extend -- Compiler options on tsc.js #2261
- Tsconfig option to disallow features requiring transformations which are not supported by Node.js' --strip-types #59601
- Long-standing question: how can we ban constructs that have no runtime impact (or are not trivially erasable)?
- Possibly more impetus for this now that Node has
--experimental-strip-typeswhich replaces type constructs with whitespace. - What would it be called?
--noTranspiledFeatures
* We transpile ESXXXX features.--typeSyntaxOnly--disallowRuntimeSyntax--noLegacySyntax--noRegerts
- Does this flag imply
--verbatimModuleSyntaxand--isolatedModules?- The use-cases overlap a lot. We don't know why you would turn this flag on without those.
- People seem to like
typeSyntaxOnlythe best. - This sort of thing is always weird because implementers are free to add new TS-specific constructs.
- Well this is also about staying "pure" with ECMAScript.
- Which are clearly not okay?
class C { constructor(public prop: number) {} }enumof any formnamespaceof any form
- Are the following allowed?
import foo = require("foo");import foo = bar.baz;export =
- Some of these can't just get erased to whitespace!
- This is all wacky because the only reason we're revisiting this is
--experimental-strip-types, which seems motivated because Node's sourcemap support is slow.- This is also speculative for a feature that hasn't shipped in stable.
- Not fully true, there is also future-proofing against syntax conflicts in ECMAScript as a concern.
- Lots of this could just be a lint rule which enforces ideological purity.
- Some mixed feelings on whether this is a good thing to do, but there is a feel that this is not what we would do today.
- Presumably this would be only in
.ts, not.d.ts - Feels bad that we'd disallow enums, what is the substitute there?
- Enums being nominal, having individual type members, etc. are all nice.
const foo = {...} as enum.
* Wouldn't be a full substitute.
const x = {
a: 1,
b: a, // can't do this
} as enum;
- What about
import foo = require(...)?- Could support
const foo = require(...)in some way, but would need a flag since a lot of code assumes this isany. - Is this really necessary? The hope is ESM/CJS interop will save us all.
- A flag to add this flag? Just turn off this flag if you really need that or write
const m = require("m") as typeof import("m").
- Could support
Metadata
Metadata
Labels
Development
No branches or pull requests