"default" is not exported by "../../../Dexie.js/dist/dexie.min.js", imported by "../../../Dexie.js/import-wrapper-prod.mjs".

[nlaurie]

When building via Vite. Getting

x Build failed in 8.15s error during build: RollupError: [vite-plugin-pwa:build] ../../../Dexie.js/import-wrapper-prod.mjs (4:7): "default" is not exported by "../../../Dexie.js/dist/dexie.min.js", imported by "../../../Dexie.js/import-wrapper-prod.mjs". file: /Users/nlaurie/Development/metafig/Dexie.js/import-wrapper-prod.mjs:4:7

Everything go back to building fine when I revert to a previous package.json that looks like this

"production": { "module": "./import-wrapper-prod.mjs", "import": "./import-wrapper-prod.mjs", "require": "./dist/dexie.min.js", "default": "./dist/dexie.min.js" },

[dfahlander]

How does the non-working package.json look? When I look at current one, it has

      "production": {
        "module": "./import-wrapper-prod.mjs",
        "import": "./import-wrapper-prod.mjs",
        "require": "./dist/dexie.min.js",
        "default": "./dist/dexie.min.js"
      },

Seems identical?

[nlaurie]

Left Non Working, Right Working

[nlaurie]

It was a couple months back when the issue cropped in when the wrapper was introduced, I figured it would come up and get fixed with the release of 4. I went through our code and made sure all the imports were consistent. since I've seen this sort of error with libraries that dont have default exports and not using the * notation for the import. import * as xyx from 'lib', but Dexie has default exports. so were using import Dexie from 'dexie'

[dfahlander]

Tried to reproduce just now: https://github.com/dfahlander/dexie-vite-starter
I get it working with a clean vite project with typescript / react and adding dexie and using dexie-react-hooks,

But I saw there was an issue in vite vitejs/vite#2679

Which version of vite are you using?

[nlaurie]

Vite 5.2.11

I switched the wrappers to , and its building with the configuration below. Shouldn't the import, module be using the modern ESM build?

[dfahlander]

If we do, nextjs apps suffer from double instanciating the dexie module (for some reason) and that causes problems as it has static properties that must be singleton instance. Ideally one should isolate state into a stateful module and import that one only as commonjs and the rest as ES.

[nlaurie]

I think I have it. my project is pure ESM
type: "module"

As per https://nodejs.org/api/packages.html#dual-package-hazard

The preceding example uses explicit extensions .mjs and .cjs. If your files use the .js extension, "type": "module" will cause such files to be treated as ES modules, just as "type": "commonjs" would cause them to be treated as CommonJS. See

your load in the wrapper needs to be expliclity [.cjs] in order for this technique not to blow up on pure ES projects.
import _Dexie from "./dist/dexie.min.cjs";

Which is why its importing as a ES and not commonjs resulting in default export not found.

[dfahlander]

Thanks for this finding. Not sure how to properly proceed though. The path dist/dexie.min.js is expected to be there by other docs and samples, for example when including dexie in a legacy script include.

I wonder if adding {"type": "commonjs"} in dexie's package.json would fix it. However, I would suppose "commonjs" is the default when "type" isn't specified so I'm not sure why vite is applying your project's "type" into dexie's type... I would suppose that vite is doing it wrong in that respect. This is a really mined area where any change can get things blown up for various configurations. I really regret adopting es module format too early, it has cause so much problems so far.

[nlaurie]

Here is the rub, We unlinked from our fork https://github.com/metafig/Dexie.js and reverted to the npm release. (built and ran as expected)

It must be something specific to loading directly off the locally built fork. (Which sucks cause it hinders our ability to help contribute to issues.)

Were still running off our fork https://github.com/metafig/dexie-encrypted so we can keep that project moving forward.

I added the local pnpm link into your starter project and it failed as expected.
https://github.com/metafig/dexie-vite-starter

[dfahlander]

I see. Seems as a vite bug then. Would it be a way forward if your fork of Dexie.js would have a step in its build process to copy dexie.min.js to dexie.min.cjs and change package.json?

[nlaurie]

I confirmed the linking issue , set up a clean new fork under our launch organization
https://github.com/asset-view/Dexie.js dexie-vite-starter does not build properly with the new link. At least we have have a simple repo.

Funny Enough you ask about that , We went as far as renaming all the release files to .cjs and modifying the wrappers etc. Everything built fine, BUT ... When we ran the SPA when the browser went to load the wrapper file it reported that the default export was not there at runtime. Just pushed the issue down the road. Vite is definitely may not be doing something during the packing to handling this commonjs wrapper node hack for dual environments. OR the local build is somehow different than the release build?

Honestly I'm a bit baffled with how it's all getting loaded etc. and why is the release build is working !

[KittenApps]

Getting the same error here using rollup (in esm only mode) directly.

Could you maybe just add "./dist/dexie.mjs": "./dist/dexie.mjs" to the package.json export field, so we can import("dexie/dist/dexie.mjs") directly without getting a Could not resolve import "dexie/dist/dexie.mjs" in [...] using exports defined in [...]/node_modules/dexie/package.json. error.

[rednil]

I have the same problem in a pure ESM project, no frameworks or packaging involved. I just updated from 3.2.2 to 4.0.7, now I am getting

Uncaught (in promise)
SyntaxError: The requested module './dist/dexie.js' does not provide an export named 'default' (at import-wrapper.mjs:4:8)

in the browser console.
I am just consuming dexie as a module via
import Dexie from 'dexie'

[dfahlander]

I have the same problem in a pure ESM project, no frameworks or packaging involved. I just updated from 3.2.2 to 4.0.7, now I am getting

Uncaught (in promise)
SyntaxError: The requested module './dist/dexie.js' does not provide an export named 'default' (at import-wrapper.mjs:4:8)

in the browser console. I am just consuming dexie as a module via import Dexie from 'dexie'

Pure esm cannot load cjs modules. Import-wrapper is a workaround for node-based clients to avoid dual package hazard. For pure esm clients, import dist/dexie.mjs or dist/modern/dexie.mjs

[tobiasBora]

Not sure to understand, is there a solution to this problem? I need to maintain my own fork, at least until #1973 gets merged, and I have no idea how to make npm build work… In my use case, I have a standard vite installation (sveltekit), and I use npm link to link to dexie.js

[KittenApps]

change your imports from "dexie" to "dexie/dist/dexie.mjs"

[tobiasBora]

Great thanks a lot, I thought this would only apply for a specific way of compiling… And it actually solves multiple weird bugs, including a really weird bug that my system was not using the proper Dexie version. I actually changed it globally by adding in my vite.config.ts:

export default defineConfig({
  resolve: {
    alias: {
      'dexie': 'dexie/dist/dexie.mjs',
      'dexie-export-import': 'dexie-export-import/dist/dexie-export-import.mjs'
    }
  },
});

Thanks!