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
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:
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:
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!