Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

AST: provide better discriminated unions for ambiguous node types #6434

Open
Assignees
Josh-Cena
Labels
ASTPRs and Issues about the AST structureaccepting prsGo ahead, send a pull request that resolves this issueenhancementNew feature or requestpackage: ast-specIssues related to @typescript-eslint/ast-spec
@bradzacher

Description

@bradzacher

Some of the nodes in the AST have certain constraints to which they must adhere which are discriminated by some property on the node.

As an example - if aMemberExpression has.computed = false, then the.propertymust only beIdentifier | PrivateIdentifier. For this specific case we clearly include this discriminated union in the AST types to make it easier for users to consume the AST without performing unnecessary checks to appease the types:

interfaceMemberExpressionBaseextendsBaseNode{
object:Expression;
property:Expression|Identifier|PrivateIdentifier;
computed:boolean;
optional:boolean;
}
exportinterfaceMemberExpressionComputedNameextendsMemberExpressionBase{
type:AST_NODE_TYPES.MemberExpression;
property:Expression;
computed:true;
}
exportinterfaceMemberExpressionNonComputedNameextendsMemberExpressionBase{
type:AST_NODE_TYPES.MemberExpression;
property:Identifier|PrivateIdentifier;
computed:false;
}
exporttypeMemberExpression=
|MemberExpressionComputedName
|MemberExpressionNonComputedName;

We have been pretty conservative (read: lazy 😅) with this work though and there are a lot more cases we could discriminate things further.

Specifically we could further discriminate the following cases:

  • Property
    • Object literal property vs Object pattern property.
      • Pattern
        • An object pattern property.value can only ever beIdentifier | ArrayPattern | ObjectPattern | AssignmentPattern, but an object literal property can beExpression.
        • An object pattern property can only ever bekind = 'init'
      • Literal
        • An object literal property cannot have.value = ObjectPattern | ArrayPattern | AssignmentPattern
      • For this case, I would envision that we would use the correct subtype for the specific nodes, i.e.:
        • ObjectExpression would useObjectExpressionProperty, notProperty.
        • ObjectPattern would useObjectPatternProperty, notProperty.
        • Property would be a union ofObjectExpressionProperty | ObjectPatternProperty.
    • .shorthand = true
      • .key and.value mustalways beIdentifier
      • Cannot have.computed = true
      • Cannot have.kind = 'get' | 'set'
      • Cannot have.method = true
    • .kind = 'get' | 'set'
      • Must have.value = FunctionExpression | TSEmptyBodyFunctionExpression
      • Cannot have.shorthand = true
    • .kind = 'init' && .method = true
      • Must have.value = FunctionExpression | TSEmptyBodyFunctionExpression
      • Cannot have.shorthand = true
  • BinaryExpression
    • in allows private brand checks like#priv in expr.
      All other operators do not allow a lone private identifier in the.left
  • MethodDefinition
    • kind = 'constructor'
      • Cannot have.computed = true
      • Cannot have.static = true
      • Cannot have.optional = true
    • kind = 'get' | 'set'
      • Cannot have.optional = true
  • ArrowFunctionExpression
    • .expression = true
      • .value cannot beBlockStatement
  • YieldExpression
    • .delegate = true
      • .argument must be defined
  • TSTypePredicate
    • .asserts = false
      • .typeAnnotation must be non-null
  • UnaryExpression
    • .prefix must always betrue

Metadata

Metadata

Assignees

Labels

ASTPRs and Issues about the AST structureaccepting prsGo ahead, send a pull request that resolves this issueenhancementNew feature or requestpackage: ast-specIssues related to @typescript-eslint/ast-spec

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions


    [8]ページ先頭

    ©2009-2025 Movatter.jp