Component compiles incorrectly for `export { ... as default }` ESM syntax about lwc HOT 6 OPEN

@wjhsf We can't always safely change the ordering, because it matters in certain cases. For example:

export default Foo
class Foo {}

^ This is a syntax error (Cannot access 'Foo' before initialization). (Some minifiers like Terser and SWC will "helpfully" fix it for you though. 🙃)

In particular, when we compile could we just change export { Foo as default } to export default class Foo {} or would that cause side effects?

Maybe, but I wonder if it's better to just leave things alone, since otherwise we could cause other unforeseen problems.

from lwc.

This issue has been linked to a new work item: W-15135580

from lwc.

I think to solve this, a bare-minimum solution would be:

1. Detect usage of export { Foo as default }
2. Check the same JS module to see if there is a class Foo extends LightningElement {}

(The solution would likely be in @lwc/babel-plugin-component.)

I think other, exotic patterns are not strictly necessary to support:

// const Foo
const Foo = class extends LightningElement {}
export { Foo as default }

// Foo imported from elsewhere
import { Foo } from './elsewhere.js'
export { Foo as default }

// really zany
const Foo = (() => { return true && class extends LightningElement {} })()
export { Foo as default }

from lwc.

We can probably also support some other simple patterns:

class Foo extends LightningElement {}

export default Foo

Maybe even:

const Foo = class extends LightningElement {}

export default Foo

from lwc.

What are the behavioral differences (in ESM land, outside the LWC context) between export default const Foo = ... vs export { default as Foo }? In particular, when we compile could we just change export { Foo as default } to export default class Foo {} or would that cause side effects?

from lwc.

Hi @nolanlawson i would like to contribute and help fix more bugs please let me know where i can be helpful.

from lwc.