Having recently joined an ISV with an old 1GP, I want to make some significant improvements to the code. (We are planning a new 2GP, but not just yet).

Making major changes in our single Partner Dev Edition is difficult as changes to existing classes, triggers etc get picked up by new builds and, if the code isn't yet complete, causes build problems and incomplete/untested code to enter the build.

So, I want to do my dev in another org - Dev Org, Sandbox, Scratch Org - I don't really mind, so long as I can do my work without breaking the existing package!

I did download all the code in the current package, to upload to a Scratch Org, using:

sf force mdapi retrieve -s -r ./mdapipkg -p "Package Name"

But, trying to deploy this to the Scratch Org, either through VS Code (where I could at least specify a Namespace) or uploading it as a Package through Workbench's 'Deploy' option all failed, primarily due to circular references (VF Page for an object's Edit/View etc needs the object defined, but the object won't deploy because the VF Page is missing) and other reasons.

So, can I even create another PDE or Individual Dev Org, and deploy our package code to it, complete with the Namespace? It would have been so much easier if I could produce 'sandbox' orgs from the PDE, with all the code, and then deploy changes back to the PDE (like a normal Sandbox -> Production workflow), but this option doesn't appear to exist. The PBO can spawn Sandboxes, but with the code in our Production org, not our PDE (not an option - I did check!).

I'm sure I'm not the only person to have had this issue, so I'm hoping there's a good, practical solution to this.


1 Answer 1


Pretty shocked that an ISV is developing their package directly on the packaging org rather than using git, scratch orgs and the SF CLI.

Moving to the latter "best practice" setup is the first step to take, which it seems you are trying. You'll need to set up an SFDX project (the sfdx-project.json) and make sure you structure the metadata appropriately (perhaps under the default force-app/main/default folder, but you can change this how you like).

You need to fix the deployment issues, clearly, and these may be due to having not pulled the whole package content, or because there is unpackaged cruft on the packaging org that you have pulled. You may also face issues with needing to enable certain features on the org to allow deployment. This is done using the scratch def - typically config/project-scratch-def.json.

Once you have it clean and deployable to a Partner Developer scratch org (in source rather than mdapi format), you can drop it all into git (github, bitbucket, gitlab or another flavour). Clearly the latter needs to be a private repo.

Anyway, you will find lots of info about setting up SFDX projects, including on trailhead. The point is that this is effectively the same even when wanting to deal with a 1GP managed package's source.

The only real difference is that when you want to build a new version of the package, you will need to explicitly deploy the metadata from a clean local checkout of the relevant git branch to the packaging org, and upload a new version through the Setup UI's package manager.

BTW, I recommend using namespaced scratch orgs (not everyone does) because there are certain types of metadata (such as Aura components and Flows) that need explicit specification or use of the namespace within them.

  • Phil, Yeah, it's not the best setup. To be fair, it was created about 13 years ago by someone without a great deal of SF experience, and certainly not a developer. It is what it is. There is a LOT of unpackaged cruft. I'm pretty sure the mdapi version does have all the current source code in it. I pulled the package from the Dev Edition, to get all the code in the package, without the stuff that's not been added. Since I arrived, ALL the code is in GitHub, but that includes the cruft.
    – cyberspy
    Commented May 9 at 14:38
  • Part 2. I've just found the Environment Hub, which looks like can be used to create additional PDE orgs, but the meta-data isn't added (like when you create a sandbox). Is this route worth pursing, or should I stick to Scratch orgs? The new process for 2ndGen packages seems pretty good - but I'm amazed how difficult 1stGen packages are to get right (unless I'm missing something!)
    – cyberspy
    Commented May 9 at 14:41
  • 1
    As Phil says, it's definiltey possible and partner scratch orgs with namespaces are the way to go. Maybe instead of starting with all the packaged metadata, just start with the code & objects to minimise the dependencies involved. May ISVs are still rocking gen 1 because we don't have a choice, but the packaging org is literally used just for that: hitting the uploading button on a package.
    – Matt Lacey
    Commented May 9 at 15:43
  • 1
    Do NOT go the route of using dev orgs. That was the standard before SFDX, and is open to lots of issues (mainly around the orgs getting polluted with cruft that is not part of the package that then causes different behaviour for different developers etc.). These also cannot be namespaced with the package's namespace and you have to implement "namespace twiddling", which is a PITA.
    – Phil W
    Commented May 9 at 17:19
  • 1
    I don't think there's an API for this for 1GP or 2GP managed packages. However, if you have the package installed you can use the Setup UI to list components in the package. You could copy/paste the output into a file and apply some scripting to use this to identify files that are part of the package (it's non-trivial as you need to map labels through to API names).
    – Phil W
    Commented May 10 at 11:10

You must log in to answer this question.

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