I'm am having some problems in a sfdx project where I am trying to gradually modularise the "happy-soup" metadata. I found out what is happening, but not the 100% of why or how to solve it.

Having multiple classes folders, even with more sub-folders in each (e.g. selectors, services, ...) is absolutely fine. However, when trying to do the same with objects I ran into problems when deploying the whole project. Specifically this error: "Must specify a non-empty label for the CustomObject"

Essentially what I'm trying to do is to have the definition of the object and its "base" fields inside the main module. And then add more (feature) specific fields or validationRules into separate modules along with other metadata for the separate context.

I thought this was possible (as discussed in this related question). And it seemed so for a while as the error does not happen always. The important difference in my context is that I do not use packages yet, rather just folders inside 1 package. This answer to a similar question shows the same problem.

So it turns out that when there are multiple folders for the same object, it is important in which of them the object's object-meta.xml file is placed. If it is in the first one, then all is well. If it is not though, then the above error appears during deployment. And the reason seems to be that the main object metadata is then "lost".

I tried to compare the results of sfdx force source convert --sourcepath force-app in the various combinations:

  1. All in main/default
  2. 1 ValidationRule or Field in separate folder inside the same package

it turns out that the package.xml is always the same, but the .object xml file is missing the object level properties (e.g. <label>Custom Object</label>) when .objet-meta.xml was not in the alphabetically first folder. repo with example

So what to do here? Is it wrong to have "feature specific" fields in modules other than the first one? (base schema)?

  • There is no way to order folders by dependencies like you can do with (unlocked) packages
  • I can't yet use packages as I have important metadata with unresolved dependencies going up/down the planned package structure
  • it does not help to make the "module" or "package-to-be" folders be sub-folders of main (siblings of default). Same issue then

(the only thing I can think of is to prefix the folder names with "z_", but that seems daft)

  • This sounds more like a bug than a feature. Have you considered logging a bug with the cli team?
    – sfdcfox
    Commented Jun 19, 2023 at 13:42
  • Done that now @sfdcfox. Just needed a little sanity check first I've not missed an obvious reason or piece of docs. Thanks
    – alesremta
    Commented Jun 19, 2023 at 20:09
  • Link to CLI Issue on GitHub: github.com/forcedotcom/cli/issues/2230#issuecomment-1600733729
    – alesremta
    Commented Oct 4, 2023 at 13:40


You must log in to answer this question.

Browse other questions tagged .