feat: typescript support!

[wjhsf]

Details

Very much still a work in progress; opening draft PR to facilitate discussion.

Does this pull request introduce a breaking change?

• 😮‍💨 No, it does not introduce a breaking change.
• 💔 Yes, it does introduce a breaking change.

Does this pull request introduce an observable change?

• 🤞 No, it does not introduce an observable change.
• 🔬 Yes, it does include an observable change.

GUS work item

[nolanlawson]

Our strategy in the past has been that consumers of LWC are responsible for providing something to transform TS into JS (e.g. a Rollup plugin). By the time the code reaches @lwc/compiler, it should already be JS.

[wjhsf]

Seems like babel doesn't need typescript as a peer dependency.

npm i @babel/cli @babel/core @babel/preset-typescript
npm ls typescript # not present

echo 'export const foo: string = 123' > index.ts
echo '{ "presets": ["@babel/preset-typescript"] }' > babel.config.json

npx babel index.ts -o compiled.js # works!
cat compiled.js # export const foo = 123

[wjhsf]

Our strategy in the past has been that consumers of LWC are responsible for providing something to transform TS into JS (e.g. a Rollup plugin). By the time the code reaches @lwc/compiler, it should already be JS.

In the past, we haven't had official support for TypeScript!

[rui-rayqiu]

The similar change was rejected earlier here #3471 (comment). The reasoning is basically "the LWC compiler shouldn't be in charge of transforming the TypeScript source into JavaScript.".

[jmsjtu]

Just to add some more context, we're trying to see how to map the LWC compiler errors back to the source TS files.

For example, if a customer authors something like this in their JS today:

import { LightningElement } from 'lwc';

export default class extends LightningElement {
    @hello world
}

They'll get a red squiggly around @hello world that reads

LWC1102: Invalid 'hello' decorator usage. Supported decorators (api, wire, track) should be imported from "lwc"

This is done in the language server by running transformSync from the OSS compiler, grabbing the source location and emitting it in the vscode editor.

We're trying to see how we can map the errors back to the source file when it's a TS file instead of JS.

Having said that, I don't think we necessarily need to include this in the OSS compiler but maybe we can add it to the language server and pass it to the OSS compiler.

Also, I think if we were to support TS here we'll probably need to adjust @lwc/metadata to handle it too.