Description
π Search Terms
--strip-types
β Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/JavaScript codeThis wouldn't change the runtime behavior of existing JavaScript codeThis could be implemented without emitting different JS based on the types of the expressionsThis isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-TypesThis feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
β Suggestion
Node.js has introduced an experimental flag that allows type annotations to be stripped. However, since Node.js only erases inline types, all TypeScript features that involve replacing TypeScript syntax with new JavaScript syntax will fail as described in the Node.js docs. The following features are listed in the docs as the most important features not supported:
- Enum
- experimentalDecorators
- namespaces
- parameter properties
Would it be possible to introduce a single flag in tsconfig that tells the compiler in one fell swoop that all these features should not be enabled to ensure compatibility with Node.js --strip-types
?
π Motivating Example
If there was such a configuration option, you could easily ensure that the code you write always contains only standard JavaScript + type annotations that can be executed by Node.js without installing any additional packages.
π» Use Cases
Finding the correct configuration of tsconfig for different Node.js projects is already relatively complicated. A simplified configuration that allows you to author compliant Typescript code that works smoothly with Node.js new out-of-the-box ts support via the --strip-types
flag would be a great help.
Activity
RyanCavanaugh commentedon Aug 12, 2024
#54283 is relevant here
Bnaya commentedon Aug 13, 2024
Feels like a lint rule and not a ts flag
I have a strong feeling that node will eventually support everything under
isolatedModules
, as it's the baseline for transformers these day and there you got your flag :)RyanCavanaugh commentedon Aug 13, 2024
Discussed a bit with some folks internally and there was possible appetite for this. This has been a longstanding request for other reasons (ideologically purity [complimentary], future-proofing, de facto tool support, etc). A sticking point is what the heck to name it and some suggestions to get the ball rolling would be useful.
marcomuser commentedon Aug 13, 2024
Wohooo! π₯³ So if you feel like poking a little fun at the ideological purity section, call it
--ecmaStrict
. πrobpalme commentedon Aug 13, 2024
Just to add to @RyanCavanaugh's list of reasons to add this mode: a further benefit not yet stated is that it will permit TypeScript (if the team wishes) to introduce a new JS emit mode that preserves JS syntax coordinates, meaning no sourcemap is required.
SWC have already shipped such an emitter written in Rust and compiled to Wasm. @acutmore will soon be open-sourcing another example of such an emitter - this time written in TypeScript.
ts-blank-space
is a type-stripper built on top of the TypeScript parser. It is ~700 lines of code. With large files it achieves a speed up of 4.7x relative to TS 5.5ts.transpileModule
withnoCheck
. With small files it goes even faster due to less GC.I agree the hardest problem is what to name it.
RyanCavanaugh commentedon Aug 13, 2024
I'll just start throwing ideas in:
--noTranspiledFeatures
--typeSyntaxOnly
--disallowRuntimeSyntax
Note that we almost always prefer a flag like this to be
false
by default, so the name should reflect thatmarcomuser commentedon Aug 13, 2024
I like the direction that
--typeSyntaxOnly
is taking, but given the waves that the stage 1 proposal has made already, I would change it slightly to match its title:--typeAnnotationsOnly
.allisonkarlitskaya commentedon Aug 16, 2024
Highly relevant:
This is early stuff, but it seems like this would probably be the thing to target with such an option.
RyanCavanaugh commentedon Aug 16, 2024
--typeSyntaxOnly
πRough notes
Who is this for?
Downsides: nothing allowed in .ts exactly replicates what
enum
does todayMust use
verbatimModuleSyntax
andisolatedModules
to turn this onApplies only to .ts, not .d.ts
Recommended to combine with
verbatimModuleSyntax
andisolatedModules
, but not requiredExact definition of what's disallowed and what's not
robpalme commentedon Aug 16, 2024
Thanks for the clear concise comprehensive update, @RyanCavanaugh.
This was the only surprise to me. I appreciate it does not emit anything so can be considered erasable. I'm curious why anyone would use this form and whether its used in real-life.
RyanCavanaugh commentedon Aug 16, 2024
Non-instantiated namespaces are need to do certain kinds of declaration merging, e.g. adding a no-emit
static
member to a classConaclos commentedon Aug 18, 2024
I still find confusing that
declare
is not required here to make the namespace ambient/non-instantiated.This requires extra work for a compiler/linter to check whether the namespace is ambient.
I really like this proposal from this design note.
Yes it is not a substitute, however it allows most of the cases users encounter and this provides a concise syntax for users that want to avoid runtime TS features.
38 remaining items