docs(ast): add allow(missing_docs) to all remaining fields for JS/TS nodes

[camchenry]

Requires that all new fields/structs/enums in the JS and TS files must have documentation.

[camchenry]

• docs(ast): add docs for all span fields for JS/TS nodes #8828
• docs(ast): add allow(missing_docs) to all remaining fields for JS/TS nodes #8827 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Performance Report

Merging #8827 will not alter performance

_{Comparing 02-01-docs_ast_add_allow_missing_docs_to_all_remaining_fields_for_js_ts_nodes (52eb944) with main (0568210)}

Summary

✅ 33 untouched benchmarks

[Boshen]

I think this is too much of a noise 🤔

[overlookmotel]

I'm afraid I tend to agree.

In fact, I'm not sure our aim should be to document every single struct field or enum variant. I am really big on code comments but, even with my pro-comments bent, I find that when the meaning is really obvious already, comments can take away readability more than they contribute to it, because they break up the code too much.

(I am thinking of how comments appear in the code itself, rather than the generated docs)

It's tricky! We ideally do want everything which isn't obvious documented, and lint rules prevent anyone forgetting to do that. But of course there's no way to teach clippy what's "important" and what's not.

For Span fields (#8828), it'd be extremely repetitious to have a comment on every single type. For that one, I suggest injecting the comments in the ast proc macro. That's trivial to do, and won't be too slow at compile time, as it's not complex code to generate. So that'd give us our cake (generated docs) and eat it too (no repetitious comments in the code). I've just overhauled oxc_ast_tools (#8844), which will make it easier to do that kind of thing. What do you think?