Meteor-feature-requests: Allow custom additional build targets

[mitar]

So instead of having a fixed set of targets, it would be great to allow custom targets to be started. So one could:

• create a top-level directory like customtarget and mark it as linked to target web.customtarget, so all files there are added to the target
• allow packages to do add.addFiles([...], 'web.cutomtarget')
• this would then create a bundle accessible under /__customtarget/bundle.js or something
• support dynamic imports inside custom targets

This would allow experimentation with various types of workers and also building browser extensions as part of the app.

[CaptainN]

In pursuit of an offline caching solution, I've found a few performance bottlenecks. The appcache package takes care of initial modules (and incorrectly also caches dynamic modules, which Meteor will never use), and I use indexedDB for other things (Meteor's dynamic import, and Ground:DB uses that too). But there is a performance penalty when loading things behind the scenes into my caches, because things still need to be loaded, parsed and evaluated.

Service Workers could be used to solve this, but that support isn't ready yet in most browsers.

Web Workers are ready today - but we need to be able to generate additional app bundles (this is true for service workers as well).

Any chance we will see multiple target bundle support ship in an upcoming version of Meteor (perhaps 1.7)? It would really help solve some of these offline/precaching performance issues, and it'll also be useful to move forward with service workers when the time comes.

[NitroBAY]

Safari now support service workers.

[msavin]

How did Safari get service workers before Meteor 😂

[schlaegerz]

For people who are lost trying to get web workers in meteor working I found out a workaround:
npm i -g browserify

then

browserify -p tinyify ./src/myWorkerCode.js -o ./public/worker.bundle.js

Then in my code

let workerObj = new Worker(url.resolve(Meteor.absoluteUrl(),'/worker.bundle.js'));
      workerObj.onmessage = (event)=>{
          callback(event.data)
          workerObj.onmessage = null
          workerObj = null
        }
       workerObj.postMessage(parameters)

This does mean i have to run the command every time I change that code and that the bundle is just hanging out in the public directory but it is the only way I found to have meteor not create a whole code bundle. It would be great for Meteor to support this so there are no extra steps every time I change the file.

If any one has some tips to make my work around better let me know.

[CaptainN]

You can actually create Web Workers from a Blob (by doing function(){}.toString() and creating a Blob to load). Which is pretty neat, and since it's all client side, doesn't require the build system to create a new end point.

The same doesn't work for Service Workers though.

I'm getting more and more interested in using a custom build target for React Native, in addition to Service Workers.