Group dependabot updates to reduce noise/frequency for devDependencies/etc

I wonder if it might be useful to configure dependabot to differentiate between production and dev dependencies; and have them operate on different timelines.

I'm currently subscribed to all notifications on this repo, and often see pretty regular updates/churn in 'low value' dependencies; and I was thinking maybe that noise could be turned down by grouping those and updating it less frequently.

https://github.com/jehna/humanify/issues?q=sort%3Aupdated-desc+label%3Adependencies

We can see that a good number of those PR's are for devDependencies:

https://github.com/jehna/humanify/blob/7d26cdbfd462334af3056bc6814fbbcb73c21f0e/package.json#L49-L72

We can see the current configuration is pretty basic:

https://github.com/jehna/humanify/blob/7d26cdbfd462334af3056bc6814fbbcb73c21f0e/.github/dependabot.yml#L1-L7

Some starting points for the docs/etc:

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups

dependency-type: Use to specify a dependency type to be included in the group. dependency-type can be development or production.
https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#example-1

groups:
production-dependencies:
  dependency-type: "production"
development-dependencies:
  dependency-type: "development"
  exclude-patterns:
  - "rubocop*"
rubocop:
  patterns:
  - "rubocop*"

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#example-2

# `dependabot.yml` file with customized Bundler configuration
# In this example, the name of the group is `dev-dependencies`, and
# only the `patterns` and `exclude-patterns` options are used.
# Grouping rules apply to version updates only.

version: 2
updates:
# Keep bundler dependencies up to date
- package-ecosystem: "bundler"
  directories:
    - "/frontend"
    - "/backend"
    - "/admin"
  schedule:
    interval: "weekly"
  # Create a group of dependencies to be updated together in one pull request
  groups:
     # Specify a name for the group, which will be used in pull request titles
     # and branch names
     dev-dependencies:
        # Define patterns to include dependencies in the group (based on
        # dependency name)
        applies-to: version-updates # Applies the group rule to version updates
        patterns:
          - "rubocop" # A single dependency name
          - "rspec*"  # A wildcard string that matches multiple dependency names
          - "*"       # A wildcard that matches all dependencies in the package
                      # ecosystem. Note: using "*" may open a large pull request
        # Define patterns to exclude dependencies from the group (based on
        # dependency name)
        exclude-patterns:
          - "gc_ruboconfig"
          - "gocardless-*"

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleinterval
https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#ignore
- update-types: Use to ignore types of updates, such as semver major, minor, or patch updates on version updates (for example: version-update:semver-patch will ignore patch updates). You can combine this with dependency-name: "*" to ignore particular update-types for all dependencies. Currently, version-update:semver-major, version-update:semver-minor, and version-update:semver-patch are the only supported options.
https://slar.se/dependabots-dependency-grouping.html

For example, you could restrict version (not security) updates to once per week, or perhaps once per week just for devDependencies, or maybe ignoring patch releases for devDependencies or similar.

jehna / humanify

Group dependabot updates to reduce noise/frequency for devDependencies/etc #125