Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

readonly and declare invalid property for MethodDefinition. #2908

Closed
3 tasks done
sosukesuzuki opened this issue Dec 29, 2020 · 2 comments
Closed
3 tasks done

readonly and declare invalid property for MethodDefinition. #2908

sosukesuzuki opened this issue Dec 29, 2020 · 2 comments
Labels
package: typescript-estree Issues related to @typescript-eslint/typescript-estree wontfix This will not be worked on

Comments

@sosukesuzuki
Copy link
Contributor

  • I have tried restarting my IDE and the issue persists.
  • I have updated to the latest version of the packages.
  • I have read the FAQ and my problem is not listed.

Repro

// the code you're trying to parse
class Foo {
  readonly bar() {}
  declare baz() {}
}
// the code you're using to do the parse of the aforementioned code
import { parse } from '@typescript-eslint/typescript-estree';

const code = `
class Foo {
  readonly bar() {}
  declare baz() {}
}
`;
const ast = parse(code);

Expected Result

Expect that MethodDefinition nodes have readonly and declare property.

AST
{
  "type": "ClassDeclaration",
  "id": {
    "type": "Identifier",
    "name": "Foo"
  },
  "body": {
    "type": "ClassBody",
    "body": [
      {
        "type": "MethodDefinition",
        "key": {
          "type": "Identifier",
          "name": "bar"
        },
        "value": {
          "type": "FunctionExpression",
          "id": null,
          "generator": false,
          "expression": false,
          "async": false,
          "body": {
            "type": "BlockStatement",
            "body": []
          },
          "params": []
        },
        "computed": false,
        "static": false,
        "kind": "method",
+        "readonly": true
      },
      {
        "type": "MethodDefinition",
        "key": {
          "type": "Identifier",
          "name": "baz"
        },
        "value": {
          "type": "FunctionExpression",
          "id": null,
          "generator": false,
          "expression": false,
          "async": false,
          "body": {
            "type": "BlockStatement",
            "body": []
          },
          "params": []
        },
        "computed": false,
        "static": false,
        "kind": "method",
+       "declare": true
      }
    ]
  },
  "superClass": null
}

Actual Result

AST
{
  "type": "ClassDeclaration",
  "id": {
    "type": "Identifier",
    "name": "Foo"
  },
  "body": {
    "type": "ClassBody",
    "body": [
      {
        "type": "MethodDefinition",
        "key": {
          "type": "Identifier",
          "name": "bar"
        },
        "value": {
          "type": "FunctionExpression",
          "id": null,
          "generator": false,
          "expression": false,
          "async": false,
          "body": {
            "type": "BlockStatement",
            "body": []
          },
          "params": []
        },
        "computed": false,
        "static": false,
        "kind": "method"
      },
      {
        "type": "MethodDefinition",
        "key": {
          "type": "Identifier",
          "name": "baz"
        },
        "value": {
          "type": "FunctionExpression",
          "id": null,
          "generator": false,
          "expression": false,
          "async": false,
          "body": {
            "type": "BlockStatement",
            "body": []
          },
          "params": []
        },
        "computed": false,
        "static": false,
        "kind": "method"
      }
    ]
  },
  "superClass": null
}

Additional Info

prettier/prettier#9760

I know the above code is invalid as TypeScript program (TS Playground). But I think code formatters should correctly treat those cases. What do you think about?

If the request is accepted, I can work on this.

Versions

package version
@typescript-eslint/typescript-estree master
TypeScript 4.1.2
node v14.8.0
@sosukesuzuki sosukesuzuki added package: typescript-estree Issues related to @typescript-eslint/typescript-estree triage Waiting for maintainers to take a look labels Dec 29, 2020
@bradzacher
Copy link
Member

Whilst the parser treats them as valid (because we throw no errors currently #1852) they shouldn't be included in the AST.

I think this falls into the same category as decorators on things that aren't classes - we don't error for them, we don't emit AST for them, and consumers can use the underlying TS AST to look for them if they want.

With the next major we'll start properly handling syntax errors, so this won't be an issue.

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for maintainers to take a look labels Dec 29, 2020
@sosukesuzuki
Copy link
Contributor Author

I got it. Certainly, it seems unreasonable for typescript-estree to address this problem.

@bradzacher bradzacher added wontfix This will not be worked on and removed awaiting response Issues waiting for a reply from the OP or another party labels Jan 8, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
package: typescript-estree Issues related to @typescript-eslint/typescript-estree wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants