Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

worker_threads used on fastlify

See original GitHub issue

Hi 😃

I recently started using this library in one of mine, basically as part of the build I statically compress a WASM file (level: 9) and then on load inflate it. This has been tested quite wide under browsers and Node.js (.cjs and .mjs) and it is doing quite well with only a slight overhead, but quite nice overall savings in the bundles (even when served with compression)

However, just ran into an issue logged by one of my users and don’t quite know a way forward to improve matters and solve this issue as it stands.

So this (and it may also exist in mixed Node/browser frameworks as next.js - untested) basically means that the bundle serves from a node environment (which ignores the browser field in package.json), but executes in another environment, which actually does need that override and/or it doesn’t exist. (Not quite sure which option comes into play here, really not quite familiar with fastlify)

I actually only ever use unzlibSync (See, so in a perfect world would have avoided anything worker-related completely. However, in this case do get tripped up.

Any suggestions to work around this and or solve this? Preferable on this level?

Would really like to solve the linked issue, but don’t quite see any options - I guess if the parts were split into their own files (or even just sync/async), could have possibly done a direct import, avoiding workers completely. (Well, then we have tree-shaking issues since atm an export map is not required).

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

jacogrcommented, Dec 19, 2020

Thanks for the quick turn-around here - I’ve asked the reporter to update. (I will also try and replicate the issue today, so will provide feedback either way, either from the reporter or myself)

101arrowzcommented, Dec 19, 2020

I’ve updated the package as of adf1a5b and v0.4.3 on NPM, try updating. I reread the stack trace in what you linked and it’s actually a server-side issue, not client side.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Worker Threads support? · Issue #1401 · fastify/fastify - GitHub
Can i use worker threads within fastify? ... You can definitely use workers to handle CPU heavy operations but not for handling every...
Read more >
fastify-threads - npm
A Fastify plugin that exposes threads.js functionality. Latest version: 2.0.0, last published: 5 months ago. Start using fastify-threads in ...
Read more >
Worker threads | Node.js v19.3.0 Documentation
The node:worker_threads module enables the use of threads that execute JavaScript in parallel. To access it: const worker = require('node:worker_threads');.
Read more >
Node.js multithreading with worker threads series - Reddit
I wrote a file upload handling library that doesn't use intermediate files (unlike Formidable), doesn't require a StorageEngine (unlike Multer), ...
Read more >
Using worker_threads in Node.js - Medium
js's built-in mechanisms for performing operations asynchronously already treat it more efficiently than Worker threads can. worker_threads are more lightweight ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found