Renovate: Refactor: simplify manager addition

[rarkins]

I would like for there to be less files "touched" when adding new managers, because new managers are most commonly added by first-time contributors.

Let's use https://github.com/renovatebot/renovate/pull/5257/files as an example as it was manager-only (no new datasource):

• [x] Skip the requirement for configuration-options.md content. Instead a manager can optionally have a readme.md within its directory that is dynamically inserted into the docs instead. We'll need to update our linting rule at the same time.
• [x] Move config definitions inside the manager exports (#5279)
• [x] export const MANAGER_HELMFILE = 'helmfile'; - These consts could be in each manager's directory, or left out altogether (#5278)
• [x] lib/manager/index: Maybe manager should "autodiscover"/autoimport managers at runtime. (#5278)
• [x] renovate-schema.json: Little hard to avoid updating this one. Possibilities:
  
  
  
  • It could be generated and pushed to a static location instead of committed with the repo
  
  
  • Create a GitHub Action that commits it if changed after PRs are merged. The problem is that then we lose the ability to "preview" it with PRs
  
  
• [x] Remove the validation snapshot
• [x] Remove the snapshot from test/workers/repository/extract/__snapshots__/index.spec.ts.snap

[rarkins]

@ViceIce @zharinov @JamieMagee you have all had a lot of experienced with adding managers - what do you think?

[viceice]

I like the idea. What if the manager / datasource exports all required info to generate the config options too? So a contributor has to simply run a update generated files command.

We can also use json files where we put config options and renovate loads them on startup to register found managers.

[rarkins]

Ideally all required information would be within lib/manager/x (and maybe also test/manager/x). So yes perhaps this also includes its default config.

I took a look at how MANAGER_HELMFILE is used too:

• It's added to constants
• lib/manager/index imports it
• lib/manager/index adds it to a list of allowed managers
• lib/manager/index uses that list for semi-dynamic imports
• a few other functions query lib/manager/index to get the list of allowed managers

I think this can maybe all be replaced with a dynamic fs-based list generation and import. It wouldn't even be necessary to export MANAGER_HELMFILE from lib/manager/helmfile/index.ts

[rarkins]

Created #5278 for dynamic manager discovery

[rarkins]

I used to dislike the idea of tests being colocated with code, which is why we today have the lib/test split. But maybe now it makes more sense to add unit tests within lib/manager/x instead of test/manager/x? @ViceIce what do you think?

[viceice]

It would make all imports more easy too. we only have to exclude test files for production build, which should be doable.

[rarkins]

Added #5279 for managers exporting their own default config and #5280 for moving test/manager files to within lib/manager

[zharinov]

What about developer guide/wiki?

[rarkins]

Good idea, once we’re done

[fgreinacher]

I like this direction a lot - these changes will most probably also make #4674 much easier to implement 😃

[rarkins]

This work is now complete. Note: similar approach has been taken for datasource too.