Bug: nodejs async variant — getcwd() fails on Windows when opening an on-disk database

[aelmosalamy]

Ladybug version

v0.15.3

What operating system are you using?

Windows 11 Pro (x64)

What happened?

Environment

• @ladybugdb/wasm-core v0.15.3
• Node.js v24.4.0
• Windows 11 Pro (x64)
• Variant: @ladybugdb/wasm-core/nodejs (async)

Description

Opening an on-disk database with the nodejs async variant on Windows fails during Database initialization with:

Error: filesystem error: in current_path: call to getcwd failed: No such file or directory
at Database.init (node_modules/@ladybugdb/wasm-core/nodejs/database.js:77:5)

This happens regardless of whether the path is relative ('db.lbug') or absolute (path.resolve(process.cwd(), 'db.lbug')) — the error occurs before the path is consulted. :memory: works fine.

Minimal reproduction

  // repro.mjs
  import { createRequire } from 'node:module'
  const require = createRequire(import.meta.url)
  const lbug = require('@ladybugdb/wasm-core/nodejs')

  const db = new lbug.Database('db.lbug')          // also fails with absolute path
  const conn = new lbug.Connection(db)
  await conn.query('CREATE NODE TABLE T(id STRING PRIMARY KEY)')  // throws here

Run: node repro.mjs

Replacing 'db.lbug' with ':memory:' makes the reproduction pass.

Expected behavior

The database file/directory is created at the given path, matching the behavior documented in the README ("this build is optimized for Node.js and uses Node.js's filesystem instead of Emscripten's default filesystem (NODEFS flag is enabled)").

Investigation

• The getcwd() call originates from the WASM engine's own bootstrap (C++ std::filesystem::current_path()), not from any path the user passes in.
• Reading nodejs/lbug_wasm_worker.js, the exposed FS-mount helpers cover only IDBFS (FSMountIdbfs) and OPFS (FSMountOpfs) — browser-only backends. There's no NODEFS mount helper exposed, and no automatic NODEFS mount against process.cwd() on worker init.
• This suggests either (a) NODEFS isn't actually active in the published nodejs build despite the README, or (b) it's active but never mounts the host CWD into the virtual FS, so getcwd() against the virtual FS returns ENOENT.

Possible fix direction

On nodejs worker init, mount NODEFS at a known path (e.g. /host) and either chdir('/host') or prepend that prefix when the user passes a disk path. The native @ladybugdb/core binding handles this transparently; the wasm nodejs variant should too if it wants to offer on-disk
persistence per the README.

Workaround

Use :memory: — but that defeats the purpose of the nodejs variant over the default variant.