fix(ast/estree): make TS-only fields optional in TS type defs

[overlookmotel]

When the source type is JS/JSX, parseSync returns an AST without any of the TS fields present (properties not present at all, not just defined as undefined / null). So to make our type defs match that AST (and also the TS AST which does have these fields), these fields need to be optional.

[overlookmotel]

• fix(ast/estree): make TS-only fields optional in TS type defs #9846 👈 (View in Graphite)
• fix(ast/estree): add directive field to ExpressionStatement in TS AST #9844
• feat(ast_tools): support #[ts] attr on converter meta types #9843
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[overlookmotel]

@hi-ogawa I'm not a TypeScript user, and don't understand the TS syntax well. Can you please check this is correct?

[hi-ogawa]

Makes sense to me 👍 This can potentially give inconvenience for users expecting typescript estree types, which has some fields strictly defined (for examples Class.implements array https://github.com/typescript-eslint/typescript-eslint/blob/3efd99e954d1749225d65b774cfb3650a54ff083/packages/ast-spec/src/base/ClassBase.ts#L50), but this typing is more correct as oxc types.

Additionally, I think we can add jsdoc on each ts-only fields, so it's easier to tell which fields can be assumed to be strictly defined when users are exclusively using astType: 'ts' parser.

[hi-ogawa]

Merge activity

• Mar 18, 3:39 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 18, 3:39 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 18, 3:53 AM EDT: A user merged this pull request with the Graphite merge queue.

[overlookmotel]

Thanks for reviewing. We could also codegen 2 sets of types for JS-only and with-TS ASTs. As we're codegen-ing everything, that wouldn't be too much work.

But I don't know if it'd be an improvement or not, because parseSync returns one or the other depending on input. That's not possible to statically type, I don't think.

[hi-ogawa]

Thanks for reviewing. We could also codegen 2 sets of types for JS-only and with-TS ASTs. As we're codegen-ing everything, that wouldn't be too much work.

But I don't know if it'd be an improvement or not, because parseSync returns one or the other depending on input. That's not possible to statically type, I don't think.

I don't think it's necessary right now, but just providing ts ast types can be useful without coupling with parseSync since that allows using that type mostly and only need program as any as TsProgram in one place.