How to publish your SFDX plugin with these easy steps
twitter social iconlinkedin social iconfacebook social icon

How to publish your SFDX plugin with these easy steps

By: Guilherme Uhelski

We all know that out-of-the-box commands that come with the Salesforce CLI only provide functionalities to meet common needs of your customers or partners. And as developers, you and I both know, that every team has specific needs. Needs that are usually not met by the basic functionalities. Luckily for us, the Salesforce CLI can be extended with your own functionalities. Since different teams have different requirements, SFDX enables you to create your own plugin that can automate or solve the specific needs of your team or project. In this blog, I’ll dive into the details and show you different strategies to publish these plugins. 

Are you going public or private with your SFDX plugin?

So. You’ve just finished your SFDX plugin and now it’s finally time to share your awesome creation with the world. There are two options: Make it available for everyone or make it available for just a select number of people. Often, you are driven towards the latter. Sometimes, companies want to keep the plugins private and other times, the plugin is made for a specific team with specific requirements. No matter if you opt for public or private, this simple guide will show you how to publish your SDFX plugin step by step.

1. Getting to know the Node Package Manager

The Node Package Manager, or NPM for short, is the world's largest public database of JavaScript software and the meta-information surrounding it. This database contains packages. A package is a file or directory that is described by a package.json file and when you create a new plugin (via the sfdx plugins:generate command) a package.json file is automatically created for you, and that is basically all you need to publish your plugin. Or should I say, your package?

For more details about how to create a package.json file, its fields, and how to customize it to your needs, you can check out the official documentation.

2. Why and when you should opt for a scoped package

One of the mandatory fields for creating a package.json file is the name field. This name should be unique since it will be representing and identifying the package once it’s published to the NPM registry. However, when a package is already published with a specific name, whether by another user or organization, it will not be possible to publish your package with the same name. So, what to do next?

Creating a package with an already existing name in mind is not the end of the world. Of course, you can think about a different name and rename your package, but there is another option. You can also choose to create a scoped package.

The benefits of a scoped package

Scoped packages are a way to group related NPM packages together and connect them to each other by a specified “scope”, that acts pretty much like a namespace. Some benefits of this type of packages are:

  • You don’t have to worry if the package name is already in use, as long as you haven’t already published such a scoped package before.
  • You don’t have to worry that someone else will publish into your scope, only scope members have the permission to do so.

3. How to publish a public plugin on NPM

You have chosen to make your plugin public? Alright! Here’s what to do. The recommended way is that you publish your plugin on the Node Package Manager registry as a scoped package. Once you have created your package.json file, all you need to do to publish your plugin publicly is run the following command in your preferred terminal:

npm publish --access public

Once your plugin is published, everyone will be able to install it by simply running:

sfdx plugins:install youruser/yourplugin

For more details on how to create a public scoped package follow the steps described in the official documentation.

4. How to publish a private plugin on NPM

To share your plugin with a limited set of users or teams, you can publish private user-scoped or organization-scoped packages to the NPM registry. With NPM private packages, you can use the NPM registry to host code that is only visible to you and your chosen collaborators. It’s important to remember that private packages always have a scope, and scoped packages are private by default.

After successfully creating the private (scoped) package, you navigate to the root directory of your package. There, you run this command to publish your private package to the NPM registry:

npm publish

In order to view your private package page, you can visit the NPM website. There you can replace *package-name with the name of your private package.

For more details on how to create and publish a private package, you can follow the steps described in the official documentation.

5. Other options to publish a private plugin

Although the Node Package Manager is a great tool, there are alternatives. I can imagine it is sometimes needed to host your own registry on your own infrastructure. In that case, Verdaccio is a great alternative that enables you to do just that. It is – like they describe themselves on their website – a lightweight private NPM proxy registry.

6. We’ve got a hands-on screencast about writing SFDX plugins for you

I can hear you thinking: “Nice, but let’s take a step back. How do I write these SFDX plugins?”. We’ve got you covered. If you want to learn how to create your first SFDX plugin and learn more about the SFDX plugin’s architecture, you can watch this screencast we made:

Appsolutely Inspired Webinar 'Write your first Salesforce CLI plugin'

Of course, this is a very brief how-to version on publishing plugins. And, if you’re not doing this on a daily basis it can seem like a daunting task. Well, if that is the case, we are here to save the day. Do you, your team, or your company need help in setting up and distributing public and private plugins? We are happy to help. Just drop me a line.


Who is Guilherme?

Guilherme has been on board as a Salesforce Developer with us since 2019. He likes to push the boundaries of tech and innovation as much as he can. As a software developer, he loves the challenge of being given a problem and then having to find his own way to solve it. Originally from Brazil, he decided to move to The Netherlands a few years ago. Quite a culture shock for this mountain bike enthusiast, since there are practically no steep hills to climb. However, he quickly discovered that even in our little country, you can bike for hours through amazing landscapes and challenge yourself. A perfect counterweight for the heavy coding he’s doing during the week, we dare say!

Share this article:
twitter social iconfacebook social iconlinkedin social icon

divider graphic


Product customizability and Overridable flows: Giving the controls to the customer
September 20, 2022

Product customizability and Overridable flows: Giving the controls to the customer

By: Hugo van Krimpen When developing Salesforce products for the AppExchange, we regularly face requ...

Hugo van Krimpen
By Hugo van Krimpen
Partner Event: Future-Proof Service Operations 2022
September 4, 2022

Partner Event: Future-Proof Service Operations 2022

Future-Proof Service Operations How to extend your service operations to sales, marketing, and beyon...

Luuk Timmermans
By Luuk Timmermans
Why you should stop just creating code!
August 10, 2022

Why you should stop just creating code!

By: Rodrigo Dantas Deep dive on Software Best Practices, and what we saw at TDX22 that backs up this ...

Rodrigo Dantas
By Rodrigo Dantas