SFDX: Having multiple project config files (one per dev hub) and switching between them dynamically when creating package version

Question

We would like to switch between different dev hubs in our sfdx 2gp project. E.g. we have one dev hub representing our BPO org (for major releases) and couple free registered dev hubs to play around with and create adhoc package versions without validation for testing purposes etc.

Since every dev hub is linked with different namespace (i.e. packaging org), has different package id created there etc, we would like to have separate sfdx-project.json per each dev hub to keep there all these hub-specific configs like namespace, package id, ancestor id, package version etc (while still part of the file describing project structure in terms of packaging folders would be the same in each project file, i.e. duplicated).

The question here: is there any way to change the name of default project config file in runtime from sfdx-project.json to e.g. sfdx-project.json.testDevHub, maybe by setting some env variable or via sfdx config set key command?

Looking through docs we haven't found a way to do that so far - the only option is just to rewrite sfdx-project.json file content in runtime, and then restore it back. Is there any better way to achive this? Any help would be appreciated.

Answer 1

No, sfdx-project.json is a hard-coded file name. Your project must use that file. I'm not sure if you're aware, but you can have hundreds of "non-validated" packages per day in a single Dev Hub, so it's unlikely that you need to do such a complicated configuration; just specify the dev hub you want to use when you create a package version.

That said, if you do want to have multiple projects, you can create multiple repositories using git, and then have your source code listed as a common git-submodule. In this way, force-app (or whatever you want to call it) is a common set of metadata, and you would then have two other git repositories, three total (one for each project, plus one for the shared submodule), and simply switch your workspace between the two projects as you see fit.