I have a Salesforce org with a nontrivial amount of Apex code and custom objects. We aren't using a VCS for our metadata yet and we're in "sandbox hell" even with only a few developers writing Apex. We've been looking forward to DX but we're having a bit of trouble getting started.

In particular, the Adopting Salesforce DX webinar published in August advocates "breaking up the happy soup" - i.e. modularizing an org's code and other metadata into separate projects, and hence separate VCS repositories. They recommend using unmanaged packages as the temporary mechanism to extract the needed pieces from the source org. This sounds good in theory, but I'm getting a bit stuck on the mechanics of how to create unmanaged packages when there are dependencies across packages. Obviously I don't want to have duplicated components in the packages/VCS repos. I want to be able to make one package depend on another package. How do I do that?

For example:

  • I create Package 1 with some base components A, B, and C.
  • I then want to create Package 2 with components D, E, and F. D depends on A, so the Salesforce Package Manager automatically adds A to Package 2.

I don't want A to be pulled into Package 2 - I don't want any metadata to be duplicated between my two packages/repos. How do I fix this? Do I need to use managed packages and extension packages (and hence dev edition orgs) as part of this process? Should I just manually doctor up the source from Package 2 after I extract it from my sandbox using the Metadata API to remove the duplicated pieces, before I commit the code to git?

If there are any examples out there that illustrate this process using something more complex than the Dreamhouse app (e.g. showing multiple repos with dependencies), I'd love some pointers!

  • I can't say for sure, but I'd bet on keeping everything in a single package, if your objects all depend directly or indirectly of A. You would split your project into different repos only if there's metadata da does not depend on the other package. Sep 18 '17 at 18:46
  • Happy Soup sure sounds a lot better than "Horrifying Invasive Tumor" I can totally relate... good question. I'm looking forward to being able to spin up a scratch Org with the shape of my Production Org. Sep 18 '17 at 19:14

I know this was asked a while ago, but for other people searching, I answered a similar question here.

To summarise though, if you're just starting out adopting VCS and the like, then don't try to dive straight into packaging, but start out by getting the core metadata that you're seeing problems with under version control. Once that's done, and your dev team is comfortable working with version control, then start to worry about splitting out packages consisting of stable and isolated code. Doing it all in one go falls somewhere between an uphill struggle and destined for failure :)

  • 1
    I'd back the same approach too. Best to start adopting to a VCS first before going into packaging straightaway. Then try to move your projects into their own directories so they can be moved out to a package later.
    – markgarg
    Apr 8 '21 at 10:28

The exact source code thats there in your gitrepo does not get pushed to your sandbox or PROD organization .There is an intermediately step in DX where the structure of the code in the git repository needs to be translated to metadata API format .

If there are lot of dependency then every release you will have to still have a process to resolve the merge conflicts between different modules .The aim should be to isolate dependencies as much as possible .

Alternatively You have figured it out right of using managed package and extensions as the solution .

Managed package will allow you to create a hard dependencies so meaning you will need to install the managed package and on top of it create components and create an extension packages .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.