--- schema_version: "1" id: 50ad81f6e5be017c97dea18a1f7775551deb013a2cac16a46bf8929786e0985b title: Overview of Salesforce CLI Plugins collection: developer version: current locale: en-us portal_url: https://docs.salesforce.com/developer/current/en-us/salesforcedx/sfcliplugin/guides/conceptual-overview/conceptual-overview.md canonical_url: https://developer.salesforce.com/docs/platform/salesforce-cli-plugin/guide/conceptual-overview.html source_site: developer.salesforce.com content_type: documentation content_hash: abbdaa5ad526e9975b3011dfcb4eaa71b974508e114fb7619444d1bea3a1b3c9 products: - Salesforce CLI Plugin Developer Guide - salesforcedx --- # Overview of Salesforce CLI Plugins A Salesforce plugin is a set of CLI commands that are grouped together. For example, the [plugin-deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve) plugin provides commands to deploy and retrieve metadata to and from an org, such as `project deploy start` and `project retrieve start`. Salesforce CLI is itself a plugin. Salesforce CLI plugins are npm (Node.js package manager) packages. Node.js is a JavaScript runtime environment that supports execution outside of a browser. If you prefer strongly typed languages, don’t worry: We recommend that you use TypeScript, which transpiles to JavaScript. The sample plugin generated from the plugin generator command (`dev generate plugin`) uses TypeScript. We recommend using TypeScript instead of JavaScript because it's strongly typed and thus better suited to large projects. The stronger types give a better IDE experience and reduce common programming mistakes that are easy to make but hard to debug. A user installs a plugin by running `sf plugins install PLUGINNAME`, where `PLUGINNAME` is an npm package on [https://npmjs.com](https://npmjs.com). To see your installed plugins and their versions, run `sf plugins`. To see which versions of the core Salesforce-provided plugins are installed on your computer, run `sf plugins --core`. ## Why Create a Salesforce CLI Plugin The Salesforce CLI core plugins provide commands and functionality to meet common needs that customers and partners have. But your team often has specific needs. That's why Salesforce CLI is extensible. Perhaps you have specific tools that you want to use for code analysis as part of your CI/CD automation process. You can build a plugin that runs your bespoke code-analysis tool. Creating a plugin provides the benefits of a consistent user experience and a common framework. A Salesforce plugin that’s included in the core Salesforce CLI but developed outside the core CLI team is [code-analyzer](https://github.com/forcedotcom/code-analyzer), which supports [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview). With Code Analyzer, you can make sure your code adheres to best practices, helping you identify problems earlier while you develop. The plugin contains the `code-analyzer` commands to run scans and manage rules. Because so much Salesforce functionality is surfaced in APIs, the sky's the limit as to what you can build. With Salesforce Plugin Generator, the [@salesforce/sf-plugins-core](https://github.com/salesforcecli/sf-plugins-core), and [@salesforce/core](https://github.com/forcedotcom/sfdx-core/tree/v3) libraries, you have the tools to get started with Salesforce CLI plugin development. ## Required Knowledge and Skills Building a Salesforce CLI plugin requires different knowledge and skills than most Salesforce development. Before you dive into plugin development, familiarize yourself with these areas. - [TypeScript](https://www.typescriptlang.org/) - [Node.js](https://nodejs.org/en/) - [npm](https://www.npmjs.com/) (Node.js Package Manager) - [Yarn](https://classic.yarnpkg.com/lang/en/) - [Salesforce Platform APIs](https://trailhead.salesforce.com/en/content/learn/modules/api_basics) ## Salesforce CLI Architecture Salesforce CLI is an npm package called `@salesforce/cli`. You run it on your local machine or continuous integration (CI) system. It supports the installation of custom plugins. Most of the core functionality that Salesforce provides comes from plugins. Use Salesforce CLI for many of your development tasks, such as authorizing to any type of org, creating scratch orgs, synchronizing source code between your scratch orgs and version control system (VCS), and running tests. All Salesforce CLI commands start with `sf`. To see which core and installed plugin version you're using, run `sf plugins --core`. To see the available sets of commands—also known top-level topics—run `sf --help`. To see a list of all available commands in an easy-to-read format, run `sf commands`. Are you a visual person? Then check out [this page](https://github.com/salesforcecli/cli/blob/main/ARCHITECTURE.md#salesforce-cli-architecture) for a graphical representation of Salesforce CLI. Be sure you scroll down to the graphic of a typical Salesforce CLI plugin and its libraries. Finally, see the [command execution flow diagram](https://github.com/salesforcecli/cli/blob/main/ARCHITECTURE.md#command-execution) which outlines the high-level process that occurs every time a user executes a CLI command. ### Core Salesforce CLI Plugins The core `sf` commands are provided by a set of core Salesforce-provided plugins that are installed by default when you install Salesforce CLI. These core plugins contain commands in a hierarchy that reflect a typical developer's workflow. For example, the top-level topics include configuring the CLI (`config`), working with Salesforce DX projects (`project`), and working with scratch orgs and sandboxes (`org`). See the [Salesforce CLI Command Reference](https://developer.salesforce.com/docs/platform/salesforce-cli-reference/guide/cli_reference.html), which is also organized into this command hierarchy. You can create your own top-level topics to contain your commands. See the [Salesforce CLI Status](https://github.com/salesforcecli/status) page for a list of all the core CLI plugins, their GitHub repos, and their status. ### Open Source Repositories All the code that makes up the core Salesforce CLI is open sourced in GitHub repositories, from the [top-level cli](https://github.com/salesforcecli/cli) package to the individual plugins, such as [plugin-deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve) and [plugin-org](https://github.com/salesforcecli/plugin-org). We highly recommend that you study this code to learn the best practices of Salesforce CLI plugin development. ### Open CLI Framework (oclif) oclif is an open-source CLI framework developed by Heroku and maintained by Salesforce. It powers Heroku CLI, the core Salesforce-provided plugins, and Salesforce Plugin Generator. The plugins that you generate with Salesforce Plugin Generator use the oclif format and can take advantage of the many features that the framework offers. In addition to enabling plugin creation, this framework enables developers to create their own standalone CLI applications. For details about oclif, see [https://oclif.io/](https://oclif.io/). For information about the features that oclif offers, see [https://oclif.io/docs/features](https://oclif.io/docs/features). For the oclif API reference, see [https://oclif.io/docs/commands](https://oclif.io/docs/commands). ## How sf and sfdx Plugin Development Differs Some of you might be familiar with the old and deprecated [`sfdx`-style Salesforce CLI commands](https://developer.salesforce.com/docs/atlas.en-us.248.0.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm) and even have created an `sfdx`-style plugin. Creating an `sf` plugin is similar. For example, you still use Typescript or Javascript as the programming language, and the underlying framework is still oclif. But there are a few key differences: - `sfdx` commands use the `SfdxCommand` base class whereas `sf` commands use the `SfCommand` base class. Both of these classes offer developers different types of functionality. For example: - `SfdxCommand` offers various properties related to working with usernames, such as `supportsUsername` and `requiresUsername`. `SfCommand` doesn't have these properties and instead provides custom flags. See [`optionalOrgFlag`](https://salesforcecli.github.io/sf-plugins-core/functions/flags_orgFlags.optionalOrgFlag.html) and [`requiredOrgFlag`](https://salesforcecli.github.io/sf-plugins-core/functions/flags_orgFlags.requiredOrgFlag.html). - `SfdxCommand` automatically initializes various classes that developers are likely going to need, such as `configAggregator` and `logger`. To stay lighter, however, `SfCommand` doesn't work this way. Instead, you initialize those classes yourself. See the [API Docs](https://forcedotcom.github.io/sfdx-core) for `@salesforce/core` for examples. - `SfCommand` provides more UX methods by default than `SfdxCommand`. See the [API Docs](https://salesforcecli.github.io/sf-plugins-core/modules/sfCommand.html) for details. - Help and error messages are stored in Markdown files rather than JSON or JavaScript. - The style of help messages and user experience (UX) design is different. A few examples include: - In `sf`, we capitalize the beginning of command and flag descriptions, and use ending punctuation. In `sfdx` we kept descriptions lowercase and didn't use punctuation. - The human-readable table output looks different in `sf`. - `sf` plugins have `sf`-specific linting rules, such as use of dashes instead of camelCase in long flag names. - Plugins that are bundled in Salesforce CLI are required to generate JSON schema for all their commands. This requirement isn't enforced for non-bundled plugins, although it's recommended.