shama / workerify Goto Github PK

https://github.com/substack/node-falafel

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.

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.

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"}))

I'm using es6 with the help of babelify and afaik workerify doesn't work with any other transforms - es6 code stays untransformed

Any ideas?

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.

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.

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.

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.

This module is using ancient browserify. Can you please update? Thanks

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.

SharedWorkers aren't much different in terms of creation than Workers; would be great to have.
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#shared-workers-and-the-sharedworker-interface