Open mitchspano opened 2 weeks ago
@mitchspano here are a couple of considerations/things I've run into when doing this same thing for Nebula Logger
fieldManageability
(options are DeveloperControlled
and SubscriberControlled
)
SubscriberControlled
would make the most sense for TAF, but not 100% sure about thatsfdx-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
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 yousfdx-project.json
that you include "ancestorVersion": "HIGHEST"
- if you don't specify an ancestorVersion
, then people won't be able to upgrade 😢
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.I'm sure there's some other stuff I'm forgetting - I'll let ya know if I think of anything else!
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.
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).
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:
Considerations for Managed Package Publication:
Trigger_Action__mdt
custom metadata type to ensure code isolation and prevent conflicts with other packages.Next Steps: