Giter Club home page Giter Club logo

workerify's Introduction

workerify

Transform web workers into browserified inline Blobs with browserify.

browser support

example

Your entry point main.js:

var mod = require('module')
var worker = new Worker('worker.js')

Your worker entry point worker.js:

self.onmessage = function(e) {
  var ab = new Uint8Array(10)
  for (var n = 0; n < ab.length; n++) ab[n] = 1
  self.postMessage(ab.buffer, [ab.buffer])
}

Browserify with this workerify transform:

browserify -t workerify main.js > bundle.js

and your bundle.js will look like:

var mod = require('module')
var worker = new Worker(window.URL.createObjectURL(new Blob(['BROWSERIFIED CONTENTS OF worker.js'])));

further example

Take a look at the example module for using with workerstream.

Modular Workers

The main reason for this is modular workers.

Let's say you create a module that would like to use web workers. Users would need to configure the URL to the worker. When your module becomes a dependency of a dependency and so on, the setup becomes really cumbersome. Especially when your worker needs to be browserified.

With this transform you simply npm install workerify --save and configure your module's package.json to apply the transform:

{
  "name": "mymodule",
  "browserify": {
    "transform": "workerify"
  }
}

Now when end users browserify your module, anywhere in the dependency tree, it will browserify and inline the worker. No URLs, no extra build steps and no additional end user requirements.

Notes

Currently it will transform the following:

// String literal
new Worker('./path/to/worker.js')

// Variable Init Earlier
var myworker = './path/to/worker.js'
new Worker(myworker)

// Or specify the workerify keyword to browserify a string anywhere
// Useful if you want to inline your worker when working with other libs
var myworker = workerify './path/to/worker.js'
var workerstream = require('workerstream')(myworker)

Using with coffeescript

browserify file.coffee -t coffeeify -t workerify

install

With npm do:

npm install workerify

release history

  • 1.1.0 - Support for Workers as modules (@moin-qidwai).
  • 1.0.0 - Upgrade browserify to 14.0.0 (@runn1ng) and other deps. Prefer window.URL over window.webkitURL.
  • 0.3.0 - Upgrade browserify to 3.41.0. Allow worker to be used with watchify (@tmpvar)
  • 0.2.3 - support compilation from coffeescript original source file
  • 0.2.2 - string-escape dep renamed to jsesc (@mathiasbynens)
  • 0.2.1 - Add missing falafel dep and bug fixes (@mikolalysenko)
  • 0.2.0 - use falafel and support more formats
  • 0.1.0 - initial release

license

Copyright (c) 2017 Kyle Robinson Young
Licensed under the MIT license.

workerify's People

Contributors

hughsk avatar kaosat-dev avatar karelbilek avatar mathiasbynens avatar mikolalysenko avatar moin-qidwai avatar rodincave avatar shama avatar tmpvar avatar weilu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

workerify's Issues

Workerify to separate files

I'm curious if anyone has spent any time to make workerify output the worker bundles to separate files, and keep the worker path in the code the same. Basically the output would be the main browserify bundle, next to any worker bundles that were generated.

Use browserify's extensions option

workerify doesn't seem to respect browserify's extensions option. Using require inside a worker I need to append '.coffee' to the path even though '.coffee' is already defined as an extension in browserify's options.

Worker support on older webkit browsers

Basically this: URL = window.URL || window.webkitURL so that this module works for safari 5 and 6.

I'm not sure if workerify should be doing this or should this be the responsibility of app devs to pull in their own shim/polyfill. For me, it's just not worth pulling in a complete set of shims just for this. Therefore I just monkeypatched URL as a global.

workerify keyword no longer working

Maybe we can just remove that option.

> [email protected] test /Users/bret/repos/workerify
> browserify test/test.js -t ./ -o test/out.js

/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:2750
  throw err
  ^

SyntaxError: Unexpected token (24:26)
    at Parser.pp$4.raise (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:2748:13)
    at Parser.pp.unexpected (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:644:8)
    at Parser.pp.semicolon (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:621:64)
    at Parser.pp$1.parseVarStatement (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:1027:8)
    at Parser.pp$1.parseStatement (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:785:17)
    at Parser.pp$1.parseBlock (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:1104:23)
    at Parser.pp$3.parseFunctionBody (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:2591:22)
    at Parser.pp$1.parseFunction (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:1211:8)
    at Parser.pp$3.parseExprAtom (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:2176:17)
    at Parser.pp$3.parseExprSubscripts (/Users/bret/repos/workerify/node_modules/falafel/node_modules/acorn/dist/acorn.js:2039:19)
npm ERR! Test failed.  See above for more details.

Can't workerify transformed CoffeeScript

workerify's \.js matcher excludes CS files transformed with coffeeify from being parsed.

i would simply open a pr to update the matcher to \.(js|coffee) but attempting to workerify a non-transformed CS file throws a pretty nasty error stack. i'm not sure what the best way to handle this is, but the feature itself would be highly useful.

Inline functions

That copy in all the vars to make it seem like its within the same context:

var mod = require('module')
var worker = new Worker(function() {
  var data = mod()
  self.postMessage({data: data})
})

Which would then be transformed into:

var mod = require('module')
var worker = new Worker(window.URL.createObjectURL(new Blob(["(function() {
  var mod = require('module')
  var data = mod()
  self.postMessage({data: data})
}())"],{type:"text/javascript"}))

Generating a bundle with multiple entry points - Relative path to worker file breaking

I'm using gulp to generate a browserify bundle with two entry points. One for a small Backbone app and the other for site wide modules.

The relative path to my worker file specified within one of the site wide modules is no longer working:

let workerTimeout = new Worker('./workertimeout');

Upon running the gulp build with the multiple entry points the path appears to be perceived to be relative to a different directory to the module that contains reference to the worker file.

For example:

Error: Cannot find module '/home/tom/domains/italk.tom/project/resources/assets/js/signup/models/workertimeout

No problem if using a single entry point to generate the browserify bundle.

workerify + browserify' s 'process' = window object undefined

first things first, thank you for this transform... it's truly awesome.

I'm using workerify to inline some code that runs levelUP on top of memDOWN, which calls the node process api, which in turn, means that browserify includes it's own special browser process.nextTick package, which uses window D:, I did a monkey patch to avoid the use of window in the actual function: https://gist.github.com/rynomad/9183135

But even having the node process module automatically required makes browserify try to pass the window object into the module.

using my above gist combined with going a find + replace "window" with "self" in my final bundle is working for now, but ultimately unsustainable.

I'd try to fix this myself and do a pull request but honestly I have only the faintest idea how browserify and the transform ecosystem actually functions.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.