Service Worker typings

[jgw96]

TypeScript Version: 2.0.3

Types for Service Workers should be built into the default definitions for TypeScript. There are some good examples out there of Service Worker typings from the community.

[mhegazy]

Since service workers run in their own context, i suppose we need --lib serviceworker (similar to --lib webworker).

Zhengbo Li (@zhengbli) can we update our declaration files to pull in serviceworker spec idl as well

[dolphin-wood]

I think it's necessary to add service worker typings into built-in definitions, though it's still a work-in-progress API.

When I tried to add /// <reference no-default-lib="true"/> directive into service_worker_api to exclude the default lib (like that in lib.webworker.d.ts), I got tons of type missing errors like:

 error TS2304: Cannot find name 'Function'.

So instead I have to use

interface Window extends ServiceWorkerGlobalScope {}

to attach interfaces onto self.

This brings some other problems, eg. I must change the incompatible properties like onmessage into what they are on Window interface:

// expected
interface ServiceWorkerGlobalScope {
    onmessage: (messageevent: ExtendableMessageEvent) => void;
}

// now
interface ServiceWorkerGlobalScope {
    onmessage: (messageevent: MessageEvent) => void;
}

Therefore, I think it would be much better to include service worker typings in default definitions, or, at least there should be a way to make no-default-lib directive act like the built-in ones.

[code-tree]

interface Window extends ServiceWorkerGlobalScope {} isn't even working for me.

Anyone know how I can force TS to change the type of self??

[mhegazy]

Anyone know how I can force TS to change the type of self??

first you need --lib webworker to include the webworker library definition. self is defined as declare var self: WorkerGlobalScope;. so update the declaration of WorkerGlobalScope to get what you want.

[rektide]

I can't vouch for it, but scouting about it looks like this gist is updating pretty regularly. May be a good candidate for TS to adopt?

[michaeljota]

I really don't like this type of comments, but... Any updates here? I mean, this is just a definition file with a proper compiler flag, isn't it? Maybe we won't be writing service workers in Typescript, but Typescript definitions are really important now days in Javascript development, for me at least. :P.

[mhegazy]

PRs welcomed. the files are generated https://github.com/Microsoft/TSJS-lib-generator. I would be happy to help if someone wants to pick this issue up.

[tiernan]

I wrote an updated gist from the one linked above by rektide here: Service Worker Typings to Supplement lib.webworker.d.ts.

It's intended to be included by a triple slash directive in the service worker, and registration scripts. It works well for me using the webworker lib along with es5+. Hope this helps

[caseyhoward]

I feel like I'm completely missing something. I tried a couple of the type definition files and they're pretty much missing everything I need. addEventListener isn't declared to take a callback that takes a ServiceWorkerMessageEvent. And ServiceWorkerMessageEvent doesn't have the properties I'm using (request, waitUntil, respondWith). self is missing everything since it's still defined as a WorkerGlobalScope.

And to further add to my confusion this says that the dom lib now has service worker stuff: https://www.npmjs.com/package/@types/service_worker_api Why would that be? I didn't think there was a DOM inside service workers. Also, I tried it and it didn't work.

Is there something else I need to configure or include somewhere?

[jhpratt]

Pending an update on this, I've just switched my service worker code into vanilla JS. Though types would be great for development, this is a basic failing of TypeScript currently.

[shqld]

I'm addressing the issue like this. Currently works well.

https://gist.github.com/shqld/32df51a4a4ed429f2c76e4e2cfdf6f96#gistcomment-2793376