fix: runtime decorators

[johnjenkins]

With the introduction of #3614, Stencil started removing @State / @Prop class fields during transpilation only to re-add them later, during bundling, as constructor initialised values.

This was due to a new behaviour with JS classes, given tsconfig:

target: 'es2022'

A typical Stencil component:

@Component({
  tag: 'cmp-a'
})
export class MyComponent {
  @Prop() prop1 = 'value1';
}

Compiled output went from:

class MyComponent {
   constructor() {
     this.prop1 = 'value1';
  }
}

to:

class MyComponent {
  prop1 = 'value1';
  // ^^ statically initialised, class fields override Stencil's accessors originally set on the prototype...
  // no-more keeping Element / class instance in-sync. No-more re-renders :(( 

 // ** Stencil, therefore started stripping them out then
// re-adding them to the CTOR like the good old days **
}

A side-effect this behaviour is user-defined, run-time decorators targeting @State / @Prop would be stripped out during transpilation and break expected behaviour.

Within the attached issue, the Stencil dev (at-the-time) outlined the reason for the broken behaviour and also stated their reticence to fix it; a preference to move away from Stencil's statically-analysed decorators for real-life, run-time decorators. Getting class fields working again within Stencil would just be layering-on more tech-debt when the ultimate goal should be to remove it.

Whilst I am completely on-board with the dev's reasoning - the more magic that Stencil can remove, the more Stencil can 'get-out-of-the-way' of native behaviour and expectations - the better. However, I also believe:

1. Something popularly used by the user community probably shouldn't be broken for over 2 years
2. Messing around with the compiler's default output is Stencil 'getting-in-the-way'
3. The undertaking to re-write Stencil - transitioning to run-time decorators whilst taking into account experimentalDecorators and / or the not-yet supported ECMA compliant decorators - will not be small and will take time.

What is the current behavior?

GitHub Issue Number: #3831

What is the new behavior?

Fixes #3831

• Re-allows Stencil decorated class members (thank you @louis-bompart ! - fix(decorator): preserve stencil decorated class members #4772 ) to flow through transpilation and stops their re-addition during bundling.
• Re-wires the @State / @Prop decorated fields with the original Stencil get / set during run-time only if it finds modern class static initialisers (during build time we detect them and switch on a new modernPropertyDecls build flag)

Documentation

Does this introduce a breaking change?

• Yes
• No

Testing

• New unit tests for the addition of a new build time flag modernPropertyDecls
• New component tests for target: "es2022" combined with dist, dist-custom-elements and run-time decorators

Other information

[christian-bromann]

However, I also believe:

💯 agree here.

[christian-bromann]

Awesome change set 🙌 thanks a lot!

Could we add some docs for custom decorator support? I would suggest to add a Custom Decorator section here and show case a simple real world example. What do you think?

[johnjenkins]

@christian-bromann when testing different run-time decorator patterns someone might use with Stencil decorated members, I found more examples of Stencil 'getting-in-the-way' ... not broken - just not particularly flexible or useful.

So before writing docs with examples, I'm gonna submit one more MR which will make user-land decorators 100% more useful in Stencil. Hope that's cool!

[christian-bromann]

Hope that's cool!

💯 cool!