Using `key` as an `@api` property is a silent no-op

[apapko]

Description

A customer brought up an issue with a public property that never rehydrates.
Issue: ability to decorate a special 'key' property with @api.

playground link: https://playground.lwcjs.org/projects/mY3ddUxFH/4/edit

ex:

// parent.html
<c-child key={childKey}></c-child>

// parent.js
export default class Child extends LightningElement {
     get childKey() {
          return 'key value from parent';
     }
}

// child.js
export default class Child extends LightningElement {
     @api key = 'my key'; 
}

// child.html
<template>
    <h2>key value from parent: {key}</h2>
</template>

[caridy]

This should be a compilation error for now. Can we add this to patch?

[apapko]

@pmdartus and I had few discussions on how to go about this work item since this is a breaking change. I would like to discuss the approach here so we can all agree on the path forward. Here are some options:

1. Add an eslint warning first and give component authors time to fix their code (PR). Then replace this warning with an error.
2. Add eslint error - this will prevent any existing components that violate this rule from being saved - breaking change.
3. Another idea from @kevinv11n and @pmdartus is same as feat(compat): Moving push, unshift and concat to xproxy prototype #2 but wait on enforcing the rule on the next platform release by checking a component version - this requires adding an infra to accommodate that.

I personally prefer staring with a warning to minimize number of complaints. However, i can also see the benefit of not waiting until more customers make this mistake and just make a breaking change with a two week notice/announcement.

@Gr8Gatsby @caridy @diervo @ekashida what are your thoughts?

[caridy]

What do you mean that this is a breaking change? do you mean that if you have @api key it works? It doesn't work today, it doesn't throw either, but the code is faulty from day 0. Did we investigate if anyone is using @api key or @api get key` in core? I think this is sufficiently constrained that we can probably pull the trigger if we don't find any decorated field or accessor called key in 218.

[apapko]

@caridy that is correct, you can have @api key; property in your class without an error ( see playground link in the description ). I have not ran transmogrify against core, but off core teams can be using this syntax as well, which will be a breaking change.

[pmdartus]

The main issue here is not Core components but database components. If a customer was able to save a component in the DB we should be able to recompile it, otherwise, their application will be broken until the code saved in the DB is fixed.

[nolanlawson]

The core issue here is that key is not valid as an @api property. (Repro

You can declare @api key, but the consumer can't pass the key prop to it because key is actually a special LWC directive and not a prop/attribute.

We have a list rendering reform proposal to add lwc:key which is related: salesforce/lwc-rfcs#84