16

What's the main differences between unlocked & unmanaged packages?

Improve this question

3 Answers 3

Reset to default
20

As for me, the most important difference is that the unlocked package uses SFDX for development. So you, as a developer, could create a package, create a new version, promote, install to org within only SFDX. So it is possible to script all required actions, so that automate the process and use CI in the development of the package.

Unlocked Package

  • 2-nd generation package
  • requires enabled DevHub and Packaging feature on DevHub on an org
  • uses SFDX and all its powerful instruments for development (like sfdx force:source:push sfdx force:source:pull CLI commands)
  • source of truth is your version control system
  • uses scratch orgs for development
  • can have dependencies on other 2-nd gen packages

Unmanaged Package

  • first-generation package
  • commonly uses Metadata API to develop components of the package
  • source of truth is a developer org
  • you need to manually add components to a package, upload new version from dev org by means of UI
Improve this answer
8
  • 2
    I agree with much of what you say, though not all. We haven't moved to 2GP yet and use both managed and unmanaged packages, developed using git, sfdx and scratch orgs. Yes, we have to have a "release org" since that's how 1GP works. However, we do consider git as the source of truth - achieved by always performing a full metadata API deployment to the release org when we are to "upload" a new release. The big drawbacks of 1GP are linear versioning, inflexibility in removing components/changing globals and poor "modularization support". If I was starting now I'd go 2GP, despite its issues.
    – Phil W
    Commented Feb 5, 2020 at 11:38
  • The main 2GP issues are (to me) the lack of 1GP to 2GP migration (this is coming but has some big hurdles to cross) and the lack of 2GP bundles (automated install of dependencies/related packages, which is being looked at for future release).
    – Phil W
    Commented Feb 5, 2020 at 11:40
  • @PhilW I agree with you with all points. A small correction to my answer. By saying "source of truth is a VCS" I meant, that you can develop code on a scratch org after that delete it, but you still can create a new version of the package, add components to it, no problems. In first-generation, you can't do the same, because you need an org, where components are located. So even if you use VCS for first-generation (that is a best practice), it isn't a "real" source of the truth, you still need manually to add components to a package and manually upload a new package version.
    – Oleksandr Berehovskyi
    Commented Feb 5, 2020 at 11:48
  • I can't disagree with that; a change made directly on the release org will override whatever you do in your VCS unless you overwrite that change by re-deploying before manual addition/upload. This is more a nuance, to my mind.
    – Phil W
    Commented Feb 5, 2020 at 11:51
  • The bullet points here are not quite correct. A bit too much for a comment, though.
    – sfdcfox ♦
    Commented Feb 5, 2020 at 13:11
34

Unlocked Packages are more like an advanced form of Managed Packages, not Unmanaged Packages. Many of the same differences exist for Unlocked Packages and Managed Packages as compared to Unmanaged Packages.

Upgrade Components

Unlocked Packages can be upgraded, like Managed Packages. Unmanaged Packages cannot be upgraded without uninstalling.

Downgrade Components

Unlocked Packages can be downgraded. Managed Packages and Unmanaged Packages cannot be downgraded.

Dependencies

Unlocked Packages can have dependencies on other packages, both Managed Packages and Unlocked Packages. Managed Packages cannot have dependencies on Unlocked Packages.

Multiple Packages

Unlocked Packages can have multiple packages in a single org, unlike Managed Packages, which each require their own org.

Namespace Differences

Managed Packages support Namespaces. Unlocked Packages may only exist in a Managed Package namespace, or in a null namespace, like Unmanaged Packages.

Delete Components

Unlocked Packages can delete metadata that is obsolete, unlike Managed Packages (with limited exceptions). Unlocked Packages can optionally not delete metadata that is obsolete, unlike Unmanaged Packages.

Source of Truth

Unlocked Packages are always sourced from local files, while Unmanaged Packages and Managed Packages always source from an org.

As you can see, Unlocked Packages are more of a hybrid between Managed Packages and Unmanaged Packages, leaning towards the Managed Package end of the feature spectrum. They are far more convenient than Unmanaged Packages for almost all use cases, except the obvious one-off "share the package with the others" scenario, and often more convenient than Managed Packages for non-ISVs (though they also help ISVs).

Improve this answer
4
  • @OleksandrBerehovskyi Since this answer speaks to the differences in packaging types, I've removed the relevant section. It's actually pretty insignificant either way, since my main point is that Unlocked Packages are a hybrid of the two older types, plus additional features not found in either.
    – sfdcfox ♦
    Commented Feb 5, 2020 at 16:18
  • 1
    As an ISV, we deliver some of the code components after installing the core package in the customer's org. Now these code components are deployed directly. The question is: as an ISV can we develop unlocked packages to deliver generic code components multiple customer? Or are these unlocked packages tied (hard coupled) to the customer's production org (Devhub)?
    – Sam
    Commented Mar 3, 2020 at 1:26
  • @Sam I don't know if you raised this as an actual question with reference back to this one? It would be good to do so if you didn't.
    – Phil W
    Commented Jan 22, 2021 at 16:43
  • @Sam I just saw your comment. In case you didn't get an answer, any admin user in any org can install any Unlocked Package, assuming they have the appropriate password. They are not locked to just "related" orgs or something like that.
    – sfdcfox ♦
    Commented Nov 30, 2021 at 17:17
1

Hope You can find the answer on this FAQ You can also add up to this :

  • Managed Packages always requires a namespace to distinguish the package on app exchange from other developer packages
  • Managed packages restricts the removal of methods if the package is already released. Have a look at this

Also, Have a look at this extremely useful Stack Overflow Question

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .