fflib as Second Generation Managed Package (2GP)

So, in a project of mine (a Second Generation Managed Package) I have a dependency on fflib.
My initial idea was to include fflib-apex-common and fflib-apex-mocks as 2GPs with the same namespace as my solution.
However, this would require a refactoring of fflib, because to make this work I would either need to decorate all the required classes with @namespaceAccessible(see here) OR replace every public access modifier with global. Not good. I don’t really want to touch the code of fflib.

The only other way is to just copy fflib to my source directory (not really copying but submodule-ing it to my source directory). I don’t like that approach either. My gut feeling tells me I don’t want to have fflib in my package. Also, I’m wondering why no one seems to have released fflib as 2GP already. I guess there has to be some reason for this?

To me, it feels like I’m caught between a rock and a hard place. I’d really like to use fflib just as a dependency in my sfdx-project.json file.

What are your opinions on that topic, or can you give me any best practice recommendations please?

Answer

I’ll start this answer by recognizing that questions which solicit opinions, rather than objective answers, are frowned upon on StackExchange.

Having said that, the question was framed beautifully and this is an important topic.

I’ve been giving this a lot of thought lately. I’m hopeful that I can provide a constructive response based on my experience delivering Platform Expert consultations to more than 100 partners since 2GP went GA.

2GP’s support of multi-package, same-namespace (MPSN) solutions is profoundly transformative. Improved reuse of code, better separation of concerns, faster package installation, safer and more frequent upgrades, and greater autonomy and agility during development are all benefits enabled by 2GP.

Taking full advantage of these benefits requires an evolution of how packaged Salesforce apps are built, especially when it comes to critical building blocks that our community has come to rely on, like fflib-apex-common and force-dot-com-esapi.

I don’t think it’s enough to add @namespaceAccessible to the existing libraries and call it a day. The ability to share logic across packages without being forced to create global APIs unlocks entirely new ways of thinking about how we solve common problems. Keeping one foot in the past by having to worry about whether our libraries are backwards compatible with 1GP holds us back.

Instead, I believe that…

  • Important libraries should be forked to allow 2GP-specific customizations to be made without expectation of backwards compatibility with 1GP.
  • A “bedrock” template should exist, bundling key community libraries into a single package, forming a foundation for MPSN solutions.
    • I suggest this instead of separately packaging each library because there needs to be a balance between the development and the distribution/support aspects of the packaging lifecycle, especially when dealing with thousands of subscribers at scale.

I know that many AppExchange developers are stuck on 1GP until 1GP=>2GP migration becomes available, but there is a steadily growing cohort of developers who cut their teeth solely on 2GP. There are also teams who’ve worked with 1GPs for years and are now doing double-duty building on 1GP and 2GP. These are the groups who would benefit from, and hopefully contribute to, new community-led efforts for 2GP specialization.

I’ve been test driving these ideas both inside and outside of Salesforce for the past couple of months. My current plans are to create an “ISV Bedrock”-style framework that delivers some of what I’ve discussed sometime in FY’23 (i.e. after February, 2022).

The OP’s question and the thoughtful comments added by my friend Phil W. give me confidence that I’m moving in the right direction. I’m looking forward to hearing the thoughts and perspectives of others on this topic.

Attribution
Source : Link , Question Author : lightxx , Answer Author : Vivek M. Chawla

Leave a Comment