Rename regexManagers to customManagers

[rarkins]

Describe the proposed change(s).

• rename regexManagers to customManagers
• add a new field customType which defaults to regex
• add migration code

[rarkins]

Nest the existing regexManagers code under a regex/ subdirectory too and wrap them so that we're ready for new customTypes

[RahulGautamSingh]

1. Should we also rename manager from regex to custom and have regex as customType only?

2. How should we handle the logic to selet the which extract fn to use among custom managers when
   we have something like this in future:

   • module/managers
     • custom
       • regex
       • jsonata

   a) Add index.ts and api.ts files in custom folder and replicate the logic which is used for managers.

   OR

   b) When manager is regex use customType to select the correct manager api to use.
   like this:

   Currrent:
   

   renovate/lib/modules/manager/index.ts

   Lines 68 to 72 in 2ebe8b1

   	const m = managers.get(manager)!;
   	return m.extractPackageFile
   	? m.extractPackageFile(content, fileName, config)
   	: null;
   	}

   New:

	 	let m: ManagerApi;
  		if (manager === 'regex') {
    	m = managers.get(config.customType ?? 'regex')!;
 		 } else {
   		 m = managers.get(manager)!;
 		 }

[rarkins]

1. Yes
2. Wrap/duplicate the functions a little

[RahulGautamSingh]

After shifting from regex to custom, how should we handle the enabledManagers option when we need to enabled regex or jsonaata in future?

1. enabledManagers: [regex, jsonaata]
2. enabledManagers: [custom]

I prefer 1) as it gives more control to user.

[viceice]

use 2.

[reitzig]

Will there be any API and/or implementation changes? (Sorry if the answer is obvious, didn't check the PR.)

FWIW, I was prompted to share thoughts on how regexManagers could be made easier to debug: renovatebot/renovate#20881

enabledManagers: [regex, jsonaata]

Are there plans to include one for XML? I felt rather dirty regexing into a Maven pom.xml.

[RahulGautamSingh]

We might need to migrate matchManagers as well.
I prefer to keep it regex because if we fo with custom then, incase we have multiple custom managers all will be matched.
ie. no way to select only jsonata or regex.

[rarkins]

Support both then. custom will match any manager while regex matches only Regex, jsonata only jsonata, etc

[RahulGautamSingh]

Support both then. custom will match any manager while regex matches only Regex, jsonata only jsonata, etc

After discussions in #23357 (comment), we have decided to support the custom* syntax,
Example:

matchManagers = ['custom.regex', 'custom.jsonata']  // custom managers separately
enabledManagers= ['custom.*'] // all custom managers

[RahulGautamSingh]

Doables in order:

• move regex manager in custom/regex refactor(managers): move regex in custom folder #23715
• add custom manager api refactor(managers): implement custom managers api #23357
• add customType field to regexManagers config feat(managers/custom): introduce customType field #23919
• rename regexManagers to customManagers feat(migrate): regexManagers -> customManagers #24451

Enhancement not directly related to the implementation

• implement custom.* syntax for enabledManagers and matchManagers
  1. feat: implement custom.<customMgrName> syntax for matchManagers #24112
  2. refactor(enabled-managers): implement custom.<customMgrName> syntax #24079

[RahulGautamSingh]

We will need separate interfaces for CustomManager , RegexManager ...
CustomManager : will contain the common fields that are expected in all custom managers eg. customType, fileMatch, and RegexManager : will contain the fields which are unique to it like matchStrings , matchStringsStrategy & its templates

Similarly we will need to handle validation based on customType as well , after validating the customType and fileMatch fields.
For eg.

 if (key === 'regexManagers') {
 ...
                } else if (is.nonEmptyString(regexManager.customType)) {
                  if (is.nonEmptyArray(regexManager.fileMatch)) {
                    // TODO: Add validation as per customType, preferrably a separate file or function for readability
                    switch (regexManager.customType) {
                      case 'regex':
                        errors.push(
                          ...(validateRegexManagerFields(
                            regexManager,
                            currentPath
                          ) as any)
                        );
                        break;
                    }
                  } else {
                    errors.push({
                      topic: 'Configuration Error',
                      message: `Each Regex Manager must contain a non-empty fileMatch array`,
                    });
                  }
                } else {
                  errors.push({
                    topic: 'Configuration Error',
                    message: `Each Regex Manager must contain a non-empty customType string`,
                  });
                }
              }
            }
... 

Hence, when a new custom manager is added, we will need:

1. a new interface and
2. a new validation function to validate its fields and return errors

[RahulGautamSingh]

Should we rename RegexManagerPresets to CustomManagerPresets ? It makes sense, since in future we might include presets of other custom managers to the same list.

[RahulGautamSingh]

Doables in order:

• move regex manager in custom/regex refactor(managers): move regex in custom folder #23715
• add custom manager api refactor(managers): implement custom managers api #23357
• add customType field to regexManagers config feat(managers/custom): introduce customType field #23919
• rename regexManagers to customManagers feat(migrate): regexManagers -> customManagers #24451

Enhancement not directly related to the implementation

• implement custom.* syntax for enabledManagers and matchManagers
  1. feat: implement custom.<customMgrName> syntax for matchManagers #24112
  2. feat: custom.<customMgrName> syntax for enabledManagers #24079

We can close this issue now, and transfer the enhancements ie. implementing custom.* syntax for enabledManagers and matchManagers to #21760

[TWiStErRob]

Note: this is not mentioned in https://docs.renovatebot.com/release-notes-for-major-versions/ for v37

[rarkins]

@TWiStErRob any thing with migrations is not treated as a breaking change

[TWiStErRob]

@rarkins I see it's not breaking, but could still worth a mention in commentary as it's a concept change?

[rarkins]

We document changes in whatever release they fall in

[TWiStErRob]

The last PR that was the actual rename (#24451) was landed in 36.107.0, does that not make it part of major v37?

[rarkins]

Yes, just like the 106 features released before it in v36. We can't mention them all in v37