Script to generate docs for types and updated docs/types.md
I ended up writing a script to generate this documentation based of type definitions found in node_modules/@babel/types/lib/index.d.ts. It does so by looking through the properties of the export from @babel/types, seeing which functions (when turned to string, which is not a great idea) includes a call to _builder.default, then it looks into the index.d.ts file above, yet again using Regex and string matching, to extract the types.
This script is run by another script scripts/generate-docs-types-versions.js which creates a directory for each version, installs that version and generates the types.md using scripts/generate-docs-types.js. It's not exactly pretty, but it works.
I tried to keep line spacing and such similar to keep the diff as small as possible.
I'm not sure what to do with the version doc for version-6.26.3, as I'm not able to locate the babel package for that on npm.
Notable changes
- Call signature example only includes required arguments
- Alphabetical ordering for the functions and aliases
- Always includes
Aliases, even if there are none. - Assumed default values based on type
- Array
(default: []) - boolean (default:
false) - string (default:
"") - default (default:
null)
- Array
t.tsUnknownType(types)"renamed"t.tsUnknownKeyword(), fixes #2079- ~
t.import()has disappeared.~ (restored in 7dff70e)
Deploy preview for babel failed.
Built without sensitive environment variables with commit 9cd3f21594681aa6073611227db91c61acadb428
https://app.netlify.com/sites/babel/deploys/5fa51bdcc1a8640008299a7c
Not sure why there was merge conflicts here, but it looks like masters diff didn't like the re-ordering of the methods. Did a search to see that I didn't remove anything, but haven't checked for duplicates.
Good suggestions, I'll hopefully get around to picking this up again soon. Time flies.
Good suggestions, I'll hopefully get around to picking this up again soon. Time flies.
It does indeed, but better late than never I've heard.
The conflicts seem to be where there is additional data about when something was added, I might need to handle that case as well then.
In addition to generating the documents I've also tried to create some examples. They aren't always great, like f.ex. any extends any ? any : any. But in general they should give some sort of idea about what will happen when you call the code. It fails in a couple of cases because arguments that are indeed required does not appear so in type. That is something that can be fixed later in separate issues.