coffeescript incompatibility

[deepblue-phoenix]

since the coffeescript wraps every file it compiles with a lambda block: (function() { ... }) all handlers created in the global scope in the coffeescript file (onmessage,onerror) are actually not global but wrapped in that same lambda block, and therefore not visible to the webworker-child.js setup script... hence workerCtx.onmessage is undefined, and so is onerror, and so the worker does not receive messages from the master...

coffeescript is gaining widespread use, and their decision to wrap every script in a lambda block to protect the global namespace is a valid one. hence I think that, in node-webworker, onmessage/onerror handlers should not be declared as they are currently as global vars, but instead should be passed in to some sort of global init() function (that would be attached to workerCtx when the worker is being setup inside webworker-child.js). that way it wouldnt matter where they're declared...

[deepblue-phoenix]

so I did a test patch and indeed the init_handlers function does solve the issue with coffeescript...

[pgriess]

The current globals-based API reflects the Web Worker's W3C spec. I agree that this API leaves something to be desired ;)

I want to retain the current API for compatibility, but am open to an alternate API, however, to accommodate what you're looking for. Can you send me your test patch so that I can take a look? And maybe an example program that uses it? I haven't seen Node work with CoffeeScript before and would like to understand more about how that works before moving forward with this.

[deepblue-phoenix]

Node works with coffeescript out of the box, its compiler by default depends on node, although it can work in the browser just fine as well... dont have the patch here on my work computer. but its literally a few lines of code.

[deepblue-phoenix]

thought about this issue for a sec again. the problem is that as you say the webworker in its current form (with global callbacks) is a w3c standard... so coffeescript as a language,if used directly, is going to deal with this same issue on the browser (in the ones that implement the webworker api).

so if we fix the api slightly here in node-webworker, and make it work, it still wont on the browser. a more or less thin layer of javascript might be a necessary condition for coffeescript to work with webworkers api in its current state, unless some compiler flag gets introduced in the coffeescript compiler that can turn off top-level lambda creation... in which case this issue should be brought up on the coffeescript repo issue board.

[deepblue-phoenix]

just in case I posted a feature request on the coffeescript compiler repo, asking for a compiler flag to turn global lambdas off

https://github.com/jashkenas/coffee-script/issues/issue/1067

[deepblue-phoenix]

and we have the solution 25min after I posted the issue the answer was commented. gotta love it :)

anyway, there's a coffeescript compiler flag, to turn the lambda wraping. duh...

so when compiling webworker worker/child scripts this flag has to be turned on for coffeescript to work with the webworker standard...

[deepblue-phoenix]

https://github.com/jashkenas/coffee-script/issues/issue/1067/#comment_691523

the solution

[pgriess]

Thanks for investigating, deepblue-phoenix.

For the tl;dr crowd, the solution is to pass '--bare' to the CoffeeScript compiler.