0

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)

The component's Javascript file imports the field as such:

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:

sfdx force:source:pull

STATE   FULL NAME          TYPE       
─────── ────────────────── ───────────
Created Asset.Photo_URL__c CustomField
Created Asset-Asset Layout Layout     
Created Admin              Profile    

Questions:

  1. 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?)

  1. Do we leave the Photo_URL__c.field-meta.xml file 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 type, required or trackHistory?)

2.B (Is the answer that we should be copying overPhoto_URL__c.field-meta.xml from Production and not from the Scratch Org?)

  1. If we are creating several different, but discrete, web components that all require this custom Photo_URL field, do we include Photo_URL__c.field-meta.xml in 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.

4
  • 1
    You could also have created a base unlocked package that contains common metadata, install that in prod, and then create dependencies for each component unlocked package that needs the base metadata. I've done this several layers deep, and it works pretty well.
    – sfdcfox
    Commented Feb 23, 2023 at 4:03
  • So create something like an Asset Expansion Pack unlocked package that only contains metadata changes. Then create separate unlocked packages for each component that depend on the Asset Expansion Pack package. Kind of an inheritance graph of packages based on shared metadata.
    – kennyc
    Commented Feb 23, 2023 at 5:04
  • Very eloquently stated. There's also documentation about how to move metadata between unlocked packages, so there's no real risk if you make bad design decisions. Feel free to experiment with it.
    – sfdcfox
    Commented Feb 23, 2023 at 14:27
  • Based on the SFDX Documentation for Org-Dependent Unlocked Packages, it looks like such packages do not support package dependencies.
    – kennyc
    Commented Feb 24, 2023 at 18:22

1 Answer 1

2

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?

Make the package org-dependent. This will allow your component reference to the field to be satisfied at installation time in your production org, rather than during the build of the package.

Can we just delete the Admin Profile and the Asset Layout because we don't have a need for those in this package?

Yes

1.B (Deleting doesn't seem to make sense because they'll just get pulled back down. Is this when .forceignore should be used?)

Yes

Do we leave the Photo_URL__c.field-meta.xml file 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 type, required or trackHistory?)

Generally, you don't - until you're ready to make that component a full-on piece of this package. You make it an org-dependent package, as above.

You must log in to answer this question.

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