2

My org is using multiple unlocked packages to organize components by purpose. This has caused the process of package version creation to be incredibly long due to a chain of dependencies.

Combining multiple unlocked packages into a single package would significantly ease the burden of packaging when it comes time for releases. I believe I'm in the last stretch of this process, but the big hurdle is the severing of ties between a component and the unlocked package it previously belonged to.

After removing a component from its current package (let's call it "objects") and adding it to the new package ("single-package") and successfully creating new versions for both, I arrive at the step where I go to Installed Packages and navigate into the currently installed version of "objects". From here I view the components, find the component I'm migrating, and click "Remove", after which I am able to install the new "single-package" unlocked package.

Is there any way to do this programmatically? I have been unable to find any metadata that may contain this link between component and package, but I would imagine there has to be a record that can be deleted or metadata property that can be changed.

Improve this question
1
  • Could you tell how many packages approximately and what level of dependencies...time being taken.. How much time does it take for deployment
    – Cloud Man
    Commented Feb 18, 2021 at 16:56

1 Answer 1

Reset to default
5

The intended path would be to update both the original package to no longer include the component, then include the component in the new package. Rather than removing from the UI, you can use the DeprecateOnly mode to update the original package and then install the new package (which you'd have to do anyways):

sfdx force:package:install -t DeprecateOnly -p "package1"
sfdx force:package:install -p "package2"
Improve this answer
5
  • Thank you for your input, @sfdcfox. I just tested this with my two packages that I created as a test to release 3 components (a trigger and two dependent classes). When I check the newly installed version that no longer contains these components using the DeprecateOnly flag, I am still seeing these 3 components as being a part of the unlocked package. This continues to prevent the installation of the unified package that should now have ownership of them. I tested this in both DX and the packageInstallation UI. Any ideas?
    – MooseBalm
    Commented Jan 14, 2021 at 11:50
  • Actually, I just tried again to see if I could find any further reflection of deprecation in the UI. This time, it did give me the notice that the component was deprecated and did allow me to install the newer package that has assumed control. Is there any inconsistency in the behavior of this command? Strange that I saw the exact same behavior as before the first time I attempted, but it seems to be successful now.
    – MooseBalm
    Commented Jan 14, 2021 at 15:09
  • @MooseBalm Not sure why it would have gone awry. It's supposed to work that way, and though my experience is limited, it's worked that way for me so far. Maybe the wrong version was installed? I know I have a hard time keeping track of all the various version numbers that start flying around when you get waist-deep in package dependencies.
    – sfdcfox ♦
    Commented Jan 14, 2021 at 19:50
  • 1
    yeah, for sure. I tried to stay on top of it and make sure the correct versions were present. I went through a run on an entire package earlier and it worked correctly. I'm now going through a test run of our entire code base now and I am hopeful. We'll see if there are any outlier components, but your answer seems to be spot on. Thanks!
    – MooseBalm
    Commented Jan 14, 2021 at 22:59
  • Also see salesforce.stackexchange.com/questions/402654/….
    – Keith C
    Commented May 4, 2023 at 10:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .