2

I feel like I'm missing something basic here..

My scenario:

  • Using SFDX project, NOT using scratch orgs (for reasons), retrieving and deploying to a dev sandbox.

  • Currently have a managed package installed on the sandbox (a Docusign package from the appExchange)

  • Said managed package metadata is not part of my local SFDX project (this is the problem I'm trying to solve)

  • Have written an apex class in my local SFDX project that references a class+method that is part of this Docusign package.

  • This is giving me a reference error in VS Code, as the project does not see the Docusign apex class

I tried SFDX force:source:retrieve -m ApexClass, but that didn't pull the classes in the package

Specifying the class name didn't help, as it wasn't found.

I also tried: SFDX force:source:retrieve -n "DocuSignPkgName"... which retrieves the pkg successfully, sure, but puts it in its own directory structure rather than integrating it into the project folder. This doesn't help me address the reference error I'm getting.

Am I not supposed to be able to include managed package components in my SFDX project? If not, how are we supposed to effectively develop against package components?

Edit to respond to SFDCFox

To give your solution a try, here's how I updated my sfdx-project.json file:

From

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://test.salesforce.com",
  "sourceApiVersion": "45.0"
}

To

{
  "namespace": "",
  "sfdcLoginUrl": "https://test.salesforce.com",
  "sourceApiVersion": "45.0",

  "packageDirectories": [
    {
      "package": "unlockedPackageTest",
      "versionNumber": "0.1",
      "path": "force-app",
      "default": true,
      "dependencies": [{
          "package": "Docusign Apps Launcher@2.3.1"
        }]
    }
  ],
  "packageAliases": {
    "Docusign Apps Launcher@2.3.1": "04t3u000003X3cuAAC"
  }
}

Now I'm not clear, but it seems like with this change I've just A) declared that my sfdx project is now an unlocked package with a name and version number, and B) claimed that my package has a dependency on the installed Docusign package

However, I'm not sure what to do with this change to my json file. I tried another SFDX force:source:retrieve on the project to see if it would now pull in the depended-upon package metadata, but it did not. Plus, the dependency error is still showing up in the Problems tab of my homemade class in VS Code, and in the deployment errors if I try to push to my sandbox.

I have confirmed that the apex class and its method that I am referencing in my own code is Global, and that if I were to recreate my class directly in sandbox via dev console, the reference error wouldn't appear.

The problem I'm trying to solve seems to be purely getting VSCode + SFDX to retrieve and acknowledge this dependency.

  • I'm having the same problem, but adding the dependency to my sfdx-project.json file doesn't resolve the issue. Are there any example projects that illustrate this scenario (trying to reference Apex classes in a managed package) that I can use as a template to figure out what I'm obviously not understanding? – jerhewet Jun 11 at 15:17
  • @jerhewet I had assumed the managed package's apex wasn't being pulled into my SFDX project, but it turns out I was incorrect, and the reason I was getting the error wasn't because my project couldn't find the Apex class + method I was calling, but rather because I was passing the wrong var type to it. You might want to double check that. – smohyee Jun 12 at 16:59
  • As far as I can tell I'm doing everything correctly (virtually the same scenario you had), but the dependency that's available from the SF Developers Console (NS.TheApexClassname) in my sandbox is missing from my VSCode-SFDX project. There are so many possible/potential configuration settings I have the sinking feeling I'm missing something -- especially if it's working for others. – jerhewet Jun 13 at 21:06
2

You can't retrieve the contents of managed package classes via the API, but presumably, if you're trying to make an Unlocked Package, you simply forgot to specify the dependency:

{
  "packageDirectories": [
    {
      "path": "force-app",
      "package": "myPackageName",
      "versionName": "ver 0.1",
      "definitionFile": "config/features.json",
      "versionNumber": "0.1.0.NEXT",
      "default": true,
      "dependencies": [
        {
          "package": "docusign@X.Y.Z"
        }
      ]
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "47.0",
  "packageAliases": {
    "docusign@X.Y.Z": "04t..............."
  }
}

To get the 04t value, use:

sfdx force:package:installed:list

In the above JSON, replace X.Y.Z with the version number provided from the output of this install list.

| improve this answer | |
  • Thanks... I'm not creating an unlocked package, rather I've got a standalone homemade class+trigger that references both an object and a class that is part of this managed Docusign Package. I've created these in my local VS Code sfdx project, but because the managed package's metadata isn't pulled into my SFDX project, the references aren't recognized and causing deployments to fail. – smohyee May 19 at 20:04
  • sfdx force:package:installed:list does show the desired managed package in the list, so I will try modifying my sfdx-project.json file... however, I was under the impression that file is only used when working with scratch orgs? I'll give it a shot but I'm deploying/retrieving from a dev sandbox – smohyee May 19 at 20:05
  • @smohyee If the packages are presently installed, it shouldn't fail. The Scratch Org Definition File is used both for creating Scratch Orgs and creating Unlocked Packages. Are you sure you're deploying to the correct org? Are the classes and methods global? Anything that you can save in the Developer Console should also work in VS Code. – sfdcfox May 19 at 20:27
  • I updated my post to share the changes I made to my sfdx-project.json, if you could please take a look and let me know if I understood it right. Also, am I correct that you are saying that I NEED to make my project an unlocked package to involve a dependency like this? What if I just wanted to write a standalone class that references a class sitting in an installed package? I wouldn't need to mess with packaging if I was doing this in dev console, I'm pretty sure – smohyee May 19 at 20:53
  • 1
    @smohyee Oh, lol, sometimes it's the easy things that trip us up. – sfdcfox May 19 at 22:42

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.