openapi-preprocessor VS estree

I use a mixed approach for OpenAPI, but not bidirectional.

I have OpenAPI pieces generated from my Go source code (comment, types, function signatures) as JSON.

I also have a manually-edited master YAML document that refers to generated bits via $ref links.

I then use openapi-preprocessor [1] (disclaimer: I wrote it) to produce a final openapi.json file which is committed in the repo.

When I want to extend the API in a spec-first process, I can add the new routes manually in the YAML file. When I do the implementation I replace the manual bits by the generated one when they are ready. When committing I can check the diff of openapi.json to verify I'm not losing in the process.

[1] https://github.com/dolmen-go/openapi-preprocessor

Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.

A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor

https://github.com/dolmen-go/openapi-preprocessor

I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.

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