Managed Package Publication

[mitchspano]

Summary:

This document proposes publishing the Trigger Actions Framework (TAF) as a managed package. This will allow other packages, including those from Independent Software Vendors (ISVs), to formally establish a dependency on TAF.

Benefits:

• Increased adoption: Publishing as a managed package will make TAF more discoverable and easier for both customers and ISVs to integrate into their Salesforce solutions.
• Improved developer experience: ISVs can build on top of TAF without needing to embed the code directly in their packages. This simplifies development and maintenance.
• Enhanced collaboration: A managed package fosters a more collaborative ecosystem around TAF.

Considerations for Managed Package Publication:

• Namespace: Introduce a namespace field on the Trigger_Action__mdt custom metadata type to ensure code isolation and prevent conflicts with other packages.
• Global vs. Namespaced: Carefully review all classes and interfaces to determine if they should be global (accessible across all packages) or namespaced (accessible only within the TAF package). Consider the intended use of each class/interface and potential conflicts.
• Backwards Compatibility: Develop a plan to maintain backwards compatibility with existing customers who use the unlocked package. This may involve versioning and providing clear migration paths for future updates.
• Documentation: Update documentation to reflect changes introduced for the managed package version.

Next Steps:

• Review Salesforce documentation on managed packages and best practices.
• Finalize the design for namespace implementation and global vs. namespaced classes/interfaces.
• Develop a backward compatibility plan for existing users.
• Prepare documentation for the managed package.

[jongpie]

@mitchspano here are a couple of considerations/things I've run into when doing this same thing for Nebula Logger

• For fields on CMDT objects, you'll want to decide what makes sense to use for fieldManageability (options are DeveloperControlled and SubscriberControlled)
  • I think using SubscriberControlled would make the most sense for TAF, but not 100% sure about that
• If you add your namespace to your sfdx-project.json file, then only people with access to your devhub (presumably, that's only you?) will be able to (easily) work with the repo - if anyone else tries to create a scratch org using your repo, they'll get an error because they don't have access to whatever namespace you use
  • @jamessimone and I have taken the approach of having a second sfdx-project.json file (in Nebula Logger and Apex Rollup), and our pipelines swap out sfdx-project.json files when building the namespaced/managed package versions. It's a bit goofy & frustrating, but you can setup your pipeline to automatically handle it for you
• By default, you can't deprecate/delete any metadata from a managed package - if/when you think you'll need to do that, you'll have to get Salesforce to enable it in your devhub
• When creating new package versions for the managed package, make sure in sfdx-project.json that you include "ancestorVersion": "HIGHEST" - if you don't specify an ancestorVersion, then people won't be able to upgrade 😢
  • I made this mistake on my first upgrade of Nebula Logger - I release v4.0, and when making v4.1, I didn't specify an ancestor version, so no one could actually use it. As a result, v4.1 was never released publicly.
• If you're thinking of using Apex test suites, they're goofy & frustrating to use when you have a namespace - the classes listed in the test suite have to include the namespace, which is different behavior from how namespaces for Apex classes are handled everywhere else. As a result, I just exclude Nebula Logger's test suite from the managed package

I'm sure there's some other stuff I'm forgetting - I'll let ya know if I think of anything else!

[daveespo]

Also on the TODO list will need to be to get this package through security review. No ISV will be able to publish their package on the AppExchange if they have a hard dependency on another package that hasn't also passed security review.

And I'll also just state aloud that it's unlikely any ISV that wants their package to be available for installation from the AppExchange will be able to depend on this package. Package Bundles are not a platform feature so the current installation process will fail due to the missing dependency on this package.

[jongpie]

Following up on @daveespo's comment - even if you get TAF security reviewed & published in AppExchange, some ISVs still may not want to directly rely on another package (TAF), so some ISVs may still take TAF's metadata & bundle it into their own package. There are a handful of ISVs that do this with Nebula Logger. But by providing TAF as a managed package, you'll have the metadata in a state that makes it easy for ISVs to pull it into their own packages (if they want to go with that approach).

[benjaminloerincz]

A similar discussion was held in the past about fflib here / here.