4

A customer of mine accidentally added a Sales Cloud dependency to his managed packages. He started using an open source library referencing Pricebook.SObjectType and didn't see this was added during upload. Now his subscribers were unable to upgrade the package in some cases.

Is there a way to test this early in the process. Ideas I had were an XPath PMD rule that detect the use of UNWANTED.SObjectType in code, but realized this is easy to bypass.

Could this be checked using an Apex test and some APIs like the Dependency or Metadata API?

Improve this question
3
  • 2
    I assume this is a 1GP, since otherwise dependencies are not automatically added. Our process is to always generate a beta release and ensure that this is installable on appropriately shaped and licensed orgs. It's very manual, but excellent for catching most nasty issues like this. I would, however, be interested to see if there is some form of automation we can leverage.
    – Phil W
    Commented May 14, 2021 at 8:29
  • Yes 1GP. And we also proposed that to the Customer but he said he wants to catch it way earlier in the process. E.g. during nightly test runs or even locally using PMD checking some Profiles or Classes.
    – Robert Sösemann
    Commented May 14, 2021 at 8:42
  • 2
    Could they not do nightly deploys to scratch orgs (that only has base set of features), i.e. kind of re-create what 2GP packaging process does, for 1GP? Deployment failure would highlight the issue.
    – Phil Hawthorn
    Commented May 14, 2021 at 9:51

1 Answer 1

Reset to default
2

In 1GMP, the only way to ensure that you haven't created a dependency is to check the View Dependencies button before uploading. This is found on the package's detail page. If you now have a Released version of this package, the dependency is non-trivial to remove. You have to have anyone who's upgraded to uninstall entirely, have Partner Support roll back the version to a Beta, fix the dependency problem, and finally upload a new version without it.

This is one of the reasons why moving to a 2GMP is recommended if possible, as you must explicitly declare your dependencies in a 2GMP, so you can't accidentally create a dependency. However, 2GMP still has some limitations, so not everyone can move to it yet.

Improve this answer
4
  • 1
    Removing dependency in 2GP is just as difficult as in 1GP since you have to have folks uninstall otherwise they are then on a separate branch in your version tree (and do you really want to somehow keep both branches going)? Let's wait and see what SF does about metadata deletion in 2GP, when they get there...
    – Phil W
    Commented May 20, 2021 at 21:23
  • 2
    @PhilW The main point, which I think was unclear here, is that in 2GP, you must explicitly create the dependency; each package is fully validated against its claimed dependencies in sfdx-project.json, so you can't possibly accidentally create a dependency.
    – sfdcfox ♦
    Commented May 20, 2021 at 21:27
  • 1
    That's as far as I understand it mostly true. It's dependent on the OOTB shape of the build scratch org. In certain edge cases it's possible to create a dependency on a feature that is part of that OOTB shape but is not available in some customer orgs. Not particularly likely, but it is possible.
    – David Reed
    Commented May 20, 2021 at 21:43
  • 1
    It is sometimes possible to remove a dependency from a 1GP release without reverting the package to a beta but it's highly fact-specific (based on the manageability rules of the components that create the dependency).
    – David Reed
    Commented May 20, 2021 at 21:44

You must log in to answer this question.

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