Suggestions... for the worker, you don't even need to extend the class, there's no real value here. Remove the class definition and change the exports to...
module.exports = new ThreadWorker(yourFunction, {...})
For the pool, put the emitter on the pool itself, you can extend your initial FixedThreadPool/DynamicThreadPool with the emitter... you can add the emitter to your prototype chain or base class(es).
For the pool, instead of passing event handler options, utilize the event emitter...
pool.on('error', error => ...);
pool.on('ready', () => ...);
You may also want a method that returns a promise bound to your ready event...
await pool.ready();
Otherwise, cool concept.
Interesting app... needs a few improvements though.
* needs radio streams.
* better persistence (sqlite?)
* large local directory add, app blows up
Definitely some potential here.
Can't pull up the site at work, may be down... There's no real point to "Web Safe" color codes these days. If it's referring to sticking to matched color points, which was more important in the days were 256 color displays and graphics controllers were much more common.
Changed the title as this is not "Node Middleware" it is "Express Middleware" ... Node middleware would be something like plugging loaders into require, or things like the `esm` module.
I think that it's of some value for libraries... the definitions file(s) for use with VS Code are really nice, even when using plain JS in your end project.
Inside some projects, it may or may not provide value, as TFA mentions, there's no io checks to/from APIs. Beyond this, it doesn't negate the need for testing and coverage. In some scenarios, type complexity can be a lot of effort for very little gain.
Aside: I've been looking at some of the GraphQL libraries with great interest... though I'm unsure of pieces of authentication and updates, it's definitely a nice approach to certain types of data and workflows and does (optionally depending on library) do type checking against definitions.
Personally, I don't support any version of IE at this point. It's EOL, replaced and a security risk. Not to mention the shims/shivs/transforms needed for ES2017+ are massive. It's a target that's not worth taking for the most part.
Another use case worth mentioning is creating reports from HTML/SVG/Canvas output to PDF for download. It's compute heavy, but often easier than trying to shoe-horn a reporting module, or use PDF primitive libraries directly.
Suggestions... for the worker, you don't even need to extend the class, there's no real value here. Remove the class definition and change the exports to... module.exports = new ThreadWorker(yourFunction, {...}) For the pool, put the emitter on the pool itself, you can extend your initial FixedThreadPool/DynamicThreadPool with the emitter... you can add the emitter to your prototype chain or base class(es). For the pool, instead of passing event handler options, utilize the event emitter... pool.on('error', error => ...); pool.on('ready', () => ...); You may also want a method that returns a promise bound to your ready event... await pool.ready(); Otherwise, cool concept.Alternatively... const delay = ms => new Promise(resolve => setTimeout(resolve, ms)); ... await delay(5000);