Closed brettz9 closed 5 years ago
That's probably a good idea, since 94-96% is better than I currently have.
Without doing an in depth comparison, the only concern I have about IndexedDBShim is that it'd add extra cognitive overhead for my users. Most people using fake-indexeddb just want to do a require
and get on with their unit tests. With IndexdedDBShim, they have to read a big README, notice the option to run it in memory, and then apply the correct options.
If that is a valid concern, then maybe fake-indexeddb could become a simple wrapper around IndexedDBShim for this use case. Same thing I did with realistic-structured-clone - you come along with a better but more complicated project, and I'm reduced to making a simpler wrapper :)
I will keep IndexedDBShim in mind if I want to start working on an IndexedDB implementation again, but as you can see from the lack of recent commits here, it's not a big priority of mine right now. But that could change in the future.
The big advantage of fake-indexeddb
for me is that it plays nicely with mocking timers and running the task queue to exhaustion, which are important in a test environment. Integrating with SQLite, while providing lots of other capability, makes that harder for IndexedDBShim
. I do think that these libraries fill different niches.
In case you weren't aware, IndexedDBShim can also allow Node usage in a manner that creates databases in memory online (or to temporary file): See
memoryDatabase
under https://github.com/axemclion/IndexedDBShim/#user-content-configuration-optionsWe also have a high test passing rate, with about 94% of W3C test files completely passing (96% if excluding exception order tests which have issues due to transaction timing limits from our avoiding synchronous operations).
It'd be great to have extra hands working together on what seems to be similar work or at least hear about any disadvantages you may have found with our project relative to yours...
Best wishes!