Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Script to generate docs for types and updated docs/types.md #2080

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

deificx
Copy link

@deificx deificx commented Aug 9, 2019

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)
  • t.tsUnknownType(types) "renamed" t.tsUnknownKeyword(), fixes t.tsUnknownType is documented but doesn't exist #2079
  • t.import() has disappeared. (restored in 7dff70e)

@netlify
Copy link

netlify bot commented Aug 9, 2019

@deificx
Copy link
Author

deificx commented Aug 9, 2019

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.

const sections = [];

for (const type in t) {
const isBuilder = /_builder\.default/.test(t[type].toString());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should include not just the builder, but as well as assert* and is* utility functions

see.is = type;
}
}
return `See also \`t.${see.is}(node, opts)\` and \`t.${
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if see.is or see.assert is not available, wouldn't it be See also and ?
maybe a join with " and " would be better?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and if we adding is and assert section, maybe this can be a link to the section

tanhauhau referenced this pull request in tanhauhau/tanhauhau.github.io Sep 9, 2019
@@ -0,0 +1,287 @@
const fs = require("fs");
const path = require("path");
const t = require("@babel/types");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this configurable, to be able to generate them from master?

node scripts/generate-docs-types.js --path ../babel/packages/babel-types

const { promisify } = require("util");

const readfile = promisify(fs.readFile);
const writefile = promisify(fs.writeFile);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can do const fs = require("fs").promises instead

@@ -0,0 +1,72 @@
const fs = require("fs");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this file? Ideally we would only need to generate docs for the new current version in the future.

@deificx
Copy link
Author

deificx commented Oct 28, 2019

Good suggestions, I'll hopefully get around to picking this up again soon. Time flies.

@deificx
Copy link
Author

deificx commented Nov 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

t.tsUnknownType is documented but doesn't exist
3 participants