This is the third and final blog post chronicling the Salesforce CLI team’s progress towards open-sourcing the sfdx command line interface (CLI). If you haven’t read the previous posts, check out the first and second ones for a refresher and to understand where we started, how far we’ve come, and where we’re going. This has been a long journey, and we’re very happy to be closing this chapter and setting our sights on the future!

CLI + OSS

We would like to celebrate and say, “We’ve done it!” We’ve been working on breaking up the salesforce-alm plugin (a.k.a. Toolbelt) for the past two years, and we’re about to remove it altogether. The salesforce-alm plugin used to contain every single command, roughly 201 in total! Now the sfdx CLI is organized into plugins that contain logically grouped commands. For example, plugin-packaging contains all of the sfdx force:source:package(1):* commands. We didn’t just move code from one repository to another and call it good, we took this opportunity to truly refactor everything. We’ve modernized our code, moved functionality into libraries that can be shared across tooling teams, adde strong and dependable testing, and rewrote our CI/CD system for testing and release. This was a bigger effort than we had initially assumed.

For each plugin we :

1. Added many unit and integration tests to ensure that we wouldn’t break existing workflows and CI.
   1. Roughly 2700 unit tests including plugins and libraries
   2. Roughly 850 integration tests for plugins and libraries
2. Refactored a lot of code and functionality, so that we’re proud of it.
   1. Reduced a lot of redundancy and convoluted code
   2. Since it’s open source, you can see everything we write
3. Migrated to the latest versions of our libraries to reduce bugs and deprecate old versions that we no longer support.
   1. Same versions of libraries to support sf and sfdx
   2. One bug fix results in two bugs fixed
4. For some larger plugins, we broke them apart into a plugin and a library. This allowed us to separate our areas of concern, create consistent functionality across our tooling, and allow other Salesforce developers to use these libraries. Out of that, we’ve created the following libraries.
   1. source-deploy-retrieve
   2. source-tracking
   3. packaging
   4. salesforcedx-templates
   5. salesforcedx-apex
   6. plugins-testkit
   7. source-testkit
   8. sfdx-core

Now, imagine doing that for all 20 of the core plugins we now install when you install the sfdx-cli! We had a lot of work to do, but we’re so happy to say that we’ve done it! Starting this month, we’ll no longer be including the salesforce-alm plugin by default, but you can always use sfdx plugins:install salesforce-alm if you really need a command that’s still there.

If you remember back to the previous blog posts, there’s a gif in each showing the output of sfdx plugins --core and we used this to show how the salesforce-alm plugin was being broken apart into plugins. Now, if you run that command, you’ll see all of our plugins like how we described in the first blog post.

Building a reliable CLI

A common theme we kept hearing from our community over the years has been “reliability over features,” and we’ve taken that to heart. As we’ve been breaking up the Toolbelt plugin, we’ve been baking in reliability, so we can provide you with a command line tool that you can trust.

In order to improve the reliability, we took a four-pronged approach from an engineering and architectural standpoint.

Plugins, plugins, and more plugins

We took the Toolbelt plugin and broke it down into individual plugins. We also have other plugins from Salesforce that are not directly bundled with the CLI, but are available for you to install and run if interested. We did not stop there, we have given the power to you to build your own commands through plugins.

Better libraries

Abstracting out common functionality into libraries has helped us a great deal with consistency as all of our developer tools (including the Extensions for VSCode, CodeBuilder, DevOps Center, etc.) use the same common libraries. We’ve even seen other Salesforce developers using these libraries to solve their own use cases.

NUTs for tests

We improved testing by adding more NUTs (Not-Unit-Tests) which includes everything that’s not a unit test, such as E2E tests, Smoke tests, Integration tests, etc. We not only test the plugins, but also the libraries themselves. We provide the same NUTs test kit (that we use internally for writing our tests) for anyone that wants to write a plugin and test their commands. We’ve seen these sorts of tests block multiple bugs and regressions from ever being released!

Goodbye Toolbelt

Starting this month, salesforce-alm (a.ka. Toolbelt) will no longer be listed. We want to take a minute to thank each and every one of you who took the time to test out a beta: command(s). It would have been impossible to deliver an entirely rewritten CLI tool without many breaking changes if it wasn’t for your help. Everyone on the CLI team, and the rest of the Developer Tooling teams, is humbly grateful to you all for using our tools and being a part of the community.

Speaking of the community, we’ve started having GitHub Discussions about new features, ways to fix long-standing bugs or behavior, questions, or feedback. We’ve found these to be super useful ways to gather ideas from everyone in the community and we plan on continuing to use these moving forward. We’ve also started adding the Help Wanted label to issues where an open-source contribution would be a straightforward and fast way to fix the issue. We’ll usually leave a comment with some starter material to get you pointed in the right direction.

We’ve seen great success from this, for example, this issue was marked as Help Wanted with a few comments on where the fix might happen, and then this contribution came in that fixed the issue. We love to see these interactions and will continue to build the community around them. If you want to get involved, check the issues tab of our GitHub repo for all Help Wanted issues.

What about the future?

You can read more about the ways that we’ll be introducing new features and styles into sfdx in a recent blog post (some of these have already been introduced in sfdx). We encourage you to adopt the new styles, try them out, and share your feedback!

Conclusion

It’s been quite the journey to achieve an open-source CLI you can trust, and we are glad that we’ve finally made it! We’ve learned so much along the way, and it’s been a crazy few years since we started this major project. Whether you’ve been using the CLI since before we started, or joined us halfway through this series, everyone on the team, and at Salesforce, is incredibly thankful for you, and always in awe of the ways you continue to improve the tools. sfdx is now open-source, and the sf CLI is open-source by default. We’re flipping this chapter closed and opening the next chapter on sf — we’re energized for the coming year and ready to bring you new and exciting commands!

About the authors

Willie Ruemmele has been an engineer on the Salesforce CLI team for over 3 years and has overseen this journey to open-source from start to finish. He’s super excited to transition the focus to the sf CLI and build a lot of useful functionality that the community wants to see. When he’s not working, he enjoys being active outside, time with friends, and traveling.

Pooja Reddivari is a Senior Manager of Product Management in the Platform Developer Tools & Experience organization at Salesforce. She is passionate about building scalable and resilient products that delight developers and customers. Pooja has worked in the enterprise, education, and fintech verticals with 12+ years of experience as an engineering and product management professional. She’s @poojasalesforc1 on Twitter and in/poojareddivari/ on LinkedIn.