How to use public sites with SFDX and Unlocked Packages

Question

I have some code which integrates with a third party service by exposing webhooks (REST Methods) via a public (non-authenticated) site. I'm trying to figure out how this should work as part of automated build testing, as well as an unlocked package.

To begin with, I have an SFDX project which includes the Apex Class containing the REST methods, and which contains a public site definition (sites/Webhook_Service.site-meta.xml). If I create a new scratch org and try to push the code, I get an error for the .site-meta.xml file:

The Force.com Site subdomain has not been set in the organization

If I open the org and view the Sites page in Setup (LEX Setup -> User Interface -> Sites and Domains -> Sites), I am prompted to create a subdomain before I can create a Site. Once I set a subdomain name, then force:org:push succeeds. This confirms to me that I need the "Site Subdomain" specified in the org before I can push the Site definition. As I understand it, this Site Subdomain cannot be set/created via Metadata API, and I have found no way to specify via SFDX either. Is that correct? Is there any way around this, for example, in order to do automated builds with SFDX?

It occurs to me that an unlocked package which contains a .site-meta.xml will not successfully deploy unless a user has already set the Site Subdomain prior to trying to install the package. In the case of an unlocked package (as opposed to an automated SFDX build), I suppose it makes sense to call the setting of the Site Subdomain a prerequisite for the use of the unlocked Package. Is this considered best practice, or would be better to require the user to create their own public site?

Answer 1

What's your unlocked package use-case? Are you using them to organise code within a large org? As a way of distributing code to many orgs? Something else?

As it stands, I would say that Sites are best left to the target org, not to be part of the unlocked package. Otherwise, things that you might legitimately want to change in production (e.g. the Site Contact) could get overwritten by installing the package.

I tend to do this by having the site as part of my sfdx project, but not in the package directory. That way, when I create a scratch org, I've got a site definition so I'm closer to being able to test it; but that definition never gets installed anywhere.

This does mean that, as you pointed out, I still have to create a subdomain in the scratch org, which is a bit annoying.

Addition

Reading David Reed's comment above, I experimented with the adding

"features": [
    "Sites"
  ]

To my scratch org definition. This does assign a domain when the scratch org is created. I'd missed this way back when I first made the package, and it's really useful!