Deprecated sfdx source/mdapi/org commands will be removed on November 6th, 2024

[VivekMChawla]

What's Happening?

On November 6th, 2024, Salesforce will…

1. Stop bundling plugin-source with the Salesforce CLI sf(v2).
2. Remove the force:org:create and force:org:delete commands from plugin-org.

What's the Impact of This Change?

1. force:source:* and force:mdapi:* commands will not be available for use with sf(v2).
   • Solution: Migrate to sf project/org commands (migration guide)
   • Workaround 1: Manually install plugin-source after installing the CLI.
   • Workaround 2: Use a version of the CLI released before November 6th (<= 2.64.7).
2. force:org:create and force:org:delete will not be available for use with sf(v2).
   • Solution: Migrate to sf org commands (migration guide)
   • Workaround 1: Manually install an earlier version of plugin-org after installing the CLI (<= 4.8.2).
   • Workaround 2: Use a version of the CLI released before November 6th (<= 2.64.7).

Why is Salesforce Making This Change?

1. Standardizing the sf command syntax and structure is part of our strategic vision for sf(v2).
2. Distributing deprecated code for a prolonged period increases complexity and technical debt for the CLI as a whole.
3. A large majority of CLI users have already transitioned to the new commands.

Why is This Change Being Made Now?

We understand this will be a disruptive change for customers who postponed migrating away from the deprecated commands.

While there's never a "good" time for changes like this, we decided to make this change now because:

1. The impacted commands have been deprecated for over a year.
2. Tools and resources exist to help customers make this transition (see below)
3. Workarounds exist for customers requiring additional time to make this change.

As mentioned in the "workaround" notes above, customers who need more than four months to migrate can pin themselves to the latest (stable) CLI version available on November 5th. Changes specific to Winter ’25 (e.g., support for new metadata types) will be incorporated into this version, giving it a reasonable "shelf life" beyond November 6th.

Additional Resources

• The Salesforce CLI Deprecation Policy
• Migration Guide for force:source* and force:mdapi:* Commands
• Migration Guide for force:org:* Commands

Questions or Feedback?

Please share any questions or feedback by commenting on this issue.

[avesolovksyy]

@VivekMChawla
To be able to switch to new style commands in a painless way, first of all feature-parity should be in place.

But as of now, is it possible to force new command sf project deploy start to ignore source tracking altogether, i.e. even if the target org has source tracking enabled? Maybe by setting some property or global env variable.

We would really like to have such option/feature to have 100% confidence that nothing will break in our CI process after switching to new commands, since we currently have ~100 sandboxes (that were created with source tracking supported, just in case so to say) and connected to our pipelines.

Or maybe you happen to know how to disable source tracking at sandbox level without refreshing/re-creating it?
Open to any suggestions except the one involving refresh of 100 sandboxes)

[VivekMChawla]

@avesolovksyy - Thanks for your feedback and question!

@cristiand391 notes that we added a command to disable source tracking for operations against a specific org.

sf org disable tracking

Salesforce CLI stores the setting in the org's local configuration file so that no source tracking operations are executed when working with the org. This would be a reasonable option in long-lived developer environments that work with those sandbox orgs.

As for CI environments, if they don't require source tracking with any orgs, you can set the environment variable SF_DISABLE_SOURCE_MEMBER_POLLING=true.

Please try this and let us know if you still believe there's a feature-parity gap here.

[avesolovksyy]

@VivekMChawla
Thanks a lot for quick response and provided suggestions - we have tried both of them.

sf org disable tracking works perfectly, although it is inconvenient to prefix every sf project deploy start command in every CI job with this command - but I unerstand that CI is not the main use case for sf org disable tracking.

Setting up SF_DISABLE_SOURCE_MEMBER_POLLING=true doesn't work at all, i.e. it is still trying to pull for SourceMembers at the end of successful deploy, basically no difference with previous behaviour when no variable is set:

But then we just updated name of variable to use older SFDX prefix, i.e. SFDX_DISABLE_SOURCE_MEMBER_POLLING=true, naturally we got a warning re usage of deprecated variable, but eventually it started ignoring source tracking:

No polling for SourceMembers as you can see below:

To be on the safe side we've decided to set up both in our final implementation, but seems like there is some issue with supporting SF_DISABLE_SOURCE_MEMBER_POLLING variable:

export SF_DISABLE_SOURCE_MEMBER_POLLING="true"
export SFDX_DISABLE_SOURCE_MEMBER_POLLING="true"

While doing these experiments we were using latest avaialbe sf cli version @salesforce/cli@2.56.7 installed into ubuntu-latest docker image. And test sandbox with source tracking enabled was upgraded to Winter 25 (i.e. api version 62.0) just rigth before we started our experiments.

To summarize, setting global variables seems to be working fine and has solved our current challenge (but still need to monitor logs for next few days), we just need some clarification re which variable name to stick with.

[avesolovksyy]

@VivekMChawla
We have bumped into one more difference in behaviour of sf project deploy start VS sf force source deploy commands that is creating challenges for us.

In our CI scripts quite often we are creating an adhoc temporary directory and copying there some metadata to be deployed.
Nothing special just mktemp -d command in bash + some subdirectory beneath it. So the final path that is passed to sf project deploy start command looks something like this: /tmp/tmp.QhJxv99Xpy/02-meta-enableSettings

sf project deploy start -d "/tmp/tmp.QhJxv99Xpy/02-meta-enableSettings" -o myTestOrg ...

But we are running this deployment when current directory is pointing to our project checkout. And it seems like sf project deploy start internally converts absolute path to some relative one, i.e. how to get from current directory to directory with metadata to be deployed. Not a problem, but then it throws an error complaining about unsafe path due to these '..', as on screenshot below. But again we are passing an absolute path, these '..' have appeared as result of internal path conversion.

Error (MetadataTransferError): Metadata API request failed: The filepath "../../../../../tmp/tmp.QhJxv99Xpy/02-meta-enableSettings/settings/FieldService.settings-meta.xml" contains unsafe character sequences

Have something like this been already reported? Any suggestions how to deal with it at a large project scale, i.e. without changing current directory before running sf project deploy start command etc.

[avesolovksyy]

@VivekMChawla
When trying to apply naive workaround like this, i.e. navigating to tmp deploy dir and run command already from that dir as current:

pushd $ourTmpDirWithMetadataToBeDeployed
sf project deploy start -d . -o myTestOrg
popd

We are getting the following error complainig about lack of SF DX project structure:

Any suggestion how can we just deploy simple directory with metada from outside of our current project checkout? I don't want to generate every time temporary sfdx project just to do adhoc deploy. There is no problem like that when using sf force source deploy command.

[nvuillam]

If it can help readers, here is the list of all commands I migrated for the next version of sfdx-hardis :)

• sfdx force:mdapi:convert -> sf project convert mdapi
• sfdx force:mdapi:deploy -> sf project deploy start --metadata-dir
• sfdx force:source:retrieve -> sf project retrieve start
• sfdx force:source:deploy -> sf project deploy start, sf project deploy validate, sf project deploy quick
• sfdx force:source:pull -> sf project retrieve start
• sfdx force:source:push -> sf project deploy start
• sfdx force:source:tracking:clear -> sf project delete tracking
• sfdx force:source:manifest:create -> sf project generate manifest
• sfdx sgd:source:delta -> sf sgd:source:delta
• sfdx force:org:create -> sf org create sandbox | sf org create scratch
• sfdx force:org:list -> sf org list
• sfdx force:org:delete -> sf org delete scratch
• sfdx config:get -> sf config get
• sfdx config:set -> sf config set
• sfdx auth:web:login -> sf org login web
• sfdx auth:jwt:grant -> sf org login jwt
• sfdx auth:sfdxurl:store -> sf org login sfdx-url
• sfdx org:login:device -> sf org login device
• sfdx force:data:record:get -> sf data get record
• sfdx force:data:record:update -> sf data update record
• sfdx force:data:soql:query -> sf data query
• sfdx force:data:bulk:delete -> sf data delete bulk
• sfdx alias:list -> sf alias list
• sfdx alias:set -> sf alias set
• sfdx force:apex:test:run -> sf apex run test
• sfdx force:apex:execute -> sf apex run
• sfdx force:package:create -> sf package create
• sfdx force:package:version:create -> sf package version create
• sfdx force:package:version:delete -> sf package version delete
• sfdx force:package:version:list -> sf package version list
• sfdx force:package:version:promote -> sf package version promote
• sfdx force:package:installed:list -> sf package installed
• sfdx force:package:install -> sf package install
• sfdx force:user:password:generate -> sf org generate password
• sfdx force:user:permset:assign -> sf org assign permset

[cristiand391]

To summarize, setting global variables seems to be working fine and has solved our current challenge (but still need to monitor logs for next few days), we just need some clarification re which variable name to stick with.

hey @avesolovksyy, that was a bug (CLI should support SF_ and SFDX_ ones), fixed here:
https://github.com/forcedotcom/cli/tree/main/releasenotes/#2587-september-11-2024-stable

thanks for reporting!

We recommend using the SF_ ones, the SFDX_ env vars are supported for backward-compatibility but are deprecated.

[thvd]

What is the impact of this change on tools provided by Salesforce? Will they be upgraded on time? For example lot's of industries solutions rely on Vlocity Build Tool
This uses SF CLI/SFDX under the hood to do MDAPI deployments.

See also vlocityinc/vlocity_build#687