Publish on npm?

[nolanlawson]

I think to do this, the only thing you have to do is add a package.json with the main pointing to idb-iegap.js.

We may or may not want to start using this in PouchDB, because this looks like a fabulous solution for the lack of multiEntry in IE, and the size (<5KB min+gz) is really not too bad at all. Especially given that we would probably have to write 5KB ourselves to work around the issue. :smiley:

[dfahlander]

Hi Nolan,

Nice if it could be of any help for PouchDB. I still must flag that issue #4 is a nasty thing that I would need to solve fully before it's really reliable. I've started to rewrite the shim in total in order to solve issue #4 but that work is kind of paused since I was focusing more on Dexie for a while. There's not been so much "desire" out there for this little shim yet. Maybe that's why it got a bit stalled. Let's see what I could do the coming weeks.

Nice to have a little chat at github! Looking forward to meet you in person in the end of June :) Cheers! David

[nolanlawson]

Hm, I didn't even realize you could fetch an object without waiting for onsuccess. :) So I guess this wouldn't be such a big deal for us; we can just use our existing code.

In my mind, this shim is very useful, because on those platforms where IDB actually works (let's not talk about Safari...), multiEntry can be a great win for performance, so IE is a real bummer. For context: I'm working on a rewrite of PouchDB's secondary index system, and I want to use multiEntry because the cross-platform alternative (a separate objectStore just to map keys to values, ugh) would drag Chrome and Firefox down for the sake of IE.

If you do rewrite this shim, it would be neat if it were possible to use only the multiEntry shim (as opposed to the compound index shim, which we wouldn't use). :smile: But if not, then no big deal; we can just include the whole thing, and 5mb is not so bad.

And yeah, looking forward to meeting you in June! :smiley: