ultra
ultra copied to clipboard
exhibitionist-digital
Update contributor guidelines
As Ultra approaches the release of version 2, it seems like we need update our contributor guidelines to assure that code quality is maintained. We might want to start with the Deno style guide and add/subtract our own wrinkles
Please note the items you want to add or change in our contributor guidlines below.
My particular pet peeve at this point is to make sure that all functions and class methods have typed arguments and return values. Besides helping someone reviewing the code, it also is a big aid in developing and updating unit tests.
Linting should surely be picking all this up. Not sure about the return types though, as they're probably inferred by default. Maybe something we need to configure in the lint settings
I went through the Deno Style Guide (DSG) and came up with ones that I think we should consider supporting (or not). If you comment on this, please number them as I have done below:
- Should we require JSDoc comments? If so, where (see DSG rec https://deno.land/manual/contributing/style_guide.md#use-jsdoc-for-exported-symbols)?
- Should we require unit tests? If so, always or in only certain instances (see DSG: https://deno.land/manual/contributing/style_guide.md#each-module-should-come-with-a-test-module)?
- Should we follow DSG rec: Exported functions: max 2 args, put the rest into an options object (https://deno.land/manual/contributing/style_guide.md#exported-functions-max-2-args-put-the-rest-into-an-options-object).
- Should we follow DSG rec: Export all interfaces that are used as parameters to an exported member (https://deno.land/manual/contributing/style_guide.md#export-all-interfaces-that-are-used-as-parameters-to-an-exported-member)
- Should we follow DSG rec: Top level functions should not use arrow syntax (https://deno.land/manual/contributing/style_guide.md#top-level-functions-should-not-use-arrow-syntax).
- Not from DSG, but something else I think we should consider: Should we require the prefixing of commits and/or PR names (something like https://www.conventionalcommits.org/en/v1.0.0/)?
I personally think we should follow all the above. Would like to know how others feel about it @mashaal @dburles