You should be able to access the decorator through member.meta which is of the following type:

interface LitElementPropertyConfig {
    type?: SimpleType | string;
    attribute?: string | boolean;
    node?: {
        type?: Node;
        attribute?: Node;
        decorator?: CallExpression;
    };
    hasConverter?: boolean;
    default?: unknown;
    reflect?: boolean;
}

So you would be able to check for member.meta?.node?.decorator?.identifier.text to get the name of the decorator 👍

i updated it, didn't realise you could access the typescript node there.

remember this is based on 1.2.0 too FYI

edit: it works, but i used member.node rather than member.meta.node.decorator. is there any particular reason you have both? this way we can tolerate multiple decorators and still match...

member.node is the node where the property/attribute was found/emitted. This could be a PropertyDeclaration, ExpressionStatement, PropertyAssignment, eg. depending on how it was found.

member.meta contains specific metadata of the analysis of the property/attribute. This data-structure right now only contains lit-specific information, but I plan that this data-structure in the future could depend on the specific WCA-flavor that emitted it. For example, if there was to be created a Stencil-specific WCA-flavor, the meta-field would contain Stencil-specific data.

member.meta.node.decorator will always point to the decorator that contains LitElement-specific metadata which was found during the analysis of the PropertyDeclaration. The decorator would always be either a property- or internalProperty-CallExpression and other decorators would be ignored. If there are multiple decorators, this would still be either the property or internalProperty decorator. The loop over member.node.decorators has already been done in WCA and the decorator of interrest would be assigned to member.meta.node.decorator, so you can trust the text property of that node to be internalProperty when that's the case.

i updated it. just wasn't aware what the meta node was so thanks for the explanation. i do wonder what'll happen when one day multiple decorators might become a thing in lit, though. maybe it should be an array rather than assuming there will always be just one "useful one" per property.