Expose worker urls to consumer

[ShaMan123]

Description 📝

As a consumer I need to import the worker file in order to init FragmentsModels

engine_fragment/packages/fragments/src/FragmentsModels/index.ts

Line 66 in 1c49df1

constructor(workerURL: string, options?: { classicWorker?: boolean }) {

This a bit painful/complicated.

Suggested solution 💡

• It can be an optional arg, falling back to the default.
• The worker files should be declared for consumption via exports under package.json.

Alternative ⛕

No response

Additional context ☝️

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

[agviegas]

Hey @ShaMan123 you cannot "import" the worker as if it was a js class, if that's what you mean. You need to have the physical file somewhere, either on your repo or somewhere public in the internet.

That said, I can add a default path that fetches that file from our github/npm page by default, so that you don't need to pass it if you don't want to.

[ShaMan123]

I mean something like the following for modern frameworks (e.g vite):

https://v3.vitejs.dev/guide/features.html#web-workers

import workerUrl from "@thatopen/fragments/dist/Worker/worker.mjs?url";

This import requires me to dig through fs.

It would be great to have something like:

import workerUrl from "@thatopen/fragments/worker?url";

This will offer intellisense as well.

[ShaMan123]

Also I am not sure I understand why the worker code is compiled

[ShaMan123]

Hey @ShaMan123 you cannot "import" the worker as if it was a js class, if that's what you mean. You need to have the physical file somewhere, either on your repo or somewhere public in the internet.

That said, I can add a default path that fetches that file from our github/npm page by default, so that you don't need to pass it if you don't want to.

Why not create a relative reference to the file from the package?

[agviegas]

@ShaMan123 do you mean a relative reference to the node_modules folder? 🤔 keep in mind that the worker is not a single file in the library. It's many files that get bundled to a single worker.js that we deliver with the library in npm.

[ShaMan123]

package.json

  "exports":{
    "default": "./dist/index.mjs",
    "types": "./dist/index.d.ts",
    "worker":{
      "default":"./dist/Worker/worker.mjs",
      "import":"./dist/Worker/worker.mjs"
    }
  },

consumer:

import workerUrl from "@thatopen/fragments/worker?url";

[ShaMan123]

You might consider a different approach altogether and hand off the worker setup to the consumer:

- import workerUrl from "@thatopen/fragments/worker?url";
+ import Worker from "@thatopen/fragments/worker?worker";

const fragments = components.get(OBC.FragmentsManager);
- fragments.init(workerUrl);
+ fragments.init(new Worker());

[agviegas]

@ShaMan123 That's an interesting approach. I can do that, but will everyone's bundler include the worker as a separate file in their apps? Maybe I'm not following you.

[ShaMan123]

Not sure I understand what you mean.
The bundler is in charge of that... that is the beauty of delegating the responsibility to the consumer. They have to deal with bundling. Vite does what it needs under the hood and it simply works.

[ShaMan123]

Let's break it down.
There is some functionality that runs in a worker.
Ideally the functionality should be decoupled from the worker.
Some static method can handle the worker registration installWorker()

functions.mjs

// a lot of logic

worker.mjs

import { installWorker } from './functions.mjs
installWorker()

main-thread.mjs

import Worker from "./worker.mjs?worker"; 
new Worker()

// OR

new Worker('./worker.mjs')

Then you can expose worker.mjs or just expose functions.mjs and let the consumer setup worker.mjs

[agviegas]

Thanks a ton for the extensive explanation. Both things done:

1. package.json: Added exports field with "./worker" entry, so consumers can do:

import workerUrl from "@thatopen/fragments/worker?url";

2. FragmentsModels constructor: Made workerURL optional. When not provided, it resolves to the bundled worker.mjs via new URL("./Worker/worker.mjs", import.meta.url).href. This works with Vite, Webpack 5, and Node.js ESM. Other bundlers might require manual configuration. Consumers can now simply do:

const fragments = new FragmentsModels();

Available from version @thatopen/fragments@3.3.6 (to be published these days). Cheers!

[ShaMan123]

Awesome!