fix: resolve strictDirectoryName types in mdapi format #601
Conversation
| @@ -142,6 +142,46 @@ describe('MetadataResolver', () => { | |||
| expect(access.getComponentsFromPath(path)).to.deep.equal([matchingContentFile.COMPONENT]); | |||
| }); | |||
|
|
|||
| it('Should determine type for metadata file with known suffix and strictDirectoryName', () => { | |||
There was a problem hiding this comment.
I made sure the test failed without the fix.
| // the suffix matches the type we think it is | ||
| (type.suffix && fsPath.endsWith(`${type.suffix}${META_XML_SUFFIX}`)) || | ||
| // the file suffix (in source or mdapi format) matches the type suffix we think it is | ||
| (type.suffix && [type.suffix, `${type.suffix}${META_XML_SUFFIX}`].some((s) => fsPath.endsWith(s))) || |
There was a problem hiding this comment.
that exception is that little punk emailServicesFunction for whom .xml is the suffix.
now that we're testing with a real registry, can you make sure that it's handled correctly?
There was a problem hiding this comment.
I tested manually and added a unit test for it. The fix doesn't affect it since the matching wouldn't get that far with the EmailServicesFunction type; it's not defined as "strictDirectoryName": true
There was a problem hiding this comment.
FYI, I was wanting it in a strictDir. ESF has a habit of matching way too promiscuously and I'm trying to keep that from happening.
So...what would happen if it were in strictDir?
There was a problem hiding this comment.
Testing would help us out, but I think it would still work just fine because it would only get to the suffix matching if the path contained the expected directory.
There was a problem hiding this comment.
After testing, ESF still retrieves and deploys successfully when defined as a strictDirectoryName.
|
QA notes: |
|
Thanks for the fix. My project is impacted by it. When will it be made available to customers? |
|
Hi @ifeanyikyra this will be available in the |
|
Thanks @WillieRuemmele .... Would running "sfdx update" get me the latest-rc on 4/7? Otherwise, is there a link that explains it |
|
the release notes explain how to get the RC version |
What does this PR do?
Fixes
MetadataResolverto match a file path in source format and mdapi format when testing types with strictDirectoryNames that also do not have an adapter strategy defined (those types are resolved properly another way).This should fix the following types:
What issues does this PR fix or reference?
forcedotcom/cli#1448
@W-10910004@
Functionality Before
Would not resolve files in mdapi format with certain strictDirectoryName types such as CustomSite. This would cause (e.g.) a retrieval of these types to fail to be written to the file system.
Functionality After
Files resolve properly. Metadata retrieval of these files are successful.