0

Im want to create an org-dependent Unlocked Package, and I have several questions about this.
The package is org dependent because it depends on org metadata that I would prefer not to include in the package.

  • will the unit tests be executed during version creation, just like for a "normal" unlocked package?
  • but then I cannot use the org metadata in the tests, which does not make sense.
  • or is there a way to push the org metadata to the temporary scratch org used by the package version creation?
  • the org metadata not included in the package is a custom sobject definition. Including it would obviously solve my immediate problem - what are the pros and cons of doing this?
2

will the unit tests be executed during version creation, just like for a "normal" unlocked package?

No, they won't:

We don’t calculate code coverage, but we recommend that you ensure the Apex code in your package is well tested.

You also won't be able to have dependencies on other packages (by nature, as dependencies are resolved at install time).

but then I cannot use the org metadata in the tests, which does not make sense. or is there a way to push the org metadata to the temporary scratch org used by the package version creation?

Yes, there is - the feature is in beta. You need Specify Unpackaged Metadata for Package Version Creation Tests.

the org metadata not included in the package is a custom sobject definition. Including it would obviously solve my immediate problem - what are the pros and cons of doing this?

If you're still building an unlocked package, rather than a managed package? I don't see a huge downside, but it's definitely something to evaluate in the context of your larger org packaging strategy - that is, in the context of that strategy, does this sObject belong in this package?

4
  • David: yes it does. But what if the customer org want to change some of the things specified in the sObject's metadata - they will have to modify the package and roll out the new version, right? If I don't include the sObject, their dependency on me would be minimized, in case they might not want to continue doing business with me. – willeg Feb 23 at 17:52
  • 1
    Yes, I think that's definitely an important consideration. If you are delivering functionality to a customer and the customer owns the sObject (it's not part of your delivery), I see the case for using an org-dependent package instead. – David Reed Feb 23 at 17:58
  • David: You mention, in your answer to my original post, the possibility of deploying a managed package: does that mean that the recommended (or at least a possible) way would be to use (2nd Gen) managed packages, even for development work within a given customer org that is done by customer-intern teams? If yes, would in this scenario that managed package count against the limits? – willeg Feb 24 at 12:16
  • I wouldn't use a managed package in this situation myself. Yes, it would count towards limits unless you submitted it to Security Review, which is a prolonged process. – David Reed Feb 24 at 14:22
1

will the unit tests be executed during version creation, just like for a "normal" unlocked package?

No. A this time, org-dependent packages do not enforce code coverage.

but then I cannot use the org metadata in the tests, which does not make sense.

or is there a way to push the org metadata to the temporary scratch org used by the package version creation?

You can specify unpackaged metadata that will be used for tests, but not included in the package.

the org metadata not included in the package is a custom sobject definition. Including it would obviously solve my immediate problem - what are the pros and cons of doing this?

Org-dependent packages are validated on installation. This means shorter package creation times, but if the dependent metadata is renamed or deleted, those packages will become inaccessible. In addition, the extra metadata still needs to be in your repository for deployment.

Unlocked Packages, in contrast, are full packages, and will "never" fail during installation (I presume there are some edge cases, like changing a formula field to a non-formula field, but in general, they won't fail like org-dependent packages can).

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.