Release?

[yovanoc]

Can you do a release with the latest changes please?

[sinclairzx81]

@yovanoc Hi, thanks for your interest in the library.

Unfortunately, the lib is pending a rebuild and isn't in a publishable state. I plan to revisit sometime later next year (most of the work involves removing the decorators and opting for the interface you see in the readme). Also I'd like to explore getting this library to work across Node, Deno and the Web Browser (ESM). But to support all environments, some of the internals need to change, so this is deferred for the time being.

The current published version should work fine on Node in the interim (the functionality isn't changing in the planned update, however the Main entry point may require passing the import.meta or other descriptor across environments)

Apologies for the inconvenience.

[yovanoc]

Oh right I get it but it's not working with nodejs and esm for me with decorators. I get this strange error:

Error: Cannot find module '/Users/devchris/code/nodejs/workspace/dev/apps/project.js' {"context":{"app":"project","env":"prod"},"metadata":{"err":{"code":"MODULE_NOT_FOUND","requireStack":[]}}}

workspace is a turborepo.
project main is at src/index.ts

but I really don't know why is looking for a project.js, and its only when I add the @main decorator.

Is there any other way for now?

[yovanoc]

@sinclairzx81 You will never come back to this lib? thanks

[sinclairzx81]

@yovanoc Hi,

Um, I may return to this project one day. Unfortunately, I had made some attempts to get this project working with Node, Deno, Bun and the Web Browser (with not much success). I could simply push on with this project being exclusive to Node, but not entirely sure if it's worthwhile (also, the mechanisms used by this project seem at odds with "top-level-await", and typical JavaScript idioms)

I guess I could proceed with this project so long as users are fine with

import { Thread } from '@sinclair/threadbox'
import * as Http from 'node:http'

Thread.Main(() => {
   // ensure all top level code is wrapped within a Main callback.
   Http.createServer(() => { ... }).listen(1234)   
})

Thoughts?

[yovanoc]

I think if we can await import in the callback it should cover all cases

[sinclairzx81]

@yovanoc Heya,

I think if we can await import in the callback it should cover all cases

There might be some caveats to that, not sure. The way this system works is each "threaded" class needs to be registered and (re-registered) for each thread you spawn. The system tracks an id ordinal for each class is based on the order in which modules import (which is assumed to be predictable based on the module resolution order), and remote classes are instanced in remote threads based on ordinal id known to both parent and spawned thread (assuming both registered the same class with the same id derived from the module/instantiation order)

So, this works for standard imports, but await import will likely cause issues as the import (and instantiation) order is no longer predictable (or statically analyzable). So, like I say, there's caveats to this approach which would require developers to work within certain constraints (which may be acceptable given the nature of the library), but certainly something to keep in mind.

There was a couple of things I wanted to add to this library (specifically static/global threads), but don't currently have the time to implement. If there's demand for a library like this, it would be somewhat more compelling however.

Did you have a use case in mind?