Error: Failed to initialize HarfBuzz: ReferenceError: __dirname is not defined (when running via nw.js)

[framethrower]

First of all:
what a suprisingly complex field wrapped into a super nice and fast little package. Extremely useful. Love it!
I hope one day i will do something as useful with my life :)

JS is not my main gig, so i get confused at times; please excuse that.

I have the following situation:
Everything runs fine when i run or build it directly via vite. (Node.js v22.20.0, VITE v6.0.9, "three-text": "^0.3.5")

But now i have to run it in a very specific environment:

NW.js v.0.70.0

https://nwjs.io

https://dl.nwjs.io/v0.70.0/nwjs-sdk-v0.70.0-linux-x64.tar.gz

And when i do that i get this error:

Error: Failed to initialize HarfBuzz: ReferenceError: __dirname is not defined

Now since Node v20.11.0 there is a new workaround (or better: a new way) to get the dir:

import.meta.dirname

nodejs/node#48740

So when i change scriptDirectory=__dirname+"/"; on line 4454 of (the line that's >14000 character long) in ./node_modules/three-text/dist/index.js into scriptDirectory=import.meta.dirname+"/"; then it works for me in the nw.js environment and also still works in the browser.

Buuut i'd like to avoid manually "patching" your lib.
What's the best approach here?

Thx! 😚

[jpt]

hi @framethrower - thank you for the very kind message, I really appreciate it

this is indeed a JS/node version, ES modules vs CommonJS thing: __dirname is a CJS global and doesn't exist in ESM. I wonder if harfbuzzjs is deciding it's in a node/CJS enviornement but trying to execute ESM code. I might be able to fix this in the rollup config. I definitely want to support as many environments as possible so this is very helpful information..

in the meantime, importing the CJS build via createRequire() might work for you:

import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const { Text } = require('three-text/three');

but I have not really been testing the CJS build, so I'm not sure, and I'll want to fix this regardless so others don't encounter the issue

consider it in progress, I will let you know when it's either resolved or I have something for you to test :)

[jpt]

hi @framethrower - can you try 0.4.1 and let me know if it fixes the issue? I took your workaround and applied it as a rollup transform so the ESM build won’t crash on __dirname, and I also adjusted the bundling so NW.js can use the real node fs for loading the HarfBuzz WASM. I verified this locally, but if you still hit anything I'm happy to take a look if you can share a minimal repro. I'll keep the issue open until I hear back 🤞

[framethrower]

hey @jpt,
thx for coming up with a fix so quickly and sorry for me taking my time to check it out.
a bit busy atm.

sooo, first of all, i think your fix fixed it! 🙂

when i use 0.4.1 (or now 0.4.4) everything loads fine!

i'm still a bit confused about the fact that i can't seem to use Text.setHarfBuzzPath when i'm in the nw.js environment.

no matter where i put the hb.wasm file and which path i pass to Text.setHarfBuzzPath() i get:

index.js:4563 failed to asynchronously prepare wasm: Error: ENOENT: no such file or directory

Text.setHarfBuzzPath('hb/hb.wasm')
Text.setHarfBuzzPath('./public/hb/hb.wasm')
Text.setHarfBuzzPath('/hb/hb.wasm')
Text.setHarfBuzzPath('./hb/hb.wasm')

but when i do this instead it works perfectly fine:

const wasmResponse = await fetch('./hb/hb.wasm');
const wasmBuffer = await wasmResponse.arrayBuffer();
Text.setHarfBuzzBuffer(wasmBuffer.data ? wasmBuffer.data : wasmBuffer);

so i'm good here ☺️ no need for you to get involved in that.

as far as i'm concerned this issue is solved and can be closed.

thx again and best regards from southern-germany!

[jpt]

hi @framethrower - that's great news that it's working for you! and no worries, take all the time you need, I'm very appreciative of your helping with this issue - zero pressure from me :)

i'm still a bit confused about the fact that i can't seem to use Text.setHarfBuzzPath when i'm in the nw.js environment.

this was confusing to me too, it looks like in my initial attempt to reproduce your problem I put hb.wasm in a path that was tricking me a bit, falling back to fs to read it - I looked at this more closely (particularly this section of the NW.js docs) and have now tested across ESM and CJS with and without vite, as well as in Electron. what I learned is that the 0.4.1 fix addressed the __dirname crash but didn't fully solve path-based loading in NW.js. this is now fixed properly, and will be in the next release after I do just a bit more Electron testing. I'm also adding some notes to the README.

in the meantime, setHarfBuzzBuffer works, as you discovered. once I push up the new version, and if you upgrade, setHarfBuzzPath should work as expected with Vite + NW.js. but, the method you're using now should continue to work as well. I'll leave a note when that version goes live. thank you again, cheers!

[jpt]

this should be fixed in #26 which I have not yet merged - zero pressure to try it out, just mentioning it as I do a little more testing

[jpt]

published 0.4.5 and this should all be good now but please reopen or create a new issue if you have trouble - thanks again!