Retrieve command incorrectly appends .resource instead of .js to static resource

[jonathanmorris180]

Summary

The retrieve command incorrectly appends .resource to a retrieved JS custom metadata resource instead of .js.

Steps To Reproduce

1. Run sf project retrieve start -m "StaticResource:<any-JS-resource>" --target-metadata-dir test --unzip
2. Notice that the retrieved file has a .resource suffix instead of .js

Expected result

The file is retrieved with the correct file extension.

Actual result

The file is retrieved with a .resource extension.

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.95.6",
  "nodeVersion": "node-v22.16.0",
  "osVersion": "Darwin 24.5.0",
  "rootPath": "/Users/jonathanmorris/.local/share/sf/client/2.95.6-b4d51b1",
  "shell": "zsh",
  "pluginVersions": [
    "@jedi/sf-jedi-plugin 4.0.0 (link) /Users/jonathanmorris/Documents/repos/sf-jedi-plugin",
    "@muenzpraeger/sfdx-plugin 0.5.0 (user) published 1878 days ago (Tue May 12 2020)",
    "@oclif/plugin-autocomplete 3.2.31 (core)",
    "@oclif/plugin-commands 4.1.26 (core)",
    "@oclif/plugin-help 6.2.29 (core)",
    "@oclif/plugin-not-found 3.2.57 (core)",
    "@oclif/plugin-plugins 5.4.42 (core)",
    "@oclif/plugin-search 1.2.25 (core)",
    "@oclif/plugin-update 4.6.45 (core)",
    "@oclif/plugin-version 2.2.30 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.42 (core)",
    "@oclif/plugin-which 3.2.37 (core)",
    "@salesforce/cli 2.95.6 (core)",
    "agent 1.23.1 (core)",
    "apex 3.6.19 (core)",
    "api 1.3.3 (core)",
    "auth 3.7.3 (core)",
    "code-analyzer 5.2.2 (user) published 9 days ago (Tue Jun 24 2025)",
    "data 4.0.40 (core)",
    "deploy-retrieve 3.22.27 (core)",
    "dev 2.5.1 (user) published 226 days ago (Tue Nov 19 2024)",
    "info 3.4.69 (core)",
    "limits 3.3.57 (core)",
    "marketplace 1.3.8 (core)",
    "org 5.9.0 (core)",
    "packaging 2.16.0 (core)",
    "schema 3.3.68 (core)",
    "settings 2.4.32 (core)",
    "sobject 1.4.63 (core)",
    "telemetry 3.6.45 (core)",
    "templates 56.3.52 (core)",
    "trust 3.7.101 (core)",
    "user 3.6.26 (core)",
    "@salesforce/sfdx-scanner 4.12.0 (user) published 65 days ago (Tue Apr 29 2025)",
    "sfdmu 4.38.0 (user) published 186 days ago (Sun Dec 29 2024)"
  ]
}

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[mdonnalley]

@jonathanmorris180 was this behaving differently in an older version of the CLI? If so, are you able to pinpoint the version that it stopped working?

I think this is working as expected. When you use the --target-metadata-dir and --unzip flags, you're telling the command that you want to pull the metadata in metadata format - not source format. If you did a normal retrieve (e.g. sf project retrieve start -m StaticResource) you'll get the JS file as expected

[jonathanmorris180]

@mdonnalley Thanks for the quick reply. I just tried a few different versions mounting various official docker containers but even using the oldest one on DockerHub (1.86.7-legacy.0) pulled the file down with the .resource extension.

I just looked around online and found this article which explains the .resource file extension. So I guess it's working as expected. I didn't realize there was any tangible difference in pulling files in source vs. metadata format, but that article helped to explain things a bit.

This actually stems from another issue I had when needing to pull files into a temporary directory on my machine and running into errors with source tracking. It would be great if we could just disable source tracking for a specific command instead of needing to create the org without it (sf org create scratch --no-track-source) since I don't know why source tracking is even needed when pulling files.