force:org:create doesn't use namespace from sfdx-project.json (or perhaps that entire file) sometimes (metadata format vs. source format?)

I’ve been working through some IC2 issues with the NPSP project lately, many due to the fact that it’s a strange hybrid of SFDX and traditional. It has an sfdx-project.json file and numerous scratch org definition files under its orgs directory, but the actual files are (mostly) in metadata format instead of source format. I say “mostly” because the documents seem to follow the source format conventions rather than metadata format conventions. Otherwise all XML metadata filenames use their metadata type-specific file extensions instead of that plus -meta.xml, and there’s no metadata decomposition.

So that’s the setup. The actual issue I’m reporting here is that if I specify a namespace in the sfdx-project.json file that is properly associated with the dev hub against which I’m creating a scratch org, then run sfdx force:org:create from the NPSP project directory, the scratch org is not created with that (or any) namespace. In fact, if I specify an invalid namespace in sfdx-project.json there are no errors, so it seems it’s either not consulting that file or it’s deciding not to use the namespace from that file for some reason.

On the other hand, if I create a dummy SFDX project using sfdx force:project:create such that its sfdx-project.json file contains the same namespace and create the scratch org from that project directory, the scratch org is created with the specified namespace.

How does the sfdx force:org:create command decide whether/how to use the information in sfdx-project.json? Does it also look at the contents of the specified package directories? This disparity in behavior is confusing and seemingly incorrect when the org is created without a namespace.

[davidmreed]

Background on the unusual project layout for the Nonprofit Success Pack:

NPSP is built using CumulusCI, Salesforce.org’s orchestration layer on top of Salesforce DX. The NPSP project is in Metadata API format. However, it also comes with all of the infrastructure to define and build scratch orgs, because CumulusCI supports building scratch orgs for products in both Metadata API and Salesforce DX source formats.

CumulusCI is the recommended route to build a scratch org for NPSP. Salesforce DX itself will not work without walking through a lot of manual steps, as NPSP includes six managed packages and unmanaged setup that must be deployed prior to pushing source into the org.

[SCWells72]

Okay, I’ve figured out the part where the namespace wasn’t being set. Because of the hybrid nature of the NPSP project, IC2 wasn’t setting the working directory for the CLI when it executes, instead causing that process’ working directory to be the sfdx script’s parent directory. When IC2 properly sets the working directory to be the parent directory of sfdx-project.json when executed for the NPSP project, the namespace is set properly even when the plugins property is present in sfdx-project.json.

It’s still strange that the namespace is set properly when a scratch org is created from a non-project working directory if plugins is not present but isn’t set when plugins is present in that same scenario, but since that’s a weird use case, I’d say go ahead and resolve this case since the other problem with settings deployment via the REST API is being handled elsewhere.

Thanks!