Packaging allows you to group various Salesforce Components for distribution or deployment. In this post, we will learn about unlocked packages and the difference between unmanaged, managed, and unlocked packages.
What is an Unlocked Package?
Salesforce offers different types of packages. The unlocked package is a good fit for internal business apps and allows customers to develop modular applications. An unlocked package is the right type for enterprise customers Unless they plan to distribute an app on AppExchange. They can use unlocked packages to organize their existing metadata, package an app, extend an app that they’ve purchased from AppExchange, or package new metadata.
It helps you to add, edit, and remove metadata in your org in a trackable way. You can install unlocked packages to multiple organizations and upgrade your Salesforce apps more easily and faster.
Unlocked packages follow a source-driven development model. The source of truth of the metadata contained within the package is your version control system, not what’s in an org. This model brings with it all the advantages of modern source-driven development models.
Modular Application Development Concepts
With Modular Application Development, customers can break one monolithic app to multiple packages defining dependency between them. Unlock packages allow us to do that. Salesforce enterprise customers mostly used the org-based deployment approaches like Changesets and ANT deployment to deploy metadata to their orgs. With Unlocked Packages, there is a way to do Modular Application package-based deployment.
What are the benefits of packaging over Change Sets and ANT Migration Tool?
Unlocked Packages offers certain advantages over Change Sets and the ANT Migration Tool. The following are some key benefits of packaging:
- Packages promote a source-driven development approach and version control system. With package versions, you have an immutable, versionable artifact that can be used in CI.
- With a version-based approach, you can develop and install different package versions in target organizations and adopt a build-once, deploy-anywhere approach.
- You can express dependencies among packages. With this capability, you can embrace a modular approach where each package contains a set of metadata that represents a distinct unit of functionality, with well-defined dependencies among packages.
- Packages provide a repeatable, scriptable, and trackable way of managing change as you develop functionality using Salesforce DX.
Check Salesforce DX Useful CLI command.
Types of packages in Salesforce
First-Generation Packaging
Before Salesforce DX came along, we had two types of packages:
- Unmanaged packages used for one-time deployment of metadata.
- Managed packages is used for Salesforce partners that build and list apps on AppExchange.
Second-Generation Packaging
With Salesforce DX, Salesforce launched Unlocked Packages and managed second-generation packages (a.k .a. managed 2GPs). With that Salesforce wants modular application development customers as they do for partners. Unlocked Packages are designed primarily to address the packaging needs of customers. It offer a super-set of features compared to unmanaged packages.
Difference between unmanaged packages, managed packaged, and unlocked packages.
| Unmanaged Package | Managed Package | Unlocked Package |
| Not upgradable | Upgradable, and one can namespace them or choose not to | Upgradable and one can namespace them or choose not to |
| Metadata elements are not IP Protected | Metadata elements are IP Protected | Metadata elements are not locked and can be changed by system admins |
| Allows for the creation of extension packages | Can be created in salesforce UI and distributed via appexchange | Requires Salesforce CLI to generate them |
| Unmanaged package containers automatically pull dependency | Components are locked and one cannot modify them directly in production or sandbox | Allows you to build your applications in a modular way |
| It is easier to manage when codebase is modularized | It is easier to manage when the codebase is modularized |
Building Unlocked packages using Salesforce CLI
Unlocked packages cannot be created using salesforce UI and require knowledge of salesforce CLI and requires source code in DX Source format. Scratch orgs are not required but a DevHub is mandatory. However scratch orgs are recommended since the deployment to them is faster.
Here is a useful Salesforce DX command to create an unlocked package. If you are new to SalesforceDX, please check this recording.
Create Unlocked package
sfdx force:package:create --name <name> --description <description> --packagetype Unlocked --path force-app --nonamespace --targetdevhubusername <Devhubalias>Create a package version
sfdx force:package:version:create -p <packagename> -d force-app --wait 10 -v <Devhubalias>Publishing and Installing Unlocked packages
sfdx-project.json defines the Version Name and version number. Installing can be using the Subscriber Package Version Id. Installation can also be done via the Salesforce CLI.
sfdx force:package:install --wait 10 --publishwait 10 --package <packagename>@1.0.0-1 -r -u <alias>By Default, a BETA package is generated. We can promote a package using the below
sfdx force:package:version:promote -p <packagename>@1.0.0-1 -v <DevHubalias>Creating Dependency between packages
sfdx-project.json can be used to define a dependency between packages.
Further Learning
Please subscribe our YouTube channel to get notifications for video uploads. Check our “Session in 2019” page for all upcoming and old sessions of 2019. Sharing is Caring, so Share with your friends.
