13

Looking at second generation packaging for managed packages and am a bit confused on feature parity with 1st gen with regards to managed packages..

Primary concern is that things are set up correctly or if we should just stay with 1st gen packaging.

The documentation is pretty sparse. Primary concerns are LMA support and multiple packages under the same namespace

Namespace

One of the benefits of second gen packaging is having multiple packages under one namespace. However, in order to associate a namespace with a scratch org to develop the package the namespace have to be registered in the dev hub org.

Currently the only way I see to register a namespace is to create a developer edition org via the environment hub.

Easy enough, but then how would you create multiple packages under that namespace? The answer to this may depend on some of the answer to the following questions

Packaging

If one has the developer edition org with namespace and the namespace is registered, how do you create the package using second generation packaging.

When using the packaging command you can generate a package with the namespace but then where does it live? I highly doubt the code will automagically be populated in the namespace org.

LMA Support

Given that there is no UI for second generation packaging, how would one support the package in subscriber orgs? Do you still get LMA records created for installations of managed second generation packages if there is no code in the namespace org?

Wrap up question

Is the developer org holding the namespace only there to provide the namespace? Does any code ever make it to the namespace org?

Keep in mind the goal is to have a solution with multiple packages under the same namespace..

OR

Is second gen packaging not read for prime time with managed packages in this scenario and we should stick with 1st generation packaging.

1 Answer 1

13

Currently the only way I see to register a namespace is to create a developer edition org via the environment hub.

You don't need to use the Environment Hub, any Developer Edition with a Registered Namespace will suffice. Given the new role of namespace orgs, there's no need to have a huge Partner Edition-sized Developer Org, a normal Developer org will suffice. Keep in mind that you can register the same namespace with multiple Dev Hub orgs as well, but you'll have to share passwords or something to make that happen.

Easy enough, but then how would you create multiple packages under that namespace?

Set the namespace property in sfdx-project.json to the desired namespace. All packages created in the project will use this namespace. There's nothing special about this process other than minimal setup.

If one has the developer edition org with namespace and the namespace is registered, how do you create the package using second generation packaging.

You use sfdx force:package:create command, just as you would with Unlocked Packages. The difference is that your Dev Hub would be linked to the namespace, and the namespace would be specified in sfdx-project.json; you should also specify -t Managed to make the package a 2GMP.

When using the packaging command you can generate a package with the namespace but then where does it live? I highly doubt the code will automagically be populated in the namespace org.

The "packaging org" concept only applies to 1GMP. In the new model, the code is stored in package metadata directly in the Dev Hub org, and is not directly exposed in the UI.

This is because your source code repository is now the source of truth, so the metadata doesn't need to "live" in an org in the same sense as a 1GMP requires. No automagical installation/updating of the namespace org is required.

This is also coincidentally the reason why you now only need two orgs (a Dev Hub and a Namespace Org) for any number of packages, instead of one org per package, each with separate namespaces. This can also reduce the number of namespaces you need to keep track of, as all your packages can now share the same namespace.

Given that there is no UI for second generation packaging, how would one support the package in subscriber orgs? Do you still get LMA records created for installations of managed second generation packages if there is no code in the namespace org?

Yes, LMA allows you to log in to Subscriber Orgs with both 1GMP and 2GMP packages. Remember, even in 1GMP, the source code in the org isn't literally the code that's in a subscriber's org. In the 1GMP model, metadata is uploaded to a PackageVersion object, and that's the metadata that's used. In truth, the only real change here is that the metadata is now stored in an org different than the namespace org.

It doesn't matter if you have code in your namespace org, as that has no bearing on the metadata in the subscriber's org. This is also technically true for 1GMP, except that the metadata has to be in the Packaging Org to be uploaded, while in 2GMP, the files are directly uploaded from your computer.

Is the developer org holding the namespace only there to provide the namespace?

Yes. That is the new, sole purpose a Developer Edition org in this context. Development should be done in Scratch Orgs, and packages are uploaded to the Dev Hub org, so DE orgs serve no other purpose at this point, if you're using 2GMP.

Does any code ever make it to the namespace org?

No code will be placed in the namespace org, unless you want to, and is completely unnecessary. The metadata package is now stored in the Dev Hub org instead, but not "installed" in to the Dev Hub. In other words, the Dev Hub holds the metadata used for installation, but doesn't operate with that metadata actually installed in the org.

Is second gen packaging not read for prime time with managed packages in this scenario and we should stick with 1st generation packaging.

In 2018, when this question was asked, it was highly experimental and not well-suited for some types of ISV apps. In this revised 2021 answer, 2GMP is largely ready for prime time.

It's still not really possible to convert a 1GMP to 2GMP (unless you're in the Pilot program), but this should be available at some point in the future.

If you already have a 1GMP, stick with it unless you can convince your subscribers to move to 2GMP, which requires uninstalling the old package and installing the new one. If you're making a new package, use 2GMP now to avoid some hassle.


This answer was heavily modified from the original answer, which is in the revision history for this answer. It has been removed entirely from the main answer body, as it contained a number of factual errors. Thanks to Felix van Hove for bringing this to my attention.

11
  • Thanks. I guess I read too much into this statement: "or develop and distribute packages to your customers". As for the namespace, you cannot create a scratch org with a namespace without having a developer org to register it. I kept getting a javascript name error
    – Eric
    Nov 12, 2018 at 21:56
  • @Eric Yeah, another confusing part of DX; the scratch org can have a NS, but each 2GP can have a NS as well. The default sfdx-project.json file is misleading. The top-level "namespace" is the 1GP namespace from your Developer Org that has a registered namespace, which you have to register with your Dev Hub first. Each path in "packageDirectories" can have its own namespace as well. Those are not registered anywhere outside your Dev Hub org.
    – sfdcfox
    Nov 12, 2018 at 22:01
  • @Eric And yes, I feel the effort is probably worth it for many projects, but there's a confusing and difficult ramp-up to get into the swing of things. We'd be using it already if it were not for the fact that our org is super-sized and can't even fit Accounts into a scratch org. Or our role hierarchy.
    – sfdcfox
    Nov 12, 2018 at 22:03
  • Thank you for the amazing detail and helpful information!
    – Eric
    Nov 12, 2018 at 22:13
  • @sfdcfox I strongly disagree with a few statements you are mentioning here. 1) 2GP are ment to replace 1GP completely. But as of now, the only part of 2GP which is in GA is Unlocked Packages. They are really intended for better structuring of your code, improving internal deployment practices etc, basically as you mentioned. But there is another type of packages in 2GP (already in beta), which would replace traditional 1GP packages. They still do not support push upgrades, patch orgs, LMO, listing on AppExchange - but it's on SF roadmap.
    – wesaw
    Mar 25, 2019 at 16:35

You must log in to answer this question.

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