5

I have a managed package with an LWC component. I need to enhance this LWC in a patch to allow it to receive some additional data during its initialization, which is done using an @wire.

The data itself comes from JSON-based configuration data held in a custom metadata type instance. I need to add an extra parameter to be sent back in the wire response to allow the LWC to change its behaviour based on that parameter. Effectively, I need to add the following to my data object that is returned to the LWC in the wire:

public class LWCResponse {
    ...

    @AuraEnabled
    public String linkNavigation { get; set; }
}

What I'm not sure about is whether this is something that can be added to a managed package as part of a patch release since it isn't possible to add new "components" to a managed package in a patch.

The problem is in identifying exactly what a "component" is. The documentation doesn't mention an @AuraEnabled method or property as a component, but I want to be sure before we shoot ourselves in the foot by taking this approach.

Anyone got a definitive answer as to whether an @AuraEnabled property can be added in a patch?

5

I dont think you have anything to lose by creating a patch org and trying.

Per this doc, you can't do the following things

You can’t add package components.

You can’t delete existing package components.

API and dynamic Apex access controls can’t change for the package.

No deprecation of any Apex code.

You can’t add new Apex class relationships, such as extends.

You can’t add Apex access modifiers, such as virtual or global.

You can’t add new web services.

You can’t add feature dependencies.

If @AuraEnabled is considered an "access modifier" or an "Access control", you're out of luck, but I can't find any documentation that calls it that way, everything calls it an "annotation".

This is assuming your method is already public and you just want to make sure you enable it for aura. If it's private, then you're out of luck too.

| improve this answer | |
  • 1
    Hey @SebastianKessel, the thing to lose is wasted time if we can't do it ;) Yeah, I guess we can do a minimal change only to try it out, though would not want to upload a new patch release with that minimal change in it if it turns out to be allowed... – Phil W Apr 6 at 15:56
  • Well, you can certainly do it in a minor release. But before I do that, I'd try a patch org. That would also allow you to push upgrade, so there's that. :) – Sebastian Kessel Apr 6 at 15:57
  • As to your edit, it's not strictly a new method, just a new property (and if we absolutely can't use a property - it would be a new one - we have found that public attributes work with AuraEnabled in most cases despite not being covered in the documentation... – Phil W Apr 6 at 15:58
  • 2
    Yup, I know we can do it in a "minor" (or "major") release, but this is something we need to do in a patch release since we can't wait the 2 months for our next "minor" release before adding this functionality for a customer. – Phil W Apr 6 at 15:59
  • 2
    I've found we can add whole new nested classes, for example, with public attributes (patches only disallow global/virtual add or remove). This is more like REST API changes... I guess if no one else has an answer we'll have to try it out for ourselves and then provide feedback here. I will, in the meantime, upvote your answer for the useful link to the patch "don'ts list". – Phil W Apr 6 at 16:08

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.