Can Unlocked Packages only modularize a single project / repo / org?

Question

The longer I read and watch everything related to Org modularization using Salesforce DX Unlocked packages there more I get the feeling that this is only about local dependencies meaning:

• You take the code of ONE org
• Convert it to ONE dx project
• Version it in ONE repository
• Define the dependencies in ONE project.json

What if I want to

• Take the code of MULTIPLE orgs (and consolidate it)
• Convert it into MULTIPLE DX projects
• Version those in MULTIPLE independent repos (with different) teams
• Define the dependencies wherever they occur

Would this work? Would they all need to "live under" the same Dev Hub? Is this the reason why this cannot be used for ISVs as it doesn't scale? Will this all be solved with 2GP (second generation packaging)?

If so what are the consequences when modularizing a happy soup org?

1. Should I create one super repository per org where each package is just a folder?
2. How do I allow independent teams to work on a single package?
3. Where do I define the different scratch orgs needed per package?
4. ...

Answer 1

You can definitely take a single org and split it to multiple packages and multiple repos (one repo per package) and define the dependencies wherever they occur.

Would they all need to "live under" the same Dev Hub?

• Technically, they do not have to.
• There are some advantages in keeping them under the same DevHub. Most notably is that it leaves the option open to design custom CLI tools to help with "leveling up" of dependency versions at the end of the test cycle and prior to production release.

Is this the reason why this cannot be used for ISVs as it doesn't scale?

• Not really. ISVs can't use second generation packages (2GP) at the moment, because Salesforce still needs to do more work to link 2GPs to the ISV LMA and other ISV-specific concerns.

Will this all be solved with 2GP (second generation packaging)?

• I suppose so.

Should I create one super repository per org where each package is just a folder?

• I would not recommend this.
• I find it easier to manage "one repo per package".
• It is also easier to manage the sfdx-project.json which specifies which packageDirectory is the "default" (...used in the billed of the package version).

How do I allow independent teams to work on a single package?

• This is controlled by feature branches in the source control.
• It is no different than it would be on another technology stack.

Where do I define the different scratch orgs needed per package?

• If you have "one package per repo" model, then you configure the different scratch org definition files under the "/config" directory -- make sure that each file ends with "*project-scratch-def.json". This is important so that VS Code will find all of the files available and make them available from the command palette "Create Scratch Org" command.

Hope this helps.