If I have interpreted the package.json fields conventions jungle correctly, the "module" field would be a way to point to an ES2015-based module but in all other aspects, only containing ES5-compatible JS code.

Found the issue as I integrated this module into dexie as a devDependencie, using rollup to include it. Rollup is run after transpilation and when it finds the "module" field, it integrates that module into my final ES5 code. When the CI tests sends this to browserstack for IE11 testing - it fails.

I don't know why I'm still maintaining dexie for IE11 though in 2021, but, I'm just in a minor release so I currently need to stick to it.

According to MDN, Safari didn't ship indexedDB.databases() until v14. I can confirm that on iOS 12.5.3, Safari throws an error in this library because the API is missing.

It seems reasonable to me to just return Promise.resolve() for older versions of Safari.

Note: I haven't tested this; I'm submitting it from the github editor.

When using fake-indexeddb with node (for unit testing), safari-14-idb-fix crashes with "ReferenceError: navigator is not defined". If navigator is not defined, then it clearly isn't safari, so I added the existence check.

Getting following error building a sveltekit project. Setting "type": "module" as suggested fixed it:

(node:51281) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
> Cannot use import statement outside a module
/Users/holdph/personal/song-kit/node_modules/idb-keyval/dist/esm/index.js:1
import safariFix from 'safari-14-idb-fix';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at compileFunction (<anonymous>)
    at Object.compileFunction (node:vm:353:18)
    at wrapSafe (node:internal/modules/cjs/loader:1039:15)
    at Module._compile (node:internal/modules/cjs/loader:1073:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1138:10)
    at Module.load (node:internal/modules/cjs/loader:989:32)
    at Function.Module._load (node:internal/modules/cjs/loader:829:14)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:201:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:175:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)
error Command failed with exit code 1.

The ES5 "compat" version of safari-14-idb-fix was actually 2b smaller than the default (modern) version. Since the differences between the two were limited to "function" vs arrows and const vs var, there should also be no measurable performance tradeoff. Simplifying the package by shipping only ES5 will help ease usage in bundlers/runtimes with varying support for Package Exports.

The new directory layout is:

dist/
    index.js  <- ESM
    index.cjs  <- CJS
    iife.min.js  <- IIFE
    index.d.ts  <- types

All are ES5, all are minified via Terser.

This PR simplifies package exports by removing intermediary directories in favor of .js / .cjs for differentiation. This also allows folks to import safari-14-idb-fix/dist/index.cjs directly if desired.

You'll get a DevTools "improvement" suggested for accessing navigator.userAgent. One might realistically expect this issue to be fixed before Safari adds support for navigator.userAgentData, so this feels like a reasonable addition just in case you want to give it a whirl.

Hi, our monitoring tool (trackJS) report us the Promise here:

crashes with an "The operation is insecure" error from time to time, even in "modern" safari browsers (safari 15.4+)

I couldn't manage to recreate the exact error conditions but I believe this might happen when the IndexedDB is disabled in the browser. Is there a check we neeed to add to detect this before it crashes?

I'm running a Cordova app on IOS 14.6 on an iPhone SE and it has the same behavior of hanging on openDB. Was hoping to use this 'function' to add a temporary shim to work around the issue.

However, current code checks for 'Safari' in the UA. In my case, it's in Cordova/Webkit not Safari - so the UA returned is:

Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148.

I'm not sure how wide to expand the test to prevent perf issues on other platforms - maybe 'Safari' and 'AppleWebKit' ? or look at the 14_x version?