LWC on platform behaves odd according to ECMAScript standard

Question

I found several unexpected behaviors while writing Lightning web components.

1. Cannot have local name on imported decorator

import { LightningElement, api as a } from "lwc";

export default class MyComp1 extends LightningElement {
  @a
  prop1;
}

// => bad result: TypeError: Cannot read property 'referencePaths' of undefined 

2. Cannot re-assign the imported wiring function to variable

import { LightningElement, api, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';
import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';

// re-assign the reference to another var
const getRec = getRecord;

export default class Record extends LightningElement {
  @api 
  recordId;

  @wire(getRec, { recordId: '$recordId', fields: [ACCOUNT_NAME_FIELD] })
  record;
}

// =>  SyntaxError: /home/sfdc/tools/lwc/1.1.13-224.8/myComp1.js: LWC1098: @wire expects a function identifier to be imported as first parameter.

When considering ECMA standard, both cases should behave identical to the officially provided examples.

Maybe the platform compiler needs this restriction to detect dependency in static analysis, but is there any document that clearly says the LWC JS has the part against the spec ?

It may seems subtle and can be easily avoided, but many tools are assuming the output would be compliant to the ECMA standard so these simple renaming may happen when doing pre-processing the source code.

Answer 1

The compiler does a lot of "magic" to ensure compatibility and Locker API consistency across all browsers. For example, decorators are experimental, so to provide a consistent experience, it applies a patch to make them work. As a side effect of that example quirk, the only decorators allowed are @api, @track, and @wire. You cannot write a custom decorator at this point.

At some point, all of this will be supported in native code, thus reducing the footprint of Aura/LWC runtime. However, LWC isn't there yet, as it has to be compatible with existing browsers. I don't know of any documentation that goes out of the way to explain limitations that are this specific. However, there's a pretty easy solution. If you don't find a particular syntax in the documentation, it is probably not allowed, or at least caution is advised.

Here's the documentation describing compatibility. Note that it doesn't have limitations such as the one you've noticed. This is not a permanent situation, but for now, you should presume that the Salesforce documentation perfectly describes what the platform supports, while ES6 describes what the future browser support should look like. After IE 11 Extended Support sunsets at the end of the year 2020, there should be a lot more ES6 compatibility, since they will no longer need to depend on patches/transpiling.