3

Long ago, I added a field Type__c to Contact on our production org. Now, I'm using SFDX to develop an unlocked package with code that refers to that custom field, like someContact.Type__c = 'Student'.

With a newly-created scratch org, using force:source:push on this package gives the error

Variable does not exist: Type__c

because the custom field hasn't been defined in the scratch org. That makes sense, and I can fix it by retrieving the metadata for Contact from production and using force:mdapi:deploy to deploy that metadata into the scratch org. Then force:source:push works and my tests run successfully.

The problem comes when I try to create a package version. When I use force:package:version:create I get the Variable does not exist: Type__c error again. The field is defined in both production and the scratch org, so I don't understand "where" the package version is being created such that it doesn't see that field.

Accessing a custom field from an SFDX-based package seems like a pretty common use case, so I have a feeling I'm misunderstanding something basic. Can anyone help me figure out what I'm doing wrong, and offer an approach that works? Thanks very much in advance for your help.

Improve this question
1

The field needs to exist in the package (or a parent package). This means you'd have a file in objects/Contact/fields/Type__c.field-meta.xml that represents the field in question. A package must be a complete replica of the data, including any dependencies.

Improve this answer
7
  • Thanks! That's the approach I took in an earlier attempt. I had converted the Contact metadata to source format, and included that as part of the package under force-app/main/default/objects/. That worked, but with a nasty side-effect: SF now says it will delete the custom fields if I uninstall the package. Worse, I'm unable to install a second package that refers to the custom field using the same technique, as I get an error that Type__c is already defined in another package. How can I work around that? – Jeff Garbers Feb 27 '19 at 20:29
  • @JeffGarbers You use dependencies to manage this. The base package would have the common fields/objects/etc, and dependent packages would add additional metadata. In your example, Type__c would be in a common package A, and two dependent packages B and C with their respective code. – sfdcfox Feb 27 '19 at 20:43
  • Okay, that's a strategy I was thinking about. I still have a Catch-22, though, I think. If I move all the custom fields and objects into package A, I can't install A because there's already an existing package B that "defined" some of those objects. And if I uninstall "B", SF says it'll delete the fields and associated data...!? Thank you again for your help! – Jeff Garbers Feb 27 '19 at 20:47
  • Oh, and: I tried uninstalling my "B" package from a sandbox, just to see if it would actually delete the custom fields it carried. Instead I got an error saying that other parts of SF were using those fields, so I couldn't delete the package. I have a bad feeling I've gotten myself well stuck. – Jeff Garbers Feb 27 '19 at 20:49
  • 1
    @JeffGarbers Nice. You might want to post your own answer with more details. I'd be interested in seeing the exact steps, and I suspect it will help other people. – sfdcfox Mar 4 '19 at 12:35

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.