Avoid dynamic require of the native package (2nd attempt)

[bgw]

This is a PR against the v0.5 branch

This is a second attempt at #200, which was reverted due to a regression in esbuild (#201).

This is an attempted fix/mitigation for https://github.com/vercel/next.js/issues/82881#issuecomment-3215277221

Apparently esbuild requires try/catch blocks to make failing non-dynamic requires throw a runtime instead of at build time. https://github.com/tursodatabase/libsql-js/issues/201

This new implementation more closely matches the pattern used on the main branch: https://github.com/tursodatabase/libsql-js/blob/31bed6686fc199ac022bc70e202dfb83f5603416/index.js#L31-L311

I tested this against the minimal repro at https://github.com/RomanHotsiy/libsql-bug-repro

I can't get the code built by esbuild that repro to run (node dist/index.js):

• I had to modify the output format from mjs to cjs to get node to run it
• But then I get an error because the *.node file has to be handled somehow, which the repro doesn't do

However that repro now builds cleanly (npm run build), which is all I think it's really intended to show.

[Lilja]

@penberg hi! could you please review this PR?

[bgw]

@Lilja, if you're blocked on this, you can work around it by doing one of the following:

• Update to Next 16, which has a mitigation for this: https://github.com/vercel/next.js/pull/84408
• Update to the libsql 0.6.0 prerelease, which does not have this problem.
• Use a package manager that doesn't hoist, like pnpm or bun with bun install --linker isolated (now the default in 1.3: https://bun.com/blog/bun-v1.3#isolated-installs-are-now-the-default-for-workspaces)

[Lilja]

@bgw Thanks for the suggestions! I'm using bun and I am bundling a typescript backend with Elysia so I'm afraid I can't use Next.js. Right now I'm externalizing @libsql/client and globally installing it in my dockerfile instead, as a workaround. It's not pretty but it's working.