8

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.

6

You have a fundamental misunderstanding of 2GP. It is not used to distribute code to clients as an ISV. It is entirely a feature that allows you, as an ISV or customer, to create functional packages that you can install in pieces in Sandboxes, Production, Developer Orgs, and Scratch Orgs. This can minimize deployment and development cycles, but won't have any notable benefit for your clients. Your clients will always be installing 1GP packages (the one with the registered namespace).

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

These namespaces are a different type, and they're registered directly from the command-line. Even better, you can use any reasonable name, even if there's already a public version of that namespace. They are unique to your org.

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

With the command line. You have to preconfigure the settings in the sfdx-project.json. Basically, create an artifact directory (e.g. feature-1), put files in it, specify an optional namespace for it in sfdx-project.json, and use the force:package:create and/or force:package:version:create, etc. It's in the documentation.

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.

It lives in the Dev Hub org. You end up "installing" them via the command-line via force:package:install.

Given that there is no UI for second generation packaging, how would one support the package in subscriber orgs?

You don't; they are only used for migrating code around, not installing namespaces in your subscribers' orgs. LMA is not affected from the current process you use today.

Do you still get LMA records created for installations of managed second generation packages if there is no code in the namespace org?

N/A. They aren't installed, you still use your 1GP process.

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

No, the Developer Org still holds your product. Each product still needs its own, public-facing namespace. 1GP per Developer Org that can be installed. 2GP are simply fragments of the 1GP.

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

They will never be ready for prime time for this purpose; they're meant to help move metadata around.


Summary

DX is useful for development, but doesn't alter your current ISV practices at all. You use 2GP to (hopefully) make your deployments easier, not for any other reason. For example, if you had common code you needed in two different products, you can now put them into a single common 2GP, and install it in both products, and provide a way to easily maintain newer versions of the code.

  • 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 '18 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 '18 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 '18 at 22:03
  • Thank you for the amazing detail and helpful information! – Eric Nov 12 '18 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 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.