0

I am really new to the packaging process for creating managed package and looking for a help from the experts,

We do have a use-case where we need to include the source of a managed package inside a customer specific managed package,

Let's say we have a core managed package called Package A (Repo A) which contains the core functionalities of our product and have another customer specific package called Package B (Repo B) where we use some of the classes of the Package A.

The question here is, do we have a way to package both the sources into one package when creating a package for the Customer? Which means without giving a customer with 2 different packages with the installation order, we need to bundle/ build a package with the Customer Specific implementation source + the core functionalities source.

Is this possible in the 2GP packaging model?

Improve this question

1 Answer 1

Reset to default
2

AFAIK, there is no way to inject an existing managed package to be a part of another managed package. Obviously, you could combine the source codes of both packages and create a new package, but that would really not be preferable or even worthy of being considered an OK approach. Instead of trying to combine 2 packages into a single managed package,

  • Retain 2 different managed packages so you can leverage the benefits of modular development approach and keep the code maintenance effort optimal in the future.
  • Define the dependency over one or more packages. This will also enable you to be able to create patch versions for each of these packages and be able have a mix of different version dependencies among these packages for various customers in the future. Or, you can be able to opt to have one package as Unlocked, if needed.

You can define dependencies in the sfdx-project.json file (under packageDirectories). Sample snippet can be found here & more details about package dependency can be found here.

If the customer tries to install a package in their org before installing a dependency, a user-friendly message will be displayed asking to install the dependencies first.

Or, you can provide them with a script that would automatically install the dependencies and then the actual package. Sample script is present here.

Update:

You can have any # of package directories in a single SFDX project (although, only one package directory can be set as default) and have them defined in the sfdx-project.json file. In the screenshot below, you can see that there are 2 package directories force-app & customer-app. One will be used for the source code of your core package, while the other for the customer related package. Note that the SFDX source folders and structure under each of this package directories will be the same. In the sfdx-project.json file, you can see that I've defined the both of these package directories, while having customer package as dependent on core package via dependencies. You can define any # of dependencies for a single package.

enter image description here

Within a single SFDX project, you can use force:package CLI commands to generate package for each of the package directories individually. You might want to check out 2GP & Unlocked Packages. This github project is a good reference for seeing how multiple package directories with dependencies can be placed within a single SFDX project.

Improve this answer
8
  • Thanks @arut for the explanation. We are not going to include the core managed package inside the customer related package when build the customer related package. What we are trying to achieve is to have two separate folder for core and customer source in a Sfdx project and try to build one package. Will this possible?
    – Hariprasath
    Commented Dec 5, 2020 at 3:33
  • 1
    That is exactly what I intended to be done via dependent packaging. Check out the updated answer. Hope that gives a better idea.
    – arut
    Commented Dec 5, 2020 at 5:32
  • Thanks for the great answer @arut. This is the exact explanation I wanted to know.
    – Hariprasath
    Commented Dec 5, 2020 at 8:40
  • 1
    (1) The package directories that you define & use within the SFDX project refers to the local directory only (where metadata corresponding to a package is defined and used by force:pacakge commands). So, you can use any # of package directories. (2) If a customer tries to install the customer app (which had the dependency defined), then a graceful message would be shown asking to install the dependencies first i.e., core package is not installed automatically unless an explicit installation script is created.
    – arut
    Commented Dec 5, 2020 at 10:56
  • 1
    (3) During development, namespace is indicated in the sfdx-project.json file, while in app release process it is managed via Namespace Registry. So, during dev, you would use a single namespace. While I have specifically not tested dependencies with different namespaces in production, I believe it should be possible because a package (or dependent one) is uniquely identified by its name and version #. Namespace is a logical grouping of related packages. SF recommends using a single namespace and this will help you to be able to use @namespaceAccessible in future.
    – arut
    Commented Dec 5, 2020 at 11:02

You must log in to answer this question.

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