Why Use Second-Generation Packages in Salesforce?
Do you know about Second-Generation packages?
Max Shkrob, Salesforce Developer at Twistellar, gathered all the features and the main differences between 1GP and 2GP. Happy to share knowledge with our code experts. Look!
❛ Hello everyone! A short time ago, I found something new for myself in SF Packages and decided to share a short article about it. I hope it will be helpful for you! ❜
Okay, so what are Second-Generation Packages in Salesforce? 2GP is a new way to build packages in Salesforce using SFDX and version control. It allows building your packages in a more "dev" way than the first generation. Let me show you below the main differences between 1GP and 2GP.
1. Org vs. Version Control System
In 1GP, a packaging org is the source of truth for the metadata in your package. This means that your org controls what you include in your package. In 2GP, your version control system becomes the source of truth for the metadata in your package. It allows you to select what metadata should be included in your package.
Why do we need this? Let's imagine that you have complex logic and to test it, you created some classes and components that have dependencies with the metadata that you want to include in the package. To build 1GP, you will need to delete the metadata from the org that you don't want to include. In 2GP, just don't include it in your version control that's all. All that you don't want to include may still be in your org.
2. Number of Managed Packages
1GP: a packaging org can own only one managed package. 2GP: The namespace of a managed package is created in a namespace org and linked to the Dev Hub. It means that in 2GP, you can create more than one managed package in one org and select the metadata to be included in that package using SFDX. Cool, right? 😀
Okay, so we can create more than one package in one org. But what do namespace org and linked Dev Hub stand for?
To make a 2GP, you will need to:
- Create a Dev Org and create a namespace (as in 1GP)
- Create and log in to the Dev Hub org you created to make packages, then add permission to your System Administrator to register a namespace (SalesforceDX Namespace Registry checkbox)
- Then go to App Launcher and type in Namespace Registries. Open and click on Link Namespace. It will ask you to log in to your Dev Org with a namespace and give access to use the namespace
- That's it. Now you have a Dev Hub ready to build your packages.
Note 1: You can link more than one Dev Hub to an org with the same namespace, but SF recommends using one Dev Hub for one org with a namespace.
Note 2: As per Note 1, I tried to create two packages using different Dev Hubs and one namespace with Apex class having one class with the same name in both packages. I received an error when trying to deploy the second package in an org where the first one was already installed. So if you decide to use more than one Dev Hub, please be ready to resolve such issues.
Don't forget to check out: Salesforce Apps: Managed vs. UnManaged Package Importance from Lederhosen Salesforce
3. Global Apex vs. @namespaceAccessible Annotation
Now you know that you can create multiple packages with the same name, but is it possible to make them communicate together? And the answer is yes! In 1GP, the only way to use methods from one class from one package in other classes of the second package is through Global Apex, but in 2GP you can use the @namespaceAccessible annotation.
@namespaceAccessible allows packages with the same namespaces to use each other's methods in an org where they are installed. It still makes them secure and allows you to build big products from more than one package.
Notes: Here’s something you need to know about @namespaceAccessible.
- You can't use the @namespaceAccessible annotation for an @AuraEnabled Apex method.
- You can add or remove the @namespaceAccessible annotation at any time, even on managed and released Apex code.
- If a public or protected variable or method is declared as @namespaceAccessible, its defining class must be either global or public with the @namespaceAccessible annotation.
4. Package Versioning
1GP: Package versioning is linear, and patch versions can only be created in specialized orgs called patch orgs. 2GP: Package versioning supports branches and patch versions are created using Salesforce CLI. The version control system is the source of truth, and there are no patch orgs.
Because 2GP uses version control, you can use not only a linear way to build package versions, but also the one resembling a "tree" in VCS.
You can read more about how versions work in 2GP here: Patch Versions and Package Ancestors
5. Unlocked Packages
One more thing that 2GP has and 1GP doesn’t, are unlocked packages. Unlocked packages are something between Managed and Unmanaged packages.
- They can be created with or without a namespace
- CLI is mandatory to create an unlocked package
- Not IP protected. It can be edited in the installed org. Thus, it gives users who have installed the package the ability to change its code but be careful with this, because if you create a new version of a package and users update their organization with that version, they will overwrite their changes with the changes from the new version.
Check out another amazing log by Twistellar here: How to Send SMS Messages from Salesforce That Really Work
To Wrap It Up
These were some key features of Second-Generation Packages and my thoughts on why you can use them instead of Fist-Generation Packages. Here are the links that will help you start building 2GP packages: Workflow for 2GP and Package Commands.
I hope this article will help you, good luck and happy coding!
🔺Subscribe to our blog to get the latest Salesforce expert articles.
Follow Twistellar's page on LinkedIn or subscribe to our blog to get more materials.