feat(config): allow exporting async config

[pmorch]

module.exports can now be a function and it can be/return a Promise,
allowing the results of asynchronous operations to be used in the
configuration.

The discussion leading up to this PR in #13035 assumed that
module.exports had to be a plain object.

But this commit:

  commit 9aa97af5b346f82b48564c20c66783b51c3022d9
  Author: Nejc Habjan <hab.nejc@gmail.com>
  Date:   Thu Dec 9 13:45:48 2021 +0100

      feat(config)!: parse JSON5/YAML self-hosted admin config (#12644)

      Adds support for alternative admin config file formats.

      BREAKING CHANGE: Renovate will now fail if RENOVATE_CONFIG_FILE is specified without a file extension

Had as an undocumented side effect, that it also handled transparenty
if module.exports was assigned a Promise. With that commit, the
promise will be await-ed so the resolved value is returned from
getConfig(). That was not the case before that commit.

So in this commit, configs that export functions are handled, and
test cases for both promises and functions have been added.

Changes:

Context:

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

This would probably be good to document somewhere, but where? I'm happy to add some documentation, if somebody can point me to where the config file is described.

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

All committers have signed the CLA.

[rarkins]

Can we document it too?

[pmorch]

Can we document it too?

Sure. But as i wrote, I'd like a pointer as to where to at the documentation. I found the documentation a little confusing in this regard.

[rarkins]

Maybe a subheading under https://github.com/renovatebot/renovate/blob/main/docs/usage/getting-started/running.md#global-config would work best

[viceice]

Wrong import order. 😉

[pmorch]

Ok, I'll move the import up above the local imports. Are there other rules about import sequence that I should be aware about, or is this good?:

import { load } from 'js-yaml';
import is from 'is';
import JSON5 from 'json5';
import upath from 'upath';
import { migrateConfig } from '../../../../config/migration';
import type { AllConfig, RenovateConfig } from '../../../../config/types';
import { logger } from '../../../../logger';
import { readFile } from '../../../../util/fs';

[viceice]

Run yarn lint. It will tell you all issues, or check the ci status. 😉

[HonkingGoose]

I think we can probably put the whole comment on one line?

[pmorch]

Linter also reported a problem with kebab-case in file names. So I'll rename e.g. fileFunction.js to file-function.js and try again.

[pmorch]

I think I've now fixed the issues that have been discussed. A few things to note:

• I've created a separate commit documenting the changes that were introduced in 9aa97af referencing feat(config)!: parse JSON5/YAML self-hosted admin config #12644.
• If tried to use my best judgement in creating commit messages for the multiple commits that now exist for this issue. They all have #13035 in the subject line.
  • There were two commits I created from the github UI that didn't get "nice" commit messages. Sorry.
• I took the liberty of renaming lib/workers/global/config/parse/__fixtures__/file*.js to config*.js, because they really were config files.

If it were just me, I'd rebase and force-push a new commit to fix this issue, so that we get clean history and a single collective commit for this issue. Some are for and some are against force pushing in merge requests. There would then be one commit to document 9aa97af / #12644 and one commit for this issue. Are you for or against that?

Full disclosure: I was not able to run

yarn test

without modifications. I have 12 CPU cores and 16 GB RAM, and jest would try to run 12 parallel tests some of which use more than 3GB RAM each. Eventually my machine would reach load 100, would start swapping like crazy and pretty much die until I hit CTRL-C. I had to introduce --max-workers=4 to run yarn test like this:

diff --git a/package.json b/package.json
index 943619336..64483b8ce 100644
--- a/package.json
+++ b/package.json
@@ -22,7 +22,7 @@
     "generate": "run-s generate:*",
     "generate:imports": "node tools/generate-imports.mjs",
     "git-check": "node tools/check-git-version.mjs",
-    "jest": "cross-env LOG_LEVEL=fatal node --expose-gc node_modules/jest/bin/jest.js --logHeapUsage",
+    "jest": "cross-env LOG_LEVEL=fatal node --expose-gc node_modules/jest/bin/jest.js --logHeapUsage --max-workers=4",
     "jest-debug": "cross-env NODE_OPTIONS=--inspect-brk yarn jest --testTimeout=100000000",
     "jest-silent": "cross-env yarn jest --reporters jest-silent-reporter",
     "lint": "run-s ls-lint eslint prettier markdown-lint git-check doc-fence-check",

It now ran successfully including jest, linter and everything :-)

[viceice]

you can run yarn jest --max-workers=4 😉 On my maschin i like to use all my 16 cores

[viceice]

We will squash pr's, so we only have one commit on main 🤗

[pmorch]

you can run yarn jest --max-workers=4 😉 On my maschin i like to use all my 16 cores

Yes, this is exactly what I did... Which is also exactly why I forgot to run yarn lint :-)

and I can't run yarn test --max-workers=4 so I had to patch package.json.

[renovate-release]

🎉 This PR is included in version 31.0.0 🎉

The release is available on:

• GitHub release
• 31.0.0

Your semantic-release bot 📦🚀