Support for TypeScript about lightning HOT 8 CLOSED

@thiblahute @Ms2ger @basvanmeurs @clopez

from lightning.

@stenalpjolly what do you mean by "supports by default"? You mean rewrite the lightning project in TypeScript? Why? I do not see a lot of added value over regular ES6 (if this was entirely in ES5, maybe) but feel free to change my mind.

from lightning.

@wouterlucas I don't mean to rewrite everything in TypeScript. We only need to add types, something similar we have in https://github.com/DefinitelyTyped/DefinitelyTyped

from lightning.

Ah, okay that makes sense. I'm clearly oblivious to typescript and didn't know about the DefinitelyTyped concept but that would be a possibility. Though I wonder to what extend dts-gen would be able to generate all the type definitions automatically. If it's within a few hours of work I see no harm to look into it, but if its a major undertaking and since we have no real usage ourselves in typescript at the moment I don't think I can justify spending days on it.

from lightning.

Lightning's architecture doesn't go too well with TypeScript's type definitions, however I understand this could be quite neat addition and definitely worth considering in the future. Right now it's low priority.

from lightning.

Though I wonder to what extend dts-gen would be able to generate all the type definitions automatically.

Very unlikely that this would provide a satisfactory experience. TypeScript's type system is very rich, so there's usually lots of semantic information that cannot be inferred from code automatically. A human needs to author it. TypeScript is excellent at describing legacy APIs that were not designed for type safety, which is partly why it's so popular compared to other JavaScript type checkers.

I don't mean to rewrite everything in TypeScript. We only need to add types, something similar we have in https://github.com/DefinitelyTyped/DefinitelyTyped

We can do it via DefinitelyTyped, but this means @types/wpe-lightning and wpe-lightning would be managed in separate GitHub repos. Where possible it's generally recommended for the package owner to include typings. That way when you add a new API, you can make sure to add the corresponding typings in the same PR.

The mechanics are pretty simple -- we'd add a "typings" field to your package.json that points to some .d.ts files describing the APIs. The .mjs files would not need to change at all.

@g-zachar I might be willing to help out with this. If someone contributed a PR that adds TypeScript typings for wpe-lightning, would you accept it?

from lightning.

Hi @octogonz,

thanks for your input.

My main concern is that 90% of the code written are actually template objects, something like this:

class LiveDemo extends lng.Application {
    static _template() {
        return {
            Header: {
                rect: true, w: 1920, h: 50, color: 0xff005500,
                Title: {
                    x: 50, y: 30, mountY: 0.5, text: { text: 'Header' }
                }
            },
            Content: {
                y: 60,
                MyImage: {
                    x: 100,
                    y: 100,
                    src: "/Lightning/img/LngDocs_LilLightningIdle.png" 
                }
            }
        }
    };
}

So I think the main advantage of TS support would be having type checking/autocomplete on those objects' properties rather than looking them up in the documentation. I'm not sure if TS is designed to handle this sort of customised JS.

I will gladly check on any sort of POC on this if you're willing to contribute.

from lightning.

Implemented in #407. Released in Core 2.7.0

from lightning.