Skip to content
Home » Blog » LWC in Purgatory

LWC in Purgatory

If you are delivering your SFDX projects using packaging you are likely aware of the challenges with moving metadata artefacts from one package to another. Particularly when moving up the dependency hierarchy. 

There is this very neat “trick” for Unlocked Packages where you can temporarily remove metadata from a package via Setup > Installed Packages > View Components. You are only dissociating the metadata from the package without deleting it, allowing the next upgrade of the refactored parent package to assume ownership of the metadata again. And it even works with Unlocked Packages with Namespace. 

This is often easier than having to do a 2-step package upgrade where you first release the components from the lower-down package and then later upgrade the higher-up package. And you have to use the –upgrade-type argument carefully. 

Well watch out when trying to move an LWC Component Bundle which calls Apex. You’ll be aware of the limitation that both the @AuraEnabled method and the calling LWC must be in the same package. If you remove the Apex-calling LWC Component Bundle from the package it will still be in the Namespace but not in a package. Therefore it is not in the same package as the Apex and it will stop working. Unfortunately even the subsequent package upgrade which is attempting to assume ownership of both the Class and LWC Component Bundle will fail with this error:

1) LightningComponentBundle(xxx) Apex action method yyy.zzz with public access modifier must be in the same package with caller ‘markup://xxx:xxx’

You will never again recover this component. Only option is to actually delete it, which may not be an option for you with it being tied in many dependencies (which is the reason you went with this approach in the first place). So far the only way out I found was to rename the LWC Component Bundle. So yea, essentially drop it and create a new one.

This really only affects you if you use namespaces in your Unlocked Packages though. If you want to try this out I’ve prepared a little demo here.

Bonus: you can’t move Custom Labels this way either. This time because there is no way (that I found) to remove it from the Package in the Subscriber Org. It does not show up on the list of package components.

Other Traps

Accidental Permissions

Apr 26, 202402 min read

Blowing the “Single Profile” approach out of the water When you install a package from AppExchange via the browser you get to choose whether to Install it for All Users, Only Admins, Specific Profiles or no-one. This really means if you want to grant full access to Classes, Pages, Fields…

UoW and SObject Instances

Oct 28, 202314 min read

I previously talked about the need to be careful about how you register records as dirty with the Apex Common’s Unit of Work. There is another little gotcha to be ware of I recently ran into. Though when it does happen to you then you are probably doing something you…

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x