Cannot separate SObject metadata (fields, validationRules) into modules inside single package (sometimes)

[packocz]

Summary

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 (alphabetically), then all is well. If it is not though, then the below error appears during deployment. And the reason seems to be that the main object metadata is then "lost"
"Must specify a non-empty label for the CustomObject"

When using force source convert instead of deploy resuts show that generated CustomObject__c.object is missing the object level attributes when CustomObject__c.object-meta.xml was not placed in the alphabetically first module/folder. All fields or validation rules are present regardless of their placement. On the other hand when CustomObject__c.object-meta.xml is in the first one, all fields and validation rules as well as object level attributes are there and all is well.

More detailed description in this Stack Exchange question if needed

It seems somewhat similar to this existing issue. Though it's about the same xml file existing twice, while this is separate sub-parts of the object metadata coming from different folders (no duplication)

Steps To Reproduce

Reproduce issue [here](https://github.com/packocz/SObjectSeparation. Single package defined in sfdx-project.json)
3 different sub-modules inside this package. Each contains the same objects/CustomObject__c/ folder, one meant to define the object, 2 feature sub-modules add fields/validationRules. This only works if CustomObject__c.object-meta.xml is in the alphabetically first folder.

1. Clone Repository above
2. Create scratch org (or any pre-athorised org is fine)
3. Deploy full force-app pacakge into any (empty) org using sfdx force source deploy --sourcepath force-app --target-org XXXXX --checkonly >> produces error
4. Move CustomObject__c.object-meta.xml from force-app/main/default/objects/CustomObject__c/ into force-app/aa-package/objects/CustomObject__c/
5. Deploy full force-app pacakge into any (empty) org using sfdx force source deploy --sourcepath force-app --target-org XXXXX --checkonly >> works fine

Expected result

Package deploys with all expected custom Fields and Validation Rules

Actual result

Deploy fails with missing attributes that are actually defined in the source

System Information

zhs terminal
Mac OS 13.4

{
  "cliVersion": "sfdx-cli/7.205.6",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Darwin 22.5.0",
  "shell": "zsh",
  "rootPath": "/Users/ales.remta/.local/share/sfdx/client/7.205.6-dfc6717",
  "pluginVersions": [
    "@dxatscale/sfpowerscripts 21.1.0 (user)",
    "@oclif/plugin-autocomplete 2.3.0 (core)",
    "@oclif/plugin-commands 2.2.15 (core)",
    "@oclif/plugin-help 5.2.9 (core)",
    "@oclif/plugin-not-found 2.3.24 (core)",
    "@oclif/plugin-plugins 3.1.2 (core)",
    "@oclif/plugin-search 0.0.17 (core)",
    "@oclif/plugin-update 3.1.17 (core)",
    "@oclif/plugin-version 1.3.4 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.37 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "@salesforce/lwc-dev-server 2.11.0 (user)",
    "apex 2.3.3 (core)",
    "auth 2.8.1 (core)",
    "community 2.3.1 (core)",
    "custom-metadata 2.1.25 (core)",
    "data 2.3.22 (core)",
    "deploy-retrieve 1.11.7 (core)",
    "info 2.6.19 (core)",
    "limits 2.3.18 (core)",
    "org 2.9.8 (core)",
    "packaging 1.19.0 (core)",
    "schema 2.3.12 (core)",
    "settings 1.4.11 (core)",
    "signups 1.4.21 (core)",
    "source 2.10.14 (core)",
    "telemetry 2.2.0 (core)",
    "templates 55.4.20 (core)",
    "trust 2.4.20 (core)",
    "user 2.3.17 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.2 (user)",
    "@salesforce/sfdx-scanner 3.13.0 (user)",
    "sfdx-cli 7.205.6 (core)",
    "sfdx-git-delta 5.22.0 (user)",
    "texei-sfdx-plugin 1.17.3 (user)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[github-actions]

Hello @packocz 👋 None of the versions of sfdx you shared match the latest release.

Shared: 7.204.6
Latest: 7.205.6

Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue.
You can also try the rc and nightly releases! (docs)

After updating, share the full output of sfdx version --verbose --json

[packocz]

Updated to latest version, same problem persists. (updated original post with new json version output)

[git2gus]

This issue has been linked to a new work item: W-13629588

[mshanemc]

Can you populate the repro repo? It's empty https://github.com/packocz/SObjectSeparation

[packocz]

@mshanemc sorry, published now

[mshanemc]

@packocz I'm very confused on the repro steps. Now that we have the repo, it has 4 mdapi-format directories . What command are you running to deploy those together?

Or has your repo changed since the repro steps were written?

[packocz]

@mshanemc
the mdapi folder contains result of sfdx force source convert --sourcepath force-app when one of the Validation Rules OR the .object-meta.xml file being present in different sub folders of force-app
This is meant to demonstrate that the resulting .object is different depending on where the .object-meta.xml is

The deployment I tested with just sfdx force source deploy --sourcepath force-app
I've updated the step to be a bit clearer

[mshanemc]

This could be a dangerous/challenging fix. On the list

[ahoveynow]

Adding my two cents that this is something impacting us as well.
Our use case is where a git submodule is used for a utility code that contains an object definition (with fields).
The parent repo adds additional fields, but if the name of the submodule folder is after the main folder alphabetically, the source generation does not include the object-meta.xml metadata.
Discovering that we can change the name is helpful, but means that we need to name things specifically for that purpose rather than in a more natural way. Underscore also is not evaluated before A, so we have to do something like "a_MY_SUBMODULE" instead of "_MY_SUBMODULE". It also means we need to try to communicate this quirk to everyone that wants to utilize the submodule.