graphql-eslint VS estree

You can read more on this blog post and also check out the new graphql-eslint website (with the online interactive playground)

GraphQL ESLint for validation, linting, and checking for best practices and conventions (like all resolvers must be camel case!!! 💀).

## Next Steps Check out [the roadmap for the V4 version](https://github.com/B2o5T/graphql-eslint/issues/981), the next major will be released once ESLint 9 will out and of course, propose your suggestions 🙂. Don't forget to give a star ⭐️ for [GraphQL-ESLint](https://github.com/B2o5T/graphql-eslint) if you like it! And Happy New 2023 Year! 🎄🎉 🥂 ### Community Thanks to our contributors @FloEdelmann, @TuvalSimha and @tshedor.

This is cool. How much overlap does it have and/or not have with https://github.com/B2o5T/graphql-eslint ?

Those could be standards that are specific for a single codebase or shared in the community. As the GraphQL ecosystem is growing quickly, we decided it's important to create a modern integration between GraphQL and ESLint, that supports all the modern needs of a GraphQL developer: graphql-eslint.

Want to have ESLint support to enforce standards and maintain sanity across your team, try something like GraphQL ESLint and set it up with your preferred conventions.

GraphQL ESLint

In the previous blog, we had started going through "The GraphQL Stack" that we use at Timecampus going through various libraries and tools like VSCode, GraphQL Config, VSCode GraphQL, GraphQL ESLint, GraphQL Inspector, Typescript, GraphQL Helix and GraphQL Codegen. In this blog, we will continue our journey exploring from where we left off.

ESLint's AST format, ESTree, would represent this line of code as:

That was a super interesting link, thank you.

For the ontological problem, I presume you're referring to how there are so many differing ideas of how to represent ASTs (apologies for mixing languages, these URLs were just handy):

* https://lisperator.net/uglifyjs/ast#nodes

* https://github.com/estree/estree#the-estree-spec

* ... likely others

which makes it hard for ls1 to ask ls2 about "the for-of iteration variable Node" because ls2 could be using UglifyJS or ESTree or their own(!) AST nomenclature?

And all of this is made worse by (e.g.) Java1.3 versus Java19 because languages are rarely static

I find it better to actually look at the AST for javascript.

These are expressions:

https://github.com/estree/estree/blob/master/es5.md#expressi...

These are statements:

https://github.com/estree/estree/blob/master/es5.md#statemen...

I guess the confusing part for many is how an expression can also be a statement. But if you look at the ExpressionStatement you see that an expression is not also a statement. It's just the wrapper statement!

When I started the NodeSecure project I had almost no experience 🐤 with AST (Abstract Syntax Tree). My first time was on the SlimIO project to generate codes dynamically with the astring package (and I had also looked at the ESTree specification).

ESTree compatible output, AST explorer on WASM

The parser we wrote transforms the GraphQL AST into ESTree structure, so it allows you to travel the GraphQL AST tree easily.

For espree parser(the one eslint uses) we can refer here Eslint AST Node Types