[joker-777]

Migrations on the web (LokiJS) had no way to drop a table or change data: unsafeExecuteSql() steps are silently ignored there. A table dropped with SQL stays in IndexedDB and is loaded and parsed on every launch.

Changes

• New destroyTable({ table }) migration step for both adapters. SQLite runs DROP TABLE IF EXISTS, so it's a no-op for a table that was already dropped with unsafeExecuteSql(). LokiJS removes the collection and deletes its chunks from IndexedDB, including leftover chunks of a collection that's no longer in Loki
• The chunks are deleted in the same IndexedDB transaction that saves the Loki metadata without the collection. The persisted database stays consistent if the page closes mid-way, and a table that is destroyed and created again in one migration keeps its new data
• New unsafeExecuteLoki(loki => {}) step, the LokiJS counterpart of unsafeExecuteSql(). It runs against the Loki instance during the migration and is ignored on SQLite. It can't be sent to a web worker, so LokiJSAdapter throws a clear error when it's used with useWebWorker: true
• LokiJS logs a warning for each ignored unsafeExecuteSql() step, with the first 200 characters of the SQL
• A failed LokiJS migration is no longer autosaved. Steps that ran before the failure changed the database in memory; now it's not saved, so the persisted database stays at the old version and the steps don't run twice next time
• Migration syncs (getSyncChanges) accept the new steps, and skip tables and columns destroyed later in the range
• destroyTable() rejects local_storage in any letter case

Loki's own removeCollection() throws for collections that IncrementalIndexedDBAdapter loaded lazily, so the driver removes the collection from loki.collections directly. Deleting the chunks relies on internals of the IncrementalIndexedDBAdapter in the lokijs version this repo pins. If they're missing, a warning is logged and the chunks are kept.

Tests

• New src/adapters/lokijs/migrations.test.js, using fake-indexeddb and the real IncrementalIndexedDBAdapter. It checks the persisted IndexedDB keys after each migration: the destroyed table's chunks are gone; leftover chunks of a collection already missing from Loki are deleted; destroy plus create in one migration keeps the new data across later saves; and a failed save is retried with the old chunks intact until it succeeds. It also covers the SQL warning and unsafeExecuteLoki()
• New shared adapter test destroys tables in migrations, which runs on LokiJS and SQLite
• Unit tests for encodeMigrationSteps, getSyncChanges and the step constructors
• Adds fake-indexeddb@^6.2.5 as a dev dependency

Verification

• On this branch: Jest passes on the host (80 suites). flow check is clean, and ESLint is clean on the changed files. The sqlite-node suite was run separately in a Node 22 container, because better-sqlite3 doesn't build on the host's Node; all 122 tests pass there
• Independent of our other open PRs. It merges with [LokiJS] Report persistence failures and allow refusing in-memory fallback #1979, [LokiJS] Fix unsafeResetDatabase failing while an autosave is in progress #1980 and [LokiJS] Opt-in exclusiveLock: one tab at a time holds the database #1989 with one trivial conflict in lokiExtensions.js, where both add a function at the same place

🤖 Generated with Claude Code

[StasDoskalenko]

Hi @joker-777, thank you for this!

I maintain NitromelonDB, a maintained fork of WatermelonDB (New Architecture, Nitro Modules). Something that might interest you: on the web, our SQLiteAdapter now runs SQLite compiled to WASM (wa-sqlite) in a web worker, stored in IndexedDB. It's the same import and adapter as on native. Migrations run the same SQL on the web as on device, so unsafeExecuteSql() steps (including DROP TABLE) just work there, without a Loki-specific escape hatch. More details are in the wa-sqlite adapter docs. One caveat: existing LokiJS data in the browser is not migrated automatically.

A destroyTable migration step would still be lovely to have on all adapters, so a PR against our repo would be very welcome. Our fork was rewritten in TypeScript (strict mode) to reduce the chance of bugs slipping through, so I think the community would really benefit if you opened your PRs against it too.

If you don't have the time or would rather not, no worries at all, I'm happy to port it myself. Just let me know. Thanks a lot!