Incorrectly Deletes Text Static Resources

[ralphcallaway]

Ran to sync up a production org which had 3 static resources

• application/zip static resource folder kept
• text/csv static resource folder removed
• test/plain static resource folder removed
• static resource meta files retained for all three

Running a retrieve brings them right back. Long shot, but maybe simple text static resources have a slightly different structure gumming things up.

[ralphcallaway]

Tan with log level trace, although not much different than the detaults, looks like the resources are being retrieved, but at some point they're marked to delete

=== Retrieved Source

FULL NAME                                                               TYPE                  PROJECT PATH

──────────────────────────────────────────────────────────────────────  ────────────────────  ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

missing1                                                                StaticResource        src/main/default/staticresources/missing1.csv
missing1                                                                StaticResource        src/main/default/staticresources/missing1.resource-meta.xml
missing2                                                                StaticResource        src/main/default/staticresources/missing2.resource-meta.xml
missing2                                                                StaticResource        src/main/default/staticresources/missing2.txt

... lots of stuff that got cleaned fine ...

removed /Users/ralphcallaway/Development/project/src/main/default/staticresources/missing2.txt
removed /Users/ralphcallaway/Development/project/src/main/default/staticresources/missing1.csv

[ChuckJonas]

Not sure why this would happen... Next time zip your project so I can reproduce plz

[ralphcallaway]

@ChuckJonas sent

[ChuckJonas]

thx... So interesting behavior. Check this out:

1. Make modifications to the file without deploying (outside of vscode)
2. Run sfdx force:source:retrieve --manifest ...

Result: Your local changes will not be overwritten

Basically it just seems like retrieve:source is broken for static resources. It doesn't update them, it only creates them if they don't exist.

forcedotcom/cli#190

[ralphcallaway]

ahh, and that broke the clean technique

organize your files into package directories they said, it'll all work, ... wtf

[ralphcallaway]

seems like there are options to accomodating, although they seem like a pain

• list static resources
• delete any that aren't returned by the list command
• mv the rest before doing the manifest refresh (and remember which folder they came from)
• do the retrieve
• put them back in their appropriate folders

[ralphcallaway]

fix approach

prep

• delete all non-meta files in package directories
• pipe "DELETE" into all meta files

retrieve

prune

• delete all empty directories
• delete all meta files whose content is DELETE

[ChuckJonas]

@ralphcallaway checkout the branch I just pushed (sry been sitting on this for a few days). I think it does everything except delete all empty directories.

You should have permission to push directly to this branch (no need to work off fork).

[ralphcallaway]

@ChuckJonas oh sweet, i'll give it a go and see if that works. We could probably skip deleting the empty directories unless it's causes some other issues.

[ralphcallaway]

@ChuckJonas sweet, text static resources are no longer getting deleted. would love to push a v0.0.6 if you're ready, or if you're hoping to do some more refinement we could do a 0.0.6-beta.1 so it's up on npm treats it as a pre-release and won't install without specifying the version

[ralphcallaway]

@ChuckJonas derp, npm changed that behavior, npm install will do pre-releases (wtf) unless you explicitly tag them as "next", see https://medium.com/@mbostock/prereleases-and-npm-e778fc5e2420

[ChuckJonas]

ya, this is a actually a good example of why the tags are nice. We think we have 0.0.6 ready but it would still be nice to test it before making it the latest. Once we are happy we can just update the tags instead of releasing the same code as a different version.

However, this change might actually warrant a new minor version, so maybe 0.1.0.

In general, I'm pretty lousy at sticking to semantic versioning.

[ralphcallaway]

@ChuckJonas awesome, no opinions on minor vs patch, feels like a bug fix which would typically be a patch, i think minor is when you add a new feature that's non breaking

once it's live i can turn on the auto checkouts using this command for a couple repos which would provide some decent test exposure

[ChuckJonas]

yea you are probably right. I was thinking "support for static resources as a feature"

Either way, I already released 0.1.0. I don't really even see any reason to beta tag it. Pretty sure we're the only ones using this