Skip to content

Tsconfig option to disallow features requiring transformations which are not supported by Node.js' --strip-types #59601

Closed
@marcomuser

Description

@marcomuser

πŸ” Search Terms

--strip-types

βœ… Viability Checklist

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
    This wouldn't change the runtime behavior of existing JavaScript code
    This could be implemented without emitting different JS based on the types of the expressions
    This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
    This 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

RyanCavanaugh commented on Aug 12, 2024

@RyanCavanaugh
Member

#54283 is relevant here

Bnaya

Bnaya commented on Aug 13, 2024

@Bnaya

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

RyanCavanaugh commented on Aug 13, 2024

@RyanCavanaugh
Member

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

marcomuser commented on Aug 13, 2024

@marcomuser
Author

Wohooo! πŸ₯³ So if you feel like poking a little fun at the ideological purity section, call it --ecmaStrict. 😁

robpalme

robpalme commented on Aug 13, 2024

@robpalme

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.5 ts.transpileModule with noCheck. With small files it goes even faster due to less GC.

I agree the hardest problem is what to name it.

RyanCavanaugh

RyanCavanaugh commented on Aug 13, 2024

@RyanCavanaugh
Member

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 that

marcomuser

marcomuser commented on Aug 13, 2024

@marcomuser
Author

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

allisonkarlitskaya commented on Aug 16, 2024

@allisonkarlitskaya

Highly relevant:

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.

RyanCavanaugh

RyanCavanaugh commented on Aug 16, 2024

@RyanCavanaugh
Member

--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 enum does today

Must use verbatimModuleSyntax and isolatedModules to turn this on

Applies only to .ts, not .d.ts

Recommended to combine with verbatimModuleSyntax and isolatedModules, but not required

Exact 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;
}
robpalme

robpalme commented on Aug 16, 2024

@robpalme

Thanks for the clear concise comprehensive update, @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.

RyanCavanaugh

RyanCavanaugh commented on Aug 16, 2024

@RyanCavanaugh
Member

Non-instantiated namespaces are need to do certain kinds of declaration merging, e.g. adding a no-emit static member to a class

Conaclos

Conaclos commented on Aug 18, 2024

@Conaclos

namespace T { } // OK (type-only)

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.

const foo = {...} as enum

Wouldn'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.

38 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

CommittedThe team has roadmapped this issueHelp WantedYou can do thisSuggestionAn idea for TypeScript

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @ljharb@danfo@justinfagnani@Bnaya@Conaclos

      Issue actions

        Tsconfig option to disallow features requiring transformations which are not supported by Node.js' --strip-types Β· Issue #59601 Β· microsoft/TypeScript