Workbox: Typescript Support?

[gauntface]

Do we want it?

https://github.com/GoogleChrome/sw-toolbox/issues/183

[mullens]

Are we considering writing the libraries in TypeScript? Good argument for it and discussion about it here: https://news.ycombinator.com/item?id=11296491

Adding typings feels like a necessity regardless. It's a huge help to TypeScript users.

[gauntface]

@mullens no this would just be adding the typings. Writing in TypeScript results is a road block for contributors that I'm not sure is worth it.

[addyosmani]

My two cents: TypeScript's benefit is developer tools providing a better DX through type checking for providing errors quickly and TS being integrated into lots of IDEs. Although support for fast incremental type checking is a nice to have, Fizzle is still early on in our open-source journey and still need to build a healthy, low-friction to contribute community around our libraries. Anything we can do to keep the bar for contributions low helps reach this goal.

My take is that once we do have a vibrant community around the libraries (we can get there), it'll make sense to reconsider better TS support for the various libraries in the monorepo.

[ithinkihaveacat]

Typings also don't need to be integrated into the package itself for developers to have a smooth experience using sw-helpers with TS code--the TS tooling is pretty good at merging together a package with its associated (but separately-distributed) types. (VS Code, for example, will automatically acquire types that are published to DefinitivelyTyped.)

(That is, the main problem is producing and maintaining the *.d.ts file itself (which could be done by someone completely unrelated to this project), not deciding whether the typings should be part of the sw-helpers package or not.)

[gauntface]

@ithinkihaveacat do you have any idea how the developer can grab the typings from an external package and pull them together? Would be handy to have an example of another project doing this already.

[ithinkihaveacat]

@gauntface Here's an example from jupyterlab.

In this case jupyterlab (which is written in TS) has a dependency on a few different JS packages, some of which have typings referenced from the package itself, and some of which have "external" typings. (The ones that need external typings are those with dependencies matching @types/*.)

So for example es6-promise has typings defined in its own package.json (so no dependency on @types/es6-promise needed) whereas semver needs the associated @types/semver dependency, because its package.json is missing a typings or types key. Both VS Code and the tsc compiler understand the @types/* system.

If someone created typings for sw-helpers and published them to DefinitivelyTyped, then developers could use these typings by adding a dev dependency of @types/sw-helpers.

(And when editing JS, VS Code will even automatically acquire types; if you have a package.json that lists lodash, for example, then var _ = require('lodash') in a JS file get you completions on _: VS Code will retrieve the typings automatically. For some reason you need to be more explicit when writing TS.)

[gauntface]

Gonna close this until someone requests it.

[josephliccini]

Requesting it :)

Maybe once V3 goes stable. I might be able to help on this one since our group is TypeScript exclusively

[Guymestef]

Sample of type def for workbox-window

declare module 'workbox-window' {
    class Workbox {
        constructor(scriptURL: string, registerOptions?: object);

        register(immediate?: boolean): Promise<any>;
        active(): Promise<ServiceWorker>;
        controlling(): Promise<ServiceWorker>;
        getSW(): Promise<ServiceWorker>;
        messageSW(data: object): Promise<object>;

        addEventListener(event: 'message', callback: (data: IWorkboxEventMessage) => void): void;
        addEventListener(event: 'installed', callback: (data: IWorkboxEvent) => void): void;
        addEventListener(event: 'waiting', callback: (data: IWorkboxEventWaiting) => void): void;
        addEventListener(event: 'controlling', callback: (data: IWorkboxEvent) => void): void;
        addEventListener(event: 'activated', callback: (data: IWorkboxEvent) => void): void;
        addEventListener(event: 'redundant', callback: (data: IWorkboxEvent) => void): void;
        addEventListener(event: 'externalinstalled', callback: (data: IWorkboxEventExternal) => void): void;
        addEventListener(event: 'externalwaiting', callback: (data: IWorkboxEventExternal) => void): void;
        addEventListener(event: 'externalactivated', callback: (data: IWorkboxEventExternal) => void): void;
    }

    type WorkboxEvent = 'message' | 'installed' | 'waiting' | 'controlling' | 'activated' | 'redundant' | 'externalinstalled' | 'externalwaiting' | 'externalactivated';

    interface IWorkboxEventBase {
        originalEvent: Event;
        type: WorkboxEvent;
        target: Workbox;
    }

    interface IWorkboxEventMessage extends IWorkboxEventBase {
        data: any;
    }

    interface IWorkboxEvent extends IWorkboxEventBase {
        sw: ServiceWorker;
        isUpdate: boolean|undefined;
    }

    interface IWorkboxEventWaiting extends IWorkboxEvent {
        wasWaitingBeforeRegister: boolean|undefined;
    }

    interface IWorkboxEventExternal extends IWorkboxEventBase {
        sw: ServiceWorker;
    }
}