[Track] Node-gyp sucks

[airone01]

node-gyp sucks

Multiple reasons to refractor the app and remove node-gyp:

1. As the name implies, using a Node-specific modules is a bad idea for portability (for Bun and Deno)
2. The better-sqlite3 package relies on node-gyp which makes it not usable with Bun at all.
3. The reason we use this module at all is because nobody added native support for SQL (or at least SQLite) in the runtime, which is already the case for Bun and Deno so they have to suffer for no reason
4. The core idea and principle of it sucks (see here and here), as it compiles C and C++ code, and I'm no low-level pro, but I believe there has to be a better solution to this
5. Bad support for anything that is not Ubuntu, because of libs and DLLs. To be fair, Bun doesn't support Windows, but It's on its way, and fast.
6. Can also break the light CI/CD or Docker environments
7. The Node.JS team assumes you are using Node and V8, even though there are multiple runtimes and engines available. I would advise against using any Node-specific modules.

Possible solutions

Aside from my rant, the solutions I looked up were:

• [x] Keeping better-sqlite3 when in an Node environment (which is hard to detect, see no. 7 above) because, well, it works
• [ ] Setting up devcontainers
• [ ] Replacing it with the native bun:sqlite module when in a Bun environment
• [ ] While we're here, we might as well implement the dozen of native Bun functions that are faster than their Node counterparts.

Counter-arguments to what I just said

See "Bun hype. How we learned nothing from Yarn"

Bun is just an abstraction layer on top of the tools we already have. Meaning it will always be behind the curve and can introduce additional bugs at that layer. Not ideal for such mission critical systems like installing dependencies, testing code, and building the code to be sent to production.

• Bun will stay hyped temporary until the V8 and Node teams catch up to it
• Bun has too much tech debt
• Not supporting Windows, even though v1 was released

@barthofu do what you want with this issue mate, maybe we can make it an actual tracker (and also remove the bug tag pls 👍)

[barthofu]

Nice issue and totally agree on it, I'm also bothered as hell concerning node-gyp but wasn't doubting this was as bad as this.

The thoughts i've had so far:

• I do not want to restrict the use of tscord with deno and/or bun.
• On the other hand, I want to make it as much compatible as possible.
• The culprit here is the better-sqlite3 library, we could revert its use back to the sqlite library which, iirc, doesn't relies on node-gyp.

The thing now is to to weigh the pros and cons of this change, as better-sqlite3 still brings big improvments over the basic sqlite lib.

[barthofu]

Keep having newcomers that are somewhat blocked at the very init step, which is not acceptable.

Solution for now:

• Going back to Mikro-ORMs sqlite database type by default
• Totaly remove the better-sqlite3 library from the dependencies
• Update accordingly the database types auto-resolver
• Write a solid documentation on how to switch from sqlite to better-sqlite for the determined
• Open a discussion and weight the pros/cons of totaly ditching the type resolving thing in the template to simplify it and alleviate a little the dependencies

We should apply this quickly in a v2.4 release, while shifting the current planned features/issues in the 2.5.