ForceCLI/force

[Non Issue] Differences between ForceCLI vs Salesforce CLI (sfdx)

Closed this issue ยท 7 comments

Hi there,

Can someone from the core dev for ForceCLI advise of the differences with Salesforce CLI? The one that I think is obvious is that sfdx requires the 'Dev Hub' feature enabled and so uses adifferent data format and communication protocol than metadata; but are the end goals the same fore both tools though?

...and that you can't use Salesforce CLI with non Dev Hub orgs, or spin scratch orgs with ForceCLI (yet) seems to be other differences.

Hey Daniel,
The Salesforce CLI only needs Dev Hub authentication for the creation of scratch orgs. Force CLI, predecessor to Salesforce CLI, provides a more generic access to the underlying APIs - metadata, rest, soap, tooling and so on. The Salesforce CLI is focused on supporting the ALM and CI/CD processes around Salesforce DX. This is includes things like source tracking between the local environment and scratch orgs, de-composition of metadata into a "source" format to support better source code control, second generation packaging and automation with respect to secure credential storage and headless test automation.

One of the goals of the Salesforce CLI is to gain some degree of parity with the Force CLI. Having said that, I think there is value in an open source, community owned CLI along side the Salesforce CLI.

Hope this helps!

Oh, and you can use both CLIs to interact with non-scratch orgs. Some commands require scratch orgs and a DX "project", but not all.

Comments from @dcarroll in #218 and #223 provide some context for why Salesforce CLI (sfdx) exists. You can think of the Salesforce CLI as a Salesforce-supported rewrite of the force cli.

The feature sets are currently a little different, but that's mainly due to development resource availability and priorities. The goals are largely the same; the design philosophy is a little different.

I would like to keep force cli stateless (apart from OAuth tokens); we'll see how practical that is when we get around to adding support for the SourceMember object in scratch orgs.

The force cli doesn't use any config files. The Salesforce cli is extended through plugins. You're more likely to extend force cli functionality by composing it with other command line tools in scripts.

The same APIs are used by both tools. The sfdx metadata format is only an on-disk difference; the metadata format is the same over the wire. The decomposed format is a big improvement for large metadata objects like profiles, so I would like to add support for it to the force cli.

So the reason I reached out here is because my experience with sfdx has been that it errors out on many commands unless I have a Dev Hub feature enabled. For example I am not able to push/pull plain metadata components, number one it wants the new sfdx project format, number two it errors out with some Dev Hub missing fields message.

That leads me to believe sfdx is aimed at the new Dev Hub approach which is available ONLY for orgs Enterprise, Performance, and Unlimited Editions (or the Dev Hub trail org you can sign up for).

If I am wrong on this, can someone confirm that I indeed can use the sfdx to push the old style metadata files? Otherwise sfdx use case is limited and that's where ForceCLI can be used.

You can use sfdx force:mdapi:deploy and sfdx force:mdapi:retrieve with any org. sfdx force:source:push and sfdx force:source:pull only work in scratch orgs. I posted to the salesforce stackexchange with an explanation of why these only work in scratch orgs.

Closing as non-issue.