The answer is yes, absolutely.
Unfortunately the Scratch Org creation mechanism isn't yet smart enough to deal with this for you and Salesforce suggested writing scripting to deal with installing the dependency packages. This is covered here.
We did it somewhat differently. We "extended" the sfdx-project.json (in a completely compatible manner) to add the installation keys for the dependency packages, which themselves must already be listed as dependencies anyway. So we have something like:
{
"namespace": "namespace",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "50.0",
"packageDirectories": [
{
"path": "force-app",
"default": true,
"package": "My Package",
"versionNumber": "1.0.1.NEXT",
"versionDescription": "Something about My Package",
"ancestorId": "My [email protected]",
"definitionFile": "config/some-scratch-def.json",
"postInstallScript": "namespace.SomeInstaller",
"dependencies": [
{
"package": "Other [email protected]"
},
{
"package": "Another [email protected]"
}
]
},
{
"path": "force-unpackaged"
}
],
"packageAliases": {
"Other [email protected]": "04t0N00000XXXXX",
"Other [email protected]:key": "Some Password",
"Another [email protected]": "04t4P00000XXXXXXXX",
"Another [email protected]:key": "Some Other Password",
"My Package": "0Ho3Z000000XXXXXXX",
"My [email protected]": "04t3Z00000XXXXXXXX"
}
}
Note that the packageAliases contains extra entries with the "key" (the installation key/password) for the dependency packages. In our case we depended on another of our own packages ("Other Package") and a third party one ("Another Package") in order to integrate the two.
We had to negotiate with the third party and persuaded them to provide us access to a beta of their package. That way we could do the install on scratch orgs, but we could not make use of their package on production orgs.
We wrote scripting (actually Ant but it could have been anything else) executed when creating the Scratch Org before anything is pushed that found the dependencies using the sfdx-project.json content and did the installation using the sfdx CLI.
In this case it actually takes about an hour to create the scratch org, because the installations take so long (both are big 1GPs that we must install before doing anything with the 2GP extension package). As such we tended to keep these scratch orgs longer than normal and would use them for multiple development tasks - normally we create a scratch org per development task, since it takes about 10 minutes (both creation and initial package metadata push) but that's not feasible here with the lengthy delay for these installs.
As always, the scratch def JSON file needs to be appropriate to ensure the features required by the third-party package(es) are enabled.
Note, too, that there is a (safe harbour) future Salesforce feature called "Scratch Org Snapshots" (search for "snapshot") that may help here - you create a snapshot from an org with the two packages already installed and the scratch org creation using that snapshot is then faster, but it is not currently top priority in the managed package team at Salesforce sadly.
