Hello
It is already possible to hook workers scripts into ember-cli build process (including watching) even it is not straightforward.
Option 1: workers does not need to reuse routines from application
Its possible to include own building tree in Brocfile.js
var webpackify = require('broccoli-webpack');
MyApp.prototype.workerJavascript = function () {
var bundler = webpackify(path.resolve('./worker'), {
entry: './main',
output: {filename: './assets/worker.js'},
devtool: 'eval',
module: {
loaders: [
{test: /\.js$/, loader: 'babel-loader'},
]
}
});
return bundler;
};
MyApp.prototype.toArray = function () {
var trees = EmberApp.prototype.toArray.apply(this, arguments);
// extra builders
trees.push(this.workerJavascript());
// ...
return trees;
};
Worker code is expected to reside in ./worker
dir. entry point of worker is main.js
. Instead of webpackify
it is possible to use broccoli-babel-transpiler
and broccoli-es6modules
which are used by ember-cli. Worker code could be written in es6 favor including eg. import
. I can publish gist if needed.
Option 2: workers need to reuse code from application
In that case I would suggest to create new standalone application which will contain the worker logic. Routines to be shared between worker and application needs to be separated to addon used among them.
Also the worker app need to be placed somewhere in parent application directory, then broccoli-static-compiler
(pickFiles) could be used to pick built output of worker and copy it to app assets.
Of course this solution is intended only for long live workers, not the "spawn-do-die" workers, because whole ember stack needs to be loaded inside worker's thread. I briefly tried to include ember.js in worker and it worked.
For these purposes I am now working on addon which will publish interface defined by worker as standard ember service and provides easy execution of worker methods utilizing promises. Not the addon yet, just platform, but already passing tests. It can be seen here: https://github.com/janmisek/workerio