Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't bundle for worker #141

Open
Qix- opened this issue Jul 5, 2021 · 5 comments
Open

Can't bundle for worker #141

Qix- opened this issue Jul 5, 2021 · 5 comments

Comments

@Qix-
Copy link

Qix- commented Jul 5, 2021

When bundling elk to be called not as a worker, but instead bundled as a larger codebase that is eventually used within a worker, elk has different export semantics and cannot be used whatsoever by the bundled code.

The culprit is this generated code:

  if (typeof document === 'undefined' && typeof self !== 'undefined') {
    var dispatcher = new Dispatcher(self);
    self.onmessage = dispatcher.saveDispatch;
  }
   else if (typeof module !== 'undefined' && module.exports) {
    Object.defineProperty(exports, '__esModule', {value:true});
    module.exports = {'default':FakeWorker, Worker:FakeWorker};
  }

Please, don't do this. To assume it's always meant to be run as a standalone worker just because it's within a worker context reduces modularity and re-usability, and just caused a good deal of headache.

The better approach would to be to generate two scripts - one that is the library and exports the same, always, and another that exports a worker wrapper around it.

@uruuru
Copy link
Member

uruuru commented Aug 7, 2021

Unfortunately, I currently do not have the time to rewrite the correspondings parts. Hence, suggestions how to adjust the current implementation are very welcome.

The generated code you point out results from the GWT wrapper code. The GWT wrapper code has likely to be adjusted to actually provide a proper module. Maybe even by adjusting the linker to include the module related parts.
The second step would then be to provide the worker wrapper.

@igordata
Copy link

igordata commented Aug 9, 2021

Sometimes I got that error, I don't remember exactly when and in what circumstances, but I can share when I don't have this error (and similar with other modules) without changing the code. Hope that helps.

  "scripts": {
    "dev": "nodemon --watch \"src/**\" --ext \"ts,json\" --exec \"node --experimental-specifier-resolution=node --loader ts-node/esm src/app.ts\"",
    "build": "tsc --project ./",
    "start": "node --experimental-modules --experimental-specifier-resolution=node ./dist/app.js"
  },

I use typescript in my projects. If you don't - just ignore ts-specific stuff.
I think these flags --experimental-modules --experimental-specifier-resolution=node do the trick and the error goes away.

@geoyws
Copy link

geoyws commented Sep 2, 2021

Has anyone had any luck trying this with React's CRA before? I'm not sure how we could pass --experimental-modules --experimental-specifier-resolution=node to webpack-dev-server

@DPros
Copy link

DPros commented Sep 27, 2021

my solution for angular environment:
include elk in angular.json:

"allowedCommonJsDependencies": [
  "elkjs"
],
"scripts": [
  "node_modules/elkjs/lib/elk.bundled.js",
]

declare variable (it's a constructor) and initialize elk in .ts file:

declare const ELK: any;
...
private elk = new ELK();

@AngryLoki
Copy link

@Qix- , thank you for your fork, it is actually exactly what I needed!

I've integrated your version into Wikidata Graph Builder (example graph). This graph is fully computed inside a webworker - everything starting from fetching data, up to drawing inside transferred OffscreenCanvas. Special thanks for removing layouts, now compressed worker is just 414 kb, which also includes drawing part. Now elkjs is actually a good alternative to dagre.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants