Sfdx-git-delta: Retrieve Metadata list from Org instead of hardcoded list

[wimvelzeboer]

I like what do did with this plugin!
A while ago I developed something similar for my company, but I think this plugin has more features.
One feature that I am missing though is that this plugin is depended on a hardcoded list of metadata.
In my plugin I have the option to connect to the target environment and retrieve the available metadata objects:

With something like:

interface MetadataObject {
    childXmlNames: string[];
    directoryName: string;
    inFolder: boolean;
    metaFile: boolean;
    suffix: string;
    xmlName: string;
}

const conn = <Connection>this.org.getConnection();
let metadataDescribe: MetadataObject[] = [];
await conn.metadata.describe(conn.version, function (err, metadata) {
      metadataDescribe = metadata.metadataObjects;
});

Do you think this is something that can be added to your plugin?

[scolladon]

Hi @wimvelzeboer

Thanks for your interest on the plugin and thanks for this very relevant suggestion.

This is something we considered at the early stage of the project.
Let me explain why we chose not to follow this path :

• At the beginning the command was not a plugin. It has been ported to the sfdx plugin architecture in v4.0.0. Before that, if we wanted to have a connection we needed to ask the consumers credential to do so. This would have complexify the integration of the command with other environment (CI/CD, local, etc) and we would have to manage every authentication use cases to deal with it.
• Now the command is a plugin it is a little bit easier because, as you said, we now have a connection 🎊 ! The only drawback here is that it would force the command to have a connection... It means you cannot use the command directly from sources without taking care of the shape (all the specific enabled metadata of the target org) where it has been developed. And that can lead to wrong output. The current version of the metadata description is not org specific, it is the broadest metadata description we could/had to do.
• Last but not least, we had to tweak a little bit the structure of some of the MetadataObject to have a structure which enable us to do the generic magic stuff the command does. You can have a look to the last metadata elements in the API files to have an idea. Per exemple all in file Metadata Element (CustomLabels, Workflows children, SharingRule children) or Wave Metadata Element have a different structure and the metadata.describe does not allow us to generically treat them the way the actual files used by the command are structured today. Doing so would imply developing a metadata.describe definitions decorator to transform it in the right shape and would probably involve a little refactoring in some part of the application (Wave and InFile element).

Now that it is said 😅 I hope it is a little bit clearer. I think added this could be done, involving changes in the design and refactoring. I would be very happy to do this kind of design and development in collaboration with anyone (@wimvelzeboer you're welcome 😉 ) following our contribution guidelines, if this requirement get tractions from the community and its drawbacks are accepted/mitigated.

Please, if anyone want the plugin to have this behaviour, let us know your thoughts here and how you would like the feature to be shaped !