TypeScript 3.8 Syntax Support

[armano2]

3.8 requires new AST nodes and to support the new syntax.

Type Import (#1697) (SUPPORTED)

import type { SomeThing } from "./some-module.js";
export type { SomeThing };

export * as ns Syntax (#1698) (SUPPORTED)

export * as utilities from "./utilities.js";

ECMAScript Private Fields (NOT YET SUPPORTED - see #3430)

AST: estree/estree#222

Important Note
We currently "support" such that no tooling should fail on private fields.

However, the AST that is produced is not considered stable and will change in future without a major release. Any tooling looking to lint private fields should not rely upon the representation (or be prepared to handle a breakage).

Why don't we have support yet?

In short: we are awaiting agreement on the AST representation from the ESTree spec.

For the 3.7 release we jumped the gun and eagerly implemented optional chaining using babel's AST representation, thinking that the ESTree spec, would just go with that. However ESTree is going with a different and incompatible representation entirely. This will cause our project (and users) a lot of pain as we will have to do a major, breaking change to the AST to align with what ESLint core will use.

To avoid going through the same pain again with private class fields, we're holding off on official support until ESTree has decided upon a representation.

There are a lot of projects, and a lot of volunteers that collaborate on the ESTree spec, so things take time; please be patient.

class Person {
    #name: string
    
    constructor(name: string) {
        this.#name = name;
    }

    greet() {
        console.log(`Hello, my name is ${this.#name}!`);
    }
}

let jeremy = new Person("Jeremy Bearimy");

jeremy.#name

Read more:

https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/

[armano2]

As for Private Fields babel already supports it as

ClassPrivateProperty
  - key: PrivateName
    - id: Identifier
  - value: Expression
  - static: boolean
  - typeAnnotation: TypeAnnotation

[sebinsua]

Perhaps a lint rule could be created to only allow types to be imported and exported with the new "type import" syntax? That makes it less likely that Babel users will get types in their JavaScript output.

Is there a feature request issue for that yet?

[vkrol]

@sebinsua

Perhaps a lint rule could be created to only allow types to be imported and exported with the new "type import" syntax?

See importsNotUsedAsValues option https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/#type-only-imports-exports.

Copy-pasted from babel/babel#8361 (comment).

[joaovieira]

This was already mentioned in babel/babel#10981 (comment), but wanted to put it here as well. Would be good if we can use the same node property to identify type imports both from Flow and TS (i.e. importKind: "type"), so existing tooling works OOTB with TS. For example, eslint-plugin-import already handles (Flow) type imports in many places.

[armano2]

@joaovieira thats how its implemented for now, i'm following up ticket at babel and i will align it if changes will be needed

see #1465

[calebeby]

@vkrol the importsNotUsedAsValues TS option only will tell you when you are not using import type when you should be. An ESLint rule would be useful to auto-fix it.

[AlCalzone]

Just out of interest: When do you guys plan to ship a version with support for TS 3.8?

Type-only imports solve quite a few circularity issues in a project of mine, so I'm eager to use the new features. Unfortunately neither Babel, nor ESLint/Prettier have support yet.

Edit: Not sure why I'm being downvoted. Just a rough estimate would be nice so I don't have to check the linked issues every few days. If it takes 2 months, so be it...

[bradzacher]

#1465 (comment)

[vegerot]

Question: Does ESTree still not support private class fields? This blocks #1666

[bradzacher]

ESTree does not fully support it yet.
It has a preliminary, experimental AST (https://github.com/estree/estree/blob/master/experimental/class-features.md) - however there's no guarantee that this AST will be the final AST until the class feature specs advance to Stage 4.

Looking at the recent TC39 notes - it looks like the features are very close to proceeding to stage 4.

I'm undecided if we want to move to implement the proposed AST right now. We would be the first implementors, and doing so would break any rules that rely upon the current representation babel uses. There's also no guarantee that the preliminary AST won't change before finalisation - which would be a breaking change to deal with.

I think it's probably better to keep it in limbo for the moment, and keep tracking the TC39 progress.

[ljharb]

It’s shipped in multiple browsers - it’s highly unlikely to change in a meaningful way, like every stage 3 feature.

[dimitropoulos]

I totally agree about waiting, for whatever it's worth. Don't want a repeat of the optional chaining situation.

@ljharb in my opinion the deeper problem is not with whether it's at stage 3 or not - but whether the upstream support exists (in ESTree). This project can land itself in quite a mess if it implements something that later is changed (which has happened and has happened recently). ESTree would be a better place to make an issue or offer support.

To me, if the AST structure is firmly decided upon, then it doesn't really matter if it's stage 4. The thought-experiment you might conduct to verify this would be to ask if anything about this issue would be different if TC-39 had happened to promote it to stage 4 in the last meeting in September. I think the answer is no: we'd still be right where we are (from the vantage point of typescript-eslint, I mean, waiting for ESTree).

[ljharb]

@dimitropoulos that's a totally fair point, and is why I continue to hope ESTree changes its policy and starts supporting shipped stage 3 syntax by default.

[LukasMachetanz]

Hey. I am wondering if there is a rough estimation when this will be finished? Thanks in advance. :)

[bradzacher]

When will private fields be ready?
When the feature reaches stage 4, ESTree's spec will be finalised.
When it's finalised, we can implement it.

When will that be?
When it's done. [1]
We don't know and are not at all involved in the timelines or progress of the other projects we are dependent on.

What's the status of support in this project?
All 3.8 features are fully supported - apart from private fields.
Private fields have support in that they won't break, and an AST is emitted for them.

What if I want to lint private fields?
You can use the experimental AST we produce for private fields.
But just be aware that it is exactly that - experimental, unstable and subject to change without a major bump.

^{[1] I can give you this piece of string to measure in the meantime.}

[LukasMachetanz]

Hey. I would like to ask again what's the current status? Any updates since #1436 (comment)? Thanks.

[bradzacher]

We do all of our work in the open. Nothing is private. You can see PRs linked to this issue.