npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

node-service-worker

v2.1.2

Published

An attempt at replicating a Service Worker environment inside Node. Uses:

Downloads

37

Readme

node-service-worker

An attempt at replicating a Service Worker environment inside Node. Uses:

Install with:

npm install node-service-worker

Why would you make such an abomination?

First and foremost, as an experiment. But mostly to see if we can centralise all page rendering inside a service worker. It will mean super-fast client loads, and if we can replicate the environment well enough in Node it means we can pre-populate pages on (e.g.) S3 for users when they first load.

What works?

Very little. This is a project I'm adding to as and when I need more functionality. Right now you can create a service worker like so:

const {ServiceWorker} = require('node-service-worker');

const sw = new ServiceWorker({
    scriptURL: 'https://localhost/sw.js',
    scope: 'http://localhost', // Primarily to resolve relative URLs
    contents: 'console.log("hi");' // The JS of the service worker
})

You'll then want to install and activate your worker. For this we use ExtendableEvents, which will wait until a Promise has executed, if waitUntil() has been called, or return immediately if not. They don't have an internal method of resolving in the spec, so we also have a function called resolveExtendableEvent that'll do it for us. Like so:

const {ExtendableEvent, resolveExtendableEvent} = require('node-service-worker');

let installEvent = new ExtendableEvent("install");
sw.dispatchEvent(installEvent);

return resolveExtendableEvent(installEvent)
.then(() => {
    let activateEvent = new ExtendableEvent("activate");
    sw.dispatchEvent(activateEvent);
    return resolveExtendableEvent(activateEvent);
})

A utility function is also provided for this, given that it's so common:

const {installAndActivate} = require('node-service-worker');

installAndActivate(sw)
.then(() => {

})

Then use the following:

FetchEvent

Dispatch FetchEvents to get page content:

const {FetchEvent} = require('node-service-worker');

let fetchEvent = new FetchEvent("http://localhost/test/");

sw.dispatchEvent(fetchEvent);

fetchEvent.resolve().then(function(response) {
    // a FetchResponse object, if you're doing it correctly.
})

CacheStorage

You can check which files your service worker has cached on install, using standard CacheStorage APIs:

sw.caches.keys()
.then((keys) => {
    let openPromises = keys.map((key) => worker.caches.open(key));
    return Promise.all(openPromises);
})
.then((cacheObjects) => {
    let keysPromises = cacheObjects.map((c) => c.keys());
    return Promise.all(keysPromises);
})
.then((cacheEntryArrays) => {
    let allEntries = Array.prototype.concat.apply([], cacheEntryArrays);
    console.log(allEntries)
})

Note that it doesn't (yet?) actually cache these files, it just stores which URLs are cached.

console

By default any calls to console.log() and the like are hidden from view. If you want to see what was logged, you can call console.dump(). Best to use inside an error handler, like so:

let install = new ExtendableEvent("install");
sw.dispatchEvent(install);

install.resolve()
.catch((err) => {
    sw.console.dump();
})

Fetch interception

I'm still working out the best way to do this. But in browser service workers, the fetch() function automatically bypasses the worker (otherwise you'd end up in infinite loops). We need to provide a hook to do the same when using this as a server proxy. So, we can do the following:

const sw = new ServiceWorker({
    scriptURL: 'https://localhost/sw.js',
    scope: 'http://localhost',
    contents: 'console.log("hi");',
    interceptFetch: function(fetchArgs, fetch) {
        // fetchArgs is an array of arguments passed. Fetch is the fetch function

        return fetch(fetchArgs[0], fetchArgs[1]) // this would mean we're doing nothing
    }
})

to rewrite / do whatever we want to internal fetch requests.

importScripts() interception

Similar to fetch, this is experimental and even trickier because it has to be synchronous. But any call to importScripts() will be separated out into the individual scripts called (because it can contain more than one argument) and passed to a function named importScript in the worker initialiser. Like so:

const sw = new ServiceWorker({
    scriptURL: 'https://localhost/sw.js',
    scope: 'http://localhost',
    contents: 'console.log("hi");',
    importScript: function(url) {
        
        return fs.readFileSync(path.join(__dirname, url));

    }
})

The example above assumes the URL is relative, which it may not be. For HTTP requests you might be able to use something like https://github.com/ForbesLindesay/sync-request, but I wouldn't really recommend it.

Gobble plugin

There's also a plugin available for Gobble, allowing you to include static HTML copies of service worker fetch events in your build process. Like so:

var serviceWorkerRender = require('node-service-worker/gobble');

gobble('src/js').transform(serviceWorkerRender, {
    entry: 'sw.js',
    scope: "https://localhost/app-demo/",
    urls: [
        "./",
        "./home/"
    ]
})

Files are output relative to scope, so this example would create index.html and home/index.html (index.html is added automatically to URLs ending with /).