fix: offer suggestions for unresolved metadata types

[iowillhoit]

What does this PR do?

In the past, a misspelled metadata file would fall back to EmailServicesFunction because that is the default for the .xml suffix. This change will prevent that incorrect resolved type and also offer suggestions to try similar metadata types.

Step 1 - Validation

• Create and bootstrap Dreamhouse
• Run sfdx project generate manifest --source-dir force-app
  • Note that the package.xml has the following Layout entry

<types>
    <members>Broker__c-Broker Layout</members>
    <members>Property__c-Property Layout</members>
    <name>Layout</name>
</types>

Step 2 - Reproduce bug

• Rename the Property layout to have a capital L on .Layout-meta.xml
  • Run mv force-app/main/default/layouts/Property__c-Property\ Layout.layout-meta.xml force-app/main/default/layouts/Property__c-Property\ Layout.Layout-meta.xml
• Run sfdx project generate manifest --source-dir force-app
• Note that the generated manifest
  • Completes "successfully"
  • The Label type no longer contains Property__c-Property\ Layout
  • There is an incorrect entry for EmailServicesFunction

<types>
    <members>Property__c-Property Layout</members>
    <name>EmailServicesFunction</name>
</types>

• This is because this lookup is using the .xml filename suffix which was claimed by EmailServicesFunction here

Step 3 - Testing Changes

• Pull this branch
• Run yarn link
• cd to plugin-deploy-retrieve
• Run yarn link @salesforce/source-deploy-retrieve
• Run sfdx plugins link
• Run sfdx plugins to confirm plugin is linked
• Run sfdx project generate manifest --source-dir force-app
• Confirm that you see a message like:

• Note that this is not specific to case. You can misspell a metadata type and it will try to find the closest match.
  • Try renaming the layout to lyout-meta.xml

What issues does this PR fix or reference?

@W-12731813@
also fixes @W-12484289@

[mshanemc]

QA:

using SDR linked into PDR
✅ got the following suggestions, along with the expected header/footer

-- Did you mean ".ai-meta.xml" instead for the "AIApplication" metadata type?
-- Did you mean ".apt-meta.xml" instead for the "ActionPlanTemplate" metadata type?
-- Did you mean ".scf-meta.xml" instead for the "Scontrol" metadata type?
-- Did you mean ".app-meta.xml" instead for the "CustomApplication" metadata type?
-- Did you mean ".eca-meta.xml" instead for the "ExternalClientApplication" metadata type?
-- Did you mean ".aq-meta.xml" instead for the "AssessmentQuestion" metadata type?
-- Did you mean ".aqs-meta.xml" instead for the "AssessmentQuestionSet" metadata type?

fileUtilities.cls => fileUtilities.CLS
✅ 🤷🏻 seems to convert just fine!

fileUtilities.cls-meta.xml => fileUtilities.cLS-meta.xml
✅ 🏆 great suggestion: -- Did you mean ".cls-meta.xml" instead for the "ApexClass" metadata type?

fileUtilities.cls-meta.xml => fileUtilities.cLS-meta.xmz
✅ 🏆 great suggestion: -- Did you mean ".cls-meta.xml" instead for the "ApexClass" metadata type?

prompts/Property.prompt-meta.xml => property.xml
👎🏻 doesn't convert, silents omits it from the output. I think this is being treated as "oh, then it's probably a package.xml." I'm not sure what can be done about it, though, without opening the file and peeking inside. Open to suggestions!

prompts/Property.prom-meta.xml => property.xml
✅ A search for the ".prom-meta.xml" metadata suffix found the following close matches:
-- Did you mean ".prompt-meta.xml" instead for the "Prompt" metadata type?

putting a bad extension on a listView (child of custom object)
Error (1): Unexpected child metadata [/Users/shane.mclaughlin/eng/plugin-deploy-retrieve/testProj/force-app/main/default/objects/Broker__c/listViews/All.lstvu-meta.xml] found for parent type [CustomObject]
➕ I'm still happy we have good error messages from all that strict-mode work. I think this is potentially another place we could provide suggestions into this "Unexpected child metadata" error. Doesn't have to be now.

---

all of these are not changed ⬇️
🤷🏻 "converts" it by keeping the same error. Not in the scope of this PR, they'll get an error at deploy time. It's ok.

• /staticresources/sample_data_brokers.resource-meta.xml => sample_data_brokers.xml
• /staticresources/sample_data_brokers.resource-meta.xml => sample_data_brokers.resources-meta.xml
• auraPropertyListMap.cmp-meta.xml => auraPropertyListMap.comp-meta.xml
• fileUtilities.cls-meta.xml => fileUtilities.cLS-meta.

[mshanemc]

additional QA against @W-12484289@ 🏆

Error (1): /Users/shane.mclaughlin/Downloads/dipb-sfdc-portal-banker/force-app/main/default/classes/redacted__c.field-meta.xml: Could not infer a metadata type

Try this:

A search for the ".field-meta.xml" metadata suffix found the following close matches:
-- Did you mean ".view-meta.xml" instead for the "ViewDefinition" metadata type?

Additional suggestions:
Confirm the file name, extension, and directory names are correct. Validate against the registry at:
https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/metadataRegistry.json

[iowillhoit]

@mshanemc I was not able to figure out how to get readFileSync working with with the ZipTreeContainer. However, I think what I've added here will detect manifests most of the time. Also related to this QA feedback

prompts/Property.prompt-meta.xml => property.xml
👎🏻 doesn't convert, silents omits it from the output. I think this is being treated as "oh, then it's probably a package.xml." I'm not sure what can be done about it, though, without opening the file and peeking inside. Open to suggestions!

This is how this currently works prior to these changes. Unlink plugin-delpoy-retrieve and run this test ^ A property.xml file is silently ignored. At least now we get a warning about it

[mshanemc]

QA round 2

Dreamhouse.app-meta.xml =>Dreamhouse.ap-meta.xml
✅ suggestions are good

Dreamhouse.app-meta.xml =>Dreamhouse.app.xml
Dreamhouse.app-meta.xml =>Dreamhouse.app-mexa.xml
Dreamhouse.app-meta.xml =>Dreamhouse.xml
❓ all produce

Try this:

A search for the ".xml" filename suffix found the following close matches:
-- Did you mean ".xml" instead for the "EmailServicesFunction" metadata type?

FileUtilities.cls-meta.xml => FileUtilities.clx-meta.xml
FileUtilities.cls-meta.xml => FileUtilities.clS-meta.xml
✅ suggestions are good