Comments (17)
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.
from dexie.js.
change your imports from "dexie"
to "dexie/dist/dexie.mjs"
from dexie.js.
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?
from dexie.js.
Left Non Working, Right Working
from dexie.js.
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'
from dexie.js.
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?
from dexie.js.
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?
from dexie.js.
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.
from dexie.js.
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.
from dexie.js.
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
from dexie.js.
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?
from dexie.js.
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 !
from dexie.js.
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.
from dexie.js.
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'
from dexie.js.
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
from dexie.js.
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
from dexie.js.
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!
from dexie.js.
Related Issues (20)
- bulkDelete() for large number of primary keys is way too slow
- WebPush for DexieCloud Feature Request
- Dexie Cloud feature request: in-app invitations HOT 1
- dexie cloud db entries with image blob disapear HOT 2
- Return only one field?
- Typescript complain with compound ID HOT 2
- related tables in dexie HOT 2
- Dexie Cloud Manager - "Manage users" error HOT 3
- Authentication error with the fresh.deno framework HOT 1
- Issue with Dexie's table.where() Method when Targeting Existing IndexedDB with Indexed KeyPath
- Transaction context is lost when running a recursive call in a loop HOT 8
- Backwards compatibility issue - ReferenceError: queueMicrotask is not defined HOT 2
- circularly reference on update HOT 10
- dexie-cloud feature request: Transaction support on REST API HOT 3
- Incomaptibility between Dexie.js v4.0.7 and @opentelemetry/context-zone 1.18.1 even with forcing last version of zone.js version 0.14.6 HOT 2
- chrome-specific error occurs on iOS PWA (UnknownError / DatabaseClosedError / Need to reopen db) HOT 1
- Get result as map
- Bulkadd method called second time, doesnt succeed neither fail HOT 1
- Dexie returns duplicated object after manually deleting the database and re-populate it. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dexie.js.