0

Context

We have an unlocked package with a namespace (call it XYZ) that contains public @AuraEnabled methods in a number of our Apex classes. When developers need to work on new features for the package, they create scratch orgs with the same XYZ namespace and install the unlocked package. We are trying to create a net new LWC that imports the public @AuraEnabled methods from packaged Apex classes into its JavaScript controller.

Problem

When deploying the LWC, the deployment fails:

  • the Apex action method CLASS_NAME.METHOD_NAME with public access modifier must be in the same package with caller 'markup://XYZ:newLWC'

This does make sense as the methods we are referencing are not annotated as @NamespaceAccessible. However, it creates extra work for our developers who have to manually update Apex classes marking every dependency of the imported method(s) as global in their scratch orgs before they can start their development work.

Is there a best practice approach for development that covers this use case? We have the option to annotate these methods as namespace accessible, which is definitely preferable to declaring classes and methods as global, but it isn't a true requirement for our use case. I've seen that tools like CumulusCI offer functionality for namespace injection during deployments and would be open to exploring the use of this type of tool if it can solve this problem.

5
  • If these new LWCs will become part of this same unlocked package, you should be deploying the unpackaged metadata to the scratch org, not installing the unlocked package.
    – Phil W
    Sep 7 at 20:23
  • @PhilW Yes, the components will ultimately be packaged and developing against unpackaged metadata would prevent this. There are lots of fully qualified namespace references within our codebase so part of why we went with the unlocked package was to avoid having to strip all those references off of files as a pre-deployment step to scratch orgs. The code base is quite large and the transform/deploy process took longer than installing an unlocked package.
    – AJW
    Sep 7 at 21:00
  • "Developing against unpackaged metadata would prevent [packaging]" is plain wrong. I work for an ISV and develop large 1GP and 2GP packages. We create namespaced scratch orgs and push our source formatted sfdx package metadata (for that namespace) to the scratch org. The scenario where we must install packages is when we have inter-package dependencies that are for different namespaces.
    – Phil W
    Sep 7 at 21:39
  • @PhilW I think you misinterpreted what I was saying, . I am agreeing with you, developing against unpackaged metadata would prevent the issue of trying to reference packaged metadata with a namespace, it has nothing to do with the packaging process. If the best approach is to deploy our metadata in its raw form to scratch orgs that is a sufficient answer for me.
    – AJW
    Sep 8 at 12:05
  • Ah, OK. Apologies. Yes, you should simply deploy the package's existing metadata directly to the scratch org where you then continue with your development for that package.
    – Phil W
    Sep 8 at 12:33

1 Answer 1

2

Package development with scratch orgs is done by:

  1. Creating the scratch org with the package's namespace (there are some teams who don't do this namespacing, though I don't agree with that approach).
    1. Optionally, and if required, installing dependency packages for this "package".
  2. Deploying the package's metadata from your local file system (a VCS checkout) directly to the scratch org.
  3. Creating additional metadata:
    1. Directly in your local file system, in the package's directory structure, and pushing to the scratch org or
    2. In the scratch org, and pulling down to local file system and ensuring it's in the package's directory structure.
  4. Adding your new metadata to VCS and committing it (after relevant testing).
  5. Packaging (you may use a beta version first, test and then "promote"):
    1. (2GP) Running package version creation CLI commands or
    2. (1GP) Pushing all the updated and new metadata to the packaging/patch org and uploading a new version.

The metadata should definitely not be "installed" as part of a package into the scratch org for multiple reasons, not least of which is the issue you have hit.

1
  • Thank you @PhilW!
    – AJW
    Sep 8 at 13:00

You must log in to answer this question.

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