More granular metadata instead of complex XMLs #5480
Replies: 3 comments
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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?) |
Beta Was this translation helpful? Give feedback.
-
|
I was just watching a TDX24 recording and noticed that this is being already worked on with the introduction of the metadata registry customization forcedotcom/cli#2376 |
Beta Was this translation helpful? Give feedback.
-
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)
Parts of a whole (each part needs to be merged to a single concept)
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.
Beta Was this translation helpful? Give feedback.
All reactions