When creating an unlocked, second-generation package for a new Lightning Web Component, how should you include the requirement for a custom field to exist if that field already exists in the Production Org?
To date, almost all of our Salesforce changes and development has been done declaratively in the Production org. We are now looking to adopt a more source-driven, package based development workflow.
Our first goal is to deploy a rudimentary Lightning Web Component that can display an image on an
Asset's record page. The URL for these images is stored in a custom field that was created awhile back:
Asset.Photo_URL__c - URL(255)
import PHOTO_FIELD from "@salesforce/schema/Asset.Photo_URL__c";
If we attempt to create a version of our package, we (rightly so) get an error:
> sfdx force:package:version:create ...
Invalid reference Asset.Photo_URL__c of type sobjectField in file xxx.js
In most of the tutorials and documentation we've read, the recommended steps are to spin up a scratch org, declaratively create the custom field and then pull the changes back down and into our project. If I do that in a scratch org, then I get:
STATE FULL NAME TYPE
─────── ────────────────── ───────────
Created Asset.Photo_URL__c CustomField
Created Asset-Asset Layout Layout
Created Admin Profile
- Can we just delete the Admin Profile and the Asset Layout because we don't have a need for those in this package?
1.B (Deleting doesn't seem to make sense because they'll just get pulled back down. Is this when
.forceignore should be used?)
- Do we leave the
Photo_URL__c.field-meta.xmlfile in our project and include that in our package? If so, how do we make sure that our metadata description of that field does not conflict with the one in Production? (ex: Differences in
2.B (Is the answer that we should be copying over
Photo_URL__c.field-meta.xml from Production and not from the Scratch Org?)
- If we are creating several different, but discrete, web components that all require this custom
Photo_URLfield, do we include
Photo_URL__c.field-meta.xmlin each package? If so, how do you make sure that those each package's copy of that file, which is now stored in source control, doesn't get out of sync with the Production copy's?
I should add that if a package is introducing a new custom Object or field, then it makes total sense that the package needs to include the relevant Metadata. I'm just a bit confused how to handle packaging when the relevant dependencies already exist.