Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
docs(ast-spec): add script to generates code strings for the doc files#3248
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Thanks for the PR,@bradzacher! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently onhttps://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitorsper day. |
d061042 tob00a8ccCompareFixes#2726Fixes#2912This PR is the basis for a big cleanup and reorganisation of the AST.This first step takes the file `types/src/ts-estree.ts` and splits it up in its entirety.This file was a monolith at 1700 lines - meaning it was a pain to organise and manage, and there was no way to isolate/restrict certain things (aside from adding comments).This PR should ultimately be a no-op - there should be no breaking changes here.I did fix up a number of types which I found when organising files into their folders.Whilst this PR ultimately creates more LOC, the isolation enables a few things:- By splitting the AST into its own module, it's isolated so easier to manage / govern- By splitting each AST node into its own folder we can cleanly document and link to individual node specs- By grouping nodes decls by folder, it's easier to inspect the types to validate unions are correct. - I found a number of invalid nodes in unions in this PR which have been fixed.- In a future PR we can: - Add lint rule(s) to validate unions are correct (eg ensure all `Expression` types are included in the `Expression` union). - Easily add documentation about the node without cluttering things up - Colocate fixtures/snapshots with the node specs to document the cases that we expect a node to show up - Colocate the conversion logic here so that it's easier to validate that the spec and the conversion logic are in sync - This will make it much easier to implement and maintain#1852
I'm not sure if we will want to actually use this or not.This was just an idea I had to allow us to embed the relevant code samples directly in a `.md` file saving consumers from having to switch between the .ts file and the .md file.We could ofc just embed the file itself, but that's not as elegant as there's the extra cruft of `export` and `import`s.May end up just ditching this... but it was worth putting it up for posterity.As an� example - this script generates the following output for `ClassProperty.ts`:```tsinterface ClassPropertyComputedName extends BaseNode { type: 'ClassProperty'; key: Expression; computed: true; value: Expression | null; static: boolean; declare: boolean; readonly?: boolean; decorators?: Decorator[]; accessibility?: "private" | "protected" | "public"; optional?: boolean; definite?: boolean; typeAnnotation?: TSTypeAnnotation;}interface ClassPropertyNonComputedName extends BaseNode { type: 'ClassProperty'; key: Identifier | NumberLiteral | StringLiteral; computed: false; value: Expression | null; static: boolean; declare: boolean; readonly?: boolean; decorators?: Decorator[]; accessibility?: "private" | "protected" | "public"; optional?: boolean; definite?: boolean; typeAnnotation?: TSTypeAnnotation;}type ClassProperty = | ClassPropertyComputedName | ClassPropertyNonComputedName;```b00a8cc tof1b42daCompare3f04cd5 toa5f8933Compare
Uh oh!
There was an error while loading.Please reload this page.
I'm not sure if we will want to actually use this or not.
This was just an idea I had to allow us to embed the relevant code samples directly in a
.mdfile saving consumers from having to switch between the .ts file and the .md file.We could ofc just embed the file itself, but that's not as nice because:
exportkeywords.importstatements.ClassPropertyis a union of two typesClassPropertyComputedNameandClassPropertyNonComputedNameClassPropertycase both the types extend base classes of similar names.We may end up just ditching this... but it was worth putting it up for posterity.
As an example - this script generates the following output for
ClassProperty: