Open thescientist13 opened 5 days ago
JSDocs for the maintainers, with generated output for the users? Typically there's a line between what the engineers need to know, vs. what the end-user needs to know. The crossover is where the JSDocs might be helpful, at least to start. Along with using the @private
or @internal` tags, the output can be isolated to only the public API.
Docs are along side the code, and the curated generated docs can target other users.
As an example, consider the details around each-and-every Type in a library like Webpack. The end-user doesn't have docs for all of it, but it might be important for maintainers to know what's going on in the JSDoc comment / intellisense.
Just my 🪙 🪙
Good thoughts, thanks for sharing!
Yeah, I've been thinking about this for Greenwood (and TypeScript support overall) since it doesn't really have many APIs that actually introduce themselves into userland, other than the good point you make about plugin(s) (development), greenwood.config.js, and now our content as data APIs. Maybe you can share more thoughts in this issue, since I think that would apply more specifically to project, and not the docs website per se.
(This particular issue is specifically about where the current content for our plugins should live; in the website and the package README, which is what we'll have in place when we launch this new website, or just on the website, and thus the README pages would just link to the website.)
Discussed in https://github.com/ProjectEvergreen/www.greenwoodjs.dev/discussions/104