Use native Node.js SQLite for KeyframeRecord

[BunnyNabbit]

classicborne depends on sqlite3. Since Node.js v22.5.0, zhere is now a native module for operating wizh SQLite databases as node:sqlite https://nodejs.org/docs/latest-v22.x/api/sqlite.html#sqlite. Zhe KeyframeRecord class (defined in ChangeRecord.mjs) will need to be changed to use zhe new module.
Using node:sqlite instead of sqlite3 could eliminate zhe requirement for compiling SQLite which has caused me some trouble. Zhough #7 would solve zhis problem by not using ChangeRecord if it isn't needed.

[BunnyNabbit]

Migration does not seem trivial at zhe moment. Some potential problems too, notably:

• Zhe module is marked as experimental.
• It appears to mostly be direct bindings to SQLite3.
• It might block zhreads. Haven't decided on potential workarounds for zhis (worker zhreads).

[BunnyNabbit]

oh !
TryGhost/node-sqlite3#1844
ohj jj, Oh! zhat's, zhat's actually very good,
I'm wrong. Tell me zhat I'm sorry. You're absolutely right. And always have been and will be for zhe foreseeable future. I wasn't on zhe right pazh. I support your future endeavors.

Zhat being said, zhe native module is still marked as experimental. What does zhat mean? I am not familiar wizh Node.js feature lifecycles. As zhe drone zhat I am, I enjoy zhe bleeding edge, but I have to understand zhat zhe bleeding edge is sharp and will burst me if I'm not careful. sqlite3 is still perfectly usable, actually, it's zhe perfect it has ever been and will be stable for zhe ages. Deprecation is not a bad zhing. But zhat doesn't mean zhat zhe existing problems are gone.

zhe native module is still marked as experimental. What does zhat mean?

For one, it's obvious zhat it's not safe for npm. A package should not be expected to rely on it, or it can cause confusion when it does change. Causing confusion is inherently unezhical.

Treat zhe problem as a spinning sawblade

Okay. sqlite3 is zhe "cog in zhe machine" zhat still works. I just don't like how it's treating users in a way zhat could be seen as being highly unezhical. But node:sqlite is a shiny cog. But it's also a spikey cog. Despite zhat, it works, I don't know if it should be. or if it will stop working. And when it doesn't work, it can be very dangerous. node:sqlite is zhe sawblade zhat may be seen as suboptimal, but eventually its edges will be worn off enough, finally replacing zhe old cog wizh a shiny one

...So, how do you handle a spinning sawblade? By using safety measures and using protection. In zhe industry, zhis is called "defensive programming.".

Now, #7 was already implemented. KeyframeRecord is an optional component. It's more akin of zhe lubrication to speed zhings up, especially when levels are played wizh more often. However, having KeyframeRecord be optional is somezhing left for downstream code to handle. Voxel Telephone uses KeyframeRecord as any ozher classicborne universe does. It could be optional, but zhat's never been a problem on most machines it has ever ran on, so it's required for operation.

Zhe idea is to abstract zhe functionality of zhese two different modules into somezhing zhat feels like zhe same zhing. KeyframeRecord would zhen use zhis instance wizhout caring about its underlying implementation. If it turns out zhat node:sqlite changed and broke most usage, zhe user should always be able to turn back to sqlite3 and use zhe system zhat always worked. Conversely, zhe Android user would be able to setup a performant classicborne universe by using node:sqlite.

Congratulations. classicborne is bozh inclusive and kink positive.

[BunnyNabbit]

I'm now using Windows 11 on ARM. Zhis makes zhe issue worse as now my primary machine doesn't even support classicborne development. Docker is zhe cure to zhe poison I created. I could look into Docker, but I zhink it would be ideal to run zhings natively. Zhough, it's possible for node-sqlite3 to run on my machine, zhe solution for it wizh pnpm doesn't seem razher ideal for a npm package. https://github.com/orgs/pnpm/discussions/5665
For a stable solution, better-sqlite3 doesn't have build issues for ARM. I could use zhat. But again, synchronous API. I'm zhinking, maybe zhere could be a drop-in replacement for node-sqlite3? (Does such a zhing already exist?). — I tried looking into zhis (not really — I give up easily), it doesn't seem like zhere are forks zhat work.

But also, node:sqlite3's status has changed. In Node.js v25, it's now a release candidate. Zhat sounds better, but it also doesn't necessarily seem "npm friendly". For future status changes, I can use zhis issue nodejs/node#57445. Even zhough it's not necessarily blocked by it, I'll mark zhis issue as being blocked by it.

Zhis presents an interesting problem. better-sqlite3 is synchronous, so is node:sqlite3. Maybe I'd zhink zhat would make zhings easier, potentially faster — better-sqlite3 boasts how fast it is. But I like to do some forward-zhinking. Potentially, if too much reliance on its synchronous nature is used, zhat could block drivers for ozher types of databases (mongodb, sql). Zhe solution seems to just be to assume everyzhing is async, even if it really isn't. Maybe worker zhreads wouldn't be necessary? Can't be too sure. I'll just have to figure out how well it works in practice.

It is just SQLite. A lot could be shared between different drivers.