More granular metadata instead of complex XMLs

[jonathanwiesel]

Is your feature request related to a problem? Please describe.

Direct management of the source metadata is raising exponentially due to the increase of adoption in version control in the Salesforce ecosystem, this implies that conflict resolution needs to be done at source level, therefore resolving conflicts in Git.

Some metadata files are, in my opinion, too big and complex to be managed in a single file in order for its changes to be tracked and reviewed in a manageable manner, especially when many changes are involved, not to mention conflict resolution.

Describe the solution you'd like

My proposal would be that complex source files are separated in more granular sub files that can be managed more easily, similar to how it has been done with the SObject file that has been worked to, for example, be more granular to have each field in a separate file.

This could apply (but not limit) to the following metadata:

Independant (each part can be deployed, changes and deleted by itself, such as the custom fields)

• Custom Labels
• Workflows (rules, tasks, alerts)

Parts of a whole (each part needs to be merged to a single concept)

• Profiles ⚠️
• Permission Sets ⚠️
• Flows
• Layouts and Flexipages
• Approval Processes

⚠️ I'm aware that for profiles and permission sets would be tricky taking into account how permission files currently work, meaning that if a permission is not part of the file it simply does not get overwritten but is not actually deleted.

Describe alternatives you've considered

There are some plugins developed by the community such as the sfdx-profiles-splitter and sfdx-metadata-splitter which represent the idea quite well, although applying these involves manual splitting and merging when retrieving and deploying respectively, I would like it to be part of the standard, or at least have the option to do it.

[catalandres]

The best way to allow for an arbitrary degree of granularity would be to ensure that the CLI has pre- and post-deployment hooks that allow for transformations to and from, respectively, the canonical SFDX project format.

Let's say that you would like to keep your project in Salto's NaCl format, or you really want it to be in YAML, or that you want to blast the XML into smithereens and turn your project into a benighted delusion of folders within folders within folders... you name it — you just need to write an adaptor to go from your format to XML and from XML to your format. When you want to deploy, the CLI calls your adaptor, gets the XML and it does what it needs to. When you want to retrieve, if needed, it gets the equivalent XML for what is in your local folder, compares it to what comes from the org, retrieves the XML and transforms it to your format.

Well... good news. This exists. It's a CLI feature (not part of the VSCode extension). And it broke recently.

[jonathanwiesel]

@catalandres What you mention is indeed a very interesting approach to achieve what is being proposed. Even so, my request still stands for it to be the standard at least for some metadata (if Salesforce already started with SObjects, why stop there?)