Open kieranhall opened 10 months ago
We already used it in our toy repo, and I think it's a good fit for libraries, but I don't think it's worth it in an app, unless you restrict it to some parts of the $lib
folder.
So I see two scenarios:
Why would you not want to only use these rules outside of the $lib? I think that having JSDoc comments with useful descriptions can be useful in all components. We might not generate a HTML documentation from these comments (although, it could be interesting to see what that would look like), but structured comments like these with good descriptions can make for much more maintainable code.
Why would you not want to only use these rules outside of the $lib? I think that having JSDoc comments with useful descriptions can be useful in all components. We might not generate a HTML documentation from these comments (although, it could be interesting to see what that would look like), but structured comments like these with good descriptions can make for much more maintainable code.
Oh, no, I explained myself badly. It's not that I don't want it, it's that I think that they are often unnecessary and (reusable) components are often better off with a storybook. But, you're right, if we're going to release open source code we should be more thorough anyway.
In the case of components it'll be also a bit harder to have proper JSDoc (as in comments with the purpose of generating HTML documentation).
I think it could be nice for us to, for example, have a less strict linting policy for JSDoc, but then have the option to, in the future, make these more strict. This way, we can always identify and enforce something we later consider important and have an easy refactoring for all the projects using this eslint config version.
By adding eslint-plugin-jsdoc we can have more confidence in the quality of the documentation of our code.