Third-party dependency upgrades are not delayed by 7 days

[onebytegone]

In the config we specify that most packages shouldn't be upgraded for 7 days. However, in cases like onebytegone/cloud-utils#39, the PR for the dependency upgrade was submitted the same day as the new version.

Desired behavior

• PRs to upgrade any @silvermine/* packages can be created immediately
• PRs to upgrade all other packages should be only be created if the package version has been released for at least 7 days

[MatheusBaldi]

@onebytegone The documentation suggests adding the internalChecksFilter option as 'strict', so I prepared PR with that suggestion.

I had a slight suspicion that Renovate bot could be unsure whether to use default.json or renovate.json file as its config, so this PR also removes the renovate.json file that used to be the default name for config files in previous Renovate versions but has been deprecated.

I'm not sure how to test though, but I'll open the PR for it.

[onebytegone]

@MatheusBaldi It seems the changes in #3 has made renovatebot replace the by-package PRs (e.g. silvermine/toolbox#96) with one "update all the packages" PR (e.g. silvermine/toolbox#99). Able to investigate why? It would be ideal to keep the by-package PRs.

[MatheusBaldi]

@onebytegone It is possibly a behavior coming from the config:recommended preset that's being extended renovatebot/renovate#24071 (reply in thread). I've read some of their docs and this solutions seems worth trying. Here are some of the resources:

How presets work: https://docs.renovatebot.com/config-presets/
Recommended presets config: https://docs.renovatebot.com/presets-config/#configrecommended
How ignorePresets work: https://docs.renovatebot.com/presets-config/#configrecommended

I'll open a PR with this solution.

If it works, but only a few pull requests are being created when there are many more packages to be updated, there is a follow up solution in the discussion referenced above that can be added in a future PR renovatebot/renovate#24071 (reply in thread).

[onebytegone]

@MatheusBaldi The default behavior of grouping monorepos is what we want (e.g. all @aws-sdk/* packages should be updated at the same time). That said, I think those docs revealed the issue. Our config for setting minimumReleaseAge also defines a groupName. This causes all matching packages to be grouped into a single PR (this is how renovate groups all monorepo packages together). We initial added groupName thinking it was just a documentation field, not something that impacts behavior. Would it be possible to try removing groupName rather than disabling the config presets?

[MatheusBaldi]

@onebytegone it makes sense, I'll change the PR.