fflib as Second Generation Managed Package (2GP)

Question

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 1

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.

Answer 2

G'day folks. Apologies for being a bit late to this discussion.

@lightxx -- There are pros and cons about separating the fflib classes out to a new package.

All things being equal, it makes sense to isolate the fflib classes into two different packages; one for Apex Mocks and one for Apex Common.

Having said that, there is currently a couple of downsides. The first being the need to have each package go through the security review separately. The second issue becomes the current lack of support for "bundled package deployments." It is on the roadmap, but currently not available. That lack of support for that feature creates issues during upgrades and support for AppExchange.

The earlier comment that you referenced from Andy Fawcett that the fflib classes should be bundled in the package is somewhat dated and pre-arrival of 2nd Generation Package. Having said that, the issues mentioned above still factor into this question.

There was an effort to outfit the Apex Mocks and Apex Common classes with the @NamespaceAccessible annotation. You can see an earlier PR Attempt in Apex Mocks here. In the end, the decision was to abandon the attempt because of issues at the time with the annotation. Those issues have been fixed. Since then, there has been no real interest that I am aware of into resuming this work until now. I, and others in the Apex Enterprise Patterns team, have discussed the idea of starting a new attempt but there has been no serious effort made in that direction. If this is something that you would be interested in helping with, I would suggest opening a feature-enhancement issue on the Apex Mocks and Apex Common repos and we can continue the discussion there.

I hope this helps.