Support Project Archetypes

[daedalus28]

For use in our application projects

[sean-clayton]

So I've been coming up with an API for configuration and this is what I have:

{
  "extends": ["smartprocure-duti-application"], // <-- Able to extend other configurations
  "directories": ["web", "api"], // <-- Tells duti to gather data from all of these directories
  "rules": {
    "readmeUpdate": "disabled", // <-- This disables the "emptyChangelog" function from running
    "requestedReviewers": ["warn", { "recommendedPrReviewers": 2 }], // <-- Makeshift tuple—1st item is the severity, 2nd item is configuration
    "bigPr": { "prNetChangeThreshold": 500 } // <-- If you pass just a configuration object, the severity is the default
  }
}

Thoughts?

[daedalus28]

It basically mimics the eslint config api which is great.

Some Notes

• I'm a bit blurry on what directories will do.
• I don't think we need a tuple style syntax - just pass an object to the methods (e.g. just extend the config object)

[stellarhoof]

I'm not clear on what the motivation for using JSON for configuration was. Why was it preferred over JS? If users of the library want to implement their own "duties" we'd have to design a JSON api to compose their duties into the config file. If we go the other route and support both dangerfiles in JS and the JSON config file separately then why have a JSON config at all?

[daedalus28]

The original theory was to match the approach of eslint and webpack config. However, given the pattern the community has of danger plugins which are just functions, we probably don't need to pursue the json configuration route and can simply wrap up multiple functions in higher order ones.