function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Jeff Garbers - PRODJeff Garbers - PROD 

Deploying new version of package after moving shared classes to another package

I'm using SFDX to build and deploy 2nd-generation packages for our internal use. My first package -- I'll call it "green" -- uses several custom fields and objects I'd already created in our production org. To get "green" to work in a scratch org, I included those field and object definitions in the package. Installing this "green" package into production worked fine.

I then created a new package "blue", which needed some of the classes I'd developed and deployed in "green". So I refactored those shared classes and components out of "green" and into a new package "common", and then made "common" a dependency for "green".

Now, I'm unable to install my new refactored version of "green" into production. It's dependent on "common", so "common" would need to be installed first. But installing "common" fails with errors because it includes classes that are already in the previous "green" package. I thought I'd just uninstall "green", but it appears as though doing so would delete all of the custom fields and objects that are defined in "green" (for use in scratch orgs) but had been created in production long before "green" existed.

Can anyone suggest a way around this catch-22? Thanks in advance for any advice you can offer.