Repository navigation
Tsconfig option to disallow features requiring transformations which are not supported by Node.js' --strip-types #59601
Description
Activity
#54283 is relevant here
Reacted by Marco Ippolito and Cody EbbersonReacted by Marco Muser, Bnaya Peretz and Cody EbbersonFeels 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 :)Reacted by Daniel Johns and OmriDiscussed 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.
Reacted by Marco Muser, Rob Palmer, Victorien Elvinger, Simon Mumenthaler, Phips Peter and Cody EbbersonWohooo! 🥳 So if you feel like poking a little fun at the ideological purity section, call it
--ecmaStrict. 😁Reacted by Daniel Johns, Dieter Oberkofler, Milan Raj, Rafaa and Cody EbbersonJust to add to Ryan Cavanaugh (@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. Ashley Claymore (@acutmore) will soon be open-sourcing another example of such an emitter - this time written in TypeScript.
ts-blank-spaceis 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.transpileModulewithnoCheck. With small files it goes even faster due to less GC.I agree the hardest problem is what to name it.
Reacted by Marco Muser, Daniel Johns, Simon Mumenthaler, Phips Peter, Peter Leonov and Cody EbbersonReacted by Andrew Johnston, Phips Peter and Cody EbbersonI'll just start throwing ideas in:
--noTranspiledFeatures--typeSyntaxOnly--disallowRuntimeSyntax
Note that we almost always prefer a flag like this to be
falseby default, so the name should reflect thatI like the direction that
--typeSyntaxOnlyis taking, but given the waves that the stage 1 proposal has made already, I would change it slightly to match its title:--typeAnnotationsOnly.Highly relevant:
- https://github.com/tc39/proposal-type-annotations#proposal
- https://tc39.es/proposal-type-annotations/
No, not all of today's TypeScript syntax would be supported by this proposal. This is similar to how Babel support for TypeScript does not support all of the existing TypeScript syntax.
For example enums, namespaces and class parameter properties are unlikely to be supported. In addition, specifying type arguments at function call-sites will require a slightly different syntax.
This is early stuff, but it seems like this would probably be the thing to target with such an option.
--typeSyntaxOnly👍Rough notes
Who is this for?
- Ideological purists
- Space-only transpilation users
- Today's version of node (but not tomorrow's?)
- Forward-versioning safety if committee changes its mind about enum
- People who don't like adding a linter
- Keep syntax in the space that's likely to be support by type annotations in JS, if that ever happens
Downsides: nothing allowed in .ts exactly replicates what
enumdoes todayMust use
verbatimModuleSyntaxandisolatedModulesto turn this onApplies only to .ts, not .d.ts
Recommended to combine with
verbatimModuleSyntaxandisolatedModules, but not requiredExact definition of what's disallowed and what's not
import x = require('fs'); // no (CJS+VMS will not have a good workaround at this time) import A = e.p; // no class X { public x; // OK (just erase `public`) constructor(public y) { } // not OK - runtime-observable } enum X { } // All forms (including `const`) not OK namespace T { } // OK (type-only) namespace X { // Not OK (instantiated) const x = 1; }
Reacted by Marco Muser, Rob Palmer, Théo LUDWIG, Phips Peter, zanminkian, mkrause, Camilo Santos and honey32Thanks for the clear concise comprehensive update, Ryan Cavanaugh (@RyanCavanaugh).
namespace T { } // OK (type-only)
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.
Non-instantiated namespaces are need to do certain kinds of declaration merging, e.g. adding a no-emit
staticmember to a classnamespace T { } // OK (type-only)I still find confusing that
declareis 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.const foo = {...} as enumWouldn't be a full substitute.
const x = { a: 1, b: a, // can't do this } as enum;
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.Reacted by Victorien Elvingerdeclare namespaceis not a replacement for type-only namespaces; you can declare any value-space thing and it will "just work". Code like:declare namespace T { export function doSomething(): void; } console.log(T.doSomething())
Will typecheck, but then crash at runtime.
This syntax is designed for declaring things that already exist in the runtime environment (think
declare var __webpack_require__: any), which is a generally useful thing, but isn't a safe replacement.Compare that to a rule which bans "instantiated namespaces", complaining about the value declaration.
Reacted by Victorien Elvinger8 remaining items
Absent a name everyone likes, we found a name no one objected to:
erasableSyntaxOnlyIf anyone wants to send a PR for this in the next week or two LMK, otherwise we'll implement.
Reacted by Jacob Smith, Vladimir Krasnochub, Phips Peter, Kenta Moriuchi, Haroen Viaene, Turadg Aleahmad and Endel DreyerReacted by Rob Palmer, Théo LUDWIG, Marco Muser, Marco Ippolito, Jordan Harband, Jacob Smith, Simon Mumenthaler, Daniel Johns, Tim, Justin Fagnani and 3 moreSince
experimentalDecoratorshas it's own flag, it probably doesn't to be covered inerasableSyntaxOnly. If someone writes a config with botherasableSyntaxOnly: trueandexperimentalDecorators: truethen they probably meant that.Given that configs can be extending other ones, I'm not sure one can assume it was intended.
Reacted by Marco MuserLooking forward to this. I guess this is ~dupe of #39961, back then I thought something like this might cause least trouble,
experimentalAbstractClasses: boolean; // default true experimentalDecorators: boolean; // default false experimentalEnums: boolean; // default true experimentalParameterProperties: boolean; // default true
Daniel (@danfo) those options names don't make sense to me because only decorators was ever experimental - the others are enabled by default and not opt-in.
#61011 is merged, which will be in 5.8 beta. Happy coding!
Reacted by Riley Hood, Jordan Harband, silverwind, Marco Muser, Théo LUDWIG, Rob Palmer, Madeline Gurriarán, Pip Rees, mkrause, Vladimir Krasnochub and 10 moreWouldn't it be better to add some api for Node.js, Bun, esbuild, deno and all the others to allow for actual TypeScript support with typechecking instead of adding more "Typescript support but not really"? 🙃
Some say tsc is just to slow
What about class decorators and explicit resource management? Both requires transpiling but
--erasableSyntaxOnlydoes not control their use. Example:export const decorator = (cls: unknown, context: ClassDecoratorContext) => {}; @decorator class C { } { using c = new C(); }
What about class decorators and explicit resource management? Both requires transpiling but
--erasableSyntaxOnlydoes not control their use. Example:export const decorator = (cls: unknown, context: ClassDecoratorContext) => {}; @decorator class C { } { using c = new C(); }
The syntax that is coming into the language (decorators, using etc...) is not banned, but simply Node.js javascript engine does not support it yet
Reacted by Ryan CavanaugherasableSyntaxOnlyis very explicitly not a moving-target flag that corresponds to exactly whatever syntax some version of nodejs currently supports. It is about banning syntax that can't be correctly handled by an "erase-only" transpiler, i.e. one that has to produce an output file that is not longer than the input file.Reacted by Marco Muser, Justin Fagnani, Sam Varga, Kasopej and Vas Sudanagunta
🔍 Search Terms
--strip-types
✅ Viability Checklist
⭐ 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:
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-typesflag would be a great help.