I've found some time to return to an older project of mine, moving my org away from the org development model to the package development model to make better use of SFDX and CI/CD.
The issue I'm running into is with how to handle customizations to page layouts. Things like adding new fields, new detail buttons, new related lists, new list buttons on related lists. I'm not trying to add a new page layout here, I'm modifying existing page layouts.
The general idea I've gotten for handling this up to now has been "it's a common component used by multiple projects/packages, so it needs to live in a common project/package that become a dependency for other projects/packages"
Following that would end up polluting the common packages pretty severely, I'd think. Adding a related list, for example, would require adding the following to the "common" package:
- The parent object page layout
- The child object
- The relationship field on the child object (pointing to the parent object)
- The child fields referenced by the related list
At the end of it all, I can't help but see the "common" pacakge(s) just becoming a bloated mess with nearly every object, field, action/button/link in it. Effectively, I think that brings me back to the org development model. Not terribly useful for trying to use unlocked 2GP or build scratch orgs to hold just enough customizations to allow declarative work.
My assumption here was that any "common" package would be at the root of the dependency graph. That every other package would then depend on it.
End of edit.
The Layout metadata type does act as a container for things like fields, buttons, and related lists, but are we able to leverage those items in SFDX/2GP like we can for SObject fields?
Do we have a decent way to handle modifications to page layouts, or is this a use case that isn't addressed by SFDX/2GP?
If it isn't supported by SFDX/2GP, is a decent way to handle this to effectively maintain two groups of projects?
- One contains bloated common packages that allow us to contain the "effective" page layout (contributions to the page layout from all downstream development)
- The other contains common packages with only the base requirements so that scratch orgs can be built and unit tests can be run