Support @vscode/sqlite3

[OlivierCavadenti]

• Actual mapbox sqlite3 have several vulnerabilities (and have no new releases since months) in dependencies so use a vscode fork instead.
• Closes Support @vscode/sqlite3 #4858

[kibertoad]

Why not just use vscode/sqlite3 directly? It's a devDependency anyway, users will have to switch on their end too.

[kibertoad]

I would go one step further and explicitly require users to have vscode version of sqlite and import from that directly, not through alias.
1.0.0, which is a semver major, is perfect for breaking changes like this.

[B4nan]

Peer dependencies are still out of date:

https://github.com/knex/knex/blob/master/package.json#L87

(Can't really say if I like this happening at all, seems quite weird. But what can we do if the original package is not maintained 🤷)

[B4nan]

Apparently there are more things forgotten, e.g. after installation, without having the new sqlite fork switched, I get this error:

Error: Knex: run
$ npm install sqlite3 --save
Cannot find module '@vscode/sqlite3' from 'node_modules/knex/lib/dialects/sqlite3/index.js'

As the driverName is still sqlite3.

[kibertoad]

@B4nan driver name was left unchanged intentionally, so that simple package.json would suffice for migration, as per UPGRADING.md

edit: ok, upgrading instructions are ambiguous. will fix

[B4nan]

I can see quite a lot of failures in schema diffing after upgrade, I can imagine there will be some changes needed also in the reflection of sqlite tables (https://github.com/knex/knex/blob/master/lib/dialects/sqlite3/schema/internal/parser.js).

Namely I see problems with reflection of things like autoincrement, FKs and default values. And some of them are also in mysql tests, so might be something else than this particular change 🤷 Need to spend more time debugging this, it can be easily something on my end (tho everything is working as expected with 0.95).

One thing I noticed is that sqlite queries now automatically include the PRAGMA foreign_keys = OFF/ON; queries, which is something I am already handling myself, and it seems inconsistent (just the temp table queries are using it). Not a big deal, I will need to replace this layer for sqlite with custom code anyway, as the way knex is handling the schema inspection can't work for the MikroORM use case. I can't inspect current schema to generate those temp table statements when generating migrations, the schema might not be up to date yet, and I have all the metadata needed in memory already anyway. For this reason v5 won't provide down migrations automatically for sqlite.

edit: ok, upgrading instructions are ambiguous. will fix

My point is that the error message is wrong, it suggests installing the old sqlite3 package.