For we works like this

// lowdb.d.ts
declare module "lowdb/node" {
  export * from "lowdb/lib/node";
}

import { LowSync } from "lowdb";
import { JSONFileSync } from "lowdb/node";

const db = new LowSync(new JSONFileSync<{ items: { name: string }[] }>("data.json"));

Same issue here with plain Typescript. This is a deal breaker for me. Something so basic (even shown in the official tutorial) should work with absolutely no issues. Abstract this problem away. Too much configuration from the get-go

have the same issue, unfoutrnly setting moduleResolution to ‘nodenext’ is casuing other issues in my application 😦

I believe this has something to do with the ts es module resolution strategy. I ran into the issue too, but I switched my project to pure esm config later and everything works. I suggest using the latest typescript version and setting moduleResolution to NodeNext in your tsconfig.json:

{
  "compilerOptions": {
    "moduleResolution": "NodeNext",
  }
}

I ran a quick test using @tkafka 's repo: https://github.com/tkafka/lowdb-node-fail

The default moduleResolution is node, if you run npx tsc --noEmit --traceResolution | grep -A50 -m1 lowdb/node, the output will be something like this:

======== Resolving module 'lowdb/node' from '/home/secant/lowdb-node-fail/services/db.ts'. ========
Explicitly specified module resolution kind: 'NodeJs'.
...
======== Module name 'lowdb/node' was not resolved. ========
...

If you change moduleResolution to nodenext, and run the trace command again, the output will be:

======== Resolving module 'lowdb/node' from '/home/secant/lowdb-node-fail/services/db.ts'. ========
Explicitly specified module resolution kind: 'NodeNext'.
...
File '/home/secant/lowdb-node-fail/node_modules/lowdb/lib/node.d.ts' exist - use it as a name resolution result.
Resolving real path for '/home/secant/lowdb-node-fail/node_modules/lowdb/lib/node.d.ts', result '/home/secant/lowdb-node-fail/node_modules/lowdb/lib/node.d.ts'.
======== Module name 'lowdb/node' was successfully resolved to '/home/secant/lowdb-node-fail/node_modules/lowdb/lib/node.d.ts' with Package ID 'lowdb/lib/node.d.ts@5.0.5'. ========
...

which suggests the module resolution succeeded.

And if someone doesn’t add type: "module" in his package.json or doesn’t use .mjs file extensions, which means he wants to import an es module in a commonjs module, then he will have to use dynamic import: https://stackoverflow.com/a/70396888/4668057

@Smiley43210 You should use nodenext for moduleResolution in tsconfig.json, like I said here: https://github.com/typicode/lowdb/issues/554#issuecomment-1293154430

Same problem in NestJS (not NextJS). Changing moduleResolution breaks all other imports.

Can you try setting "type": "module" in your package.json? Here’s also how you can test locally:

package.json

{
  "name": "lowdb-test",
  "version": "1.0.0",
  "type": "module",
  "dependencies": {
    "lowdb": "^5.0.5"
  },
  "devDependencies": {
    "@sindresorhus/tsconfig": "^3.0.1",
    "typescript": "^4.8.4"
  }
}

tsconfig.json

{
  "extends": "@sindresorhus/tsconfig",
  "compilerOptions": {
    "outDir": "./lib"
  }
}

src/index.ts

import { Low } from 'lowdb'
import { JSONFile } from 'lowdb/node'

/tmp/lowdb-test is 📦 v1.0.0 via  v19.0.0 
❯ npm x tsc
src/index.ts:1:1 - error TS6133: 'Low' is declared but its value is never read.

1 import { Low } from 'lowdb'
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~

src/index.ts:2:1 - error TS6133: 'JSONFile' is declared but its value is never read.

2 import { JSONFile } from 'lowdb/node'
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 2 errors in the same file, starting at: src/index.ts:1

yeah I second @weoreference First I thought this package would be very nice to have as mock database on local machine. But just trying to install / fix

import { JSONFile } from 'lowdb/node';

is just breaking everything in my code. to bad 😦

It’s totally unusable. If we don’t fix this

Another option is to patch up lowdb (and leave everything else alone):

1. npm i -D patch-package (if you don’t already have it)
2. add export * from './node.js' to the end of node_modules/lowdb/lib/index.js and node_modules/lowdb/lib/index.d.ts
3. npx patch-package lowdb
4. add "postinstall": "patch-package" to scripts in package.json (if you don’t already have this or something to that effect)

The last step ensures that everytime you reinstall modules you will get that patch reapplied.

You will now be importing JSONFile from lowdb, ie. import { Low, JSONFile } from 'lowdb';

@colining

Here you are importing JSONFileSync from the wrong path. Check usage here.

- import { JSONFileSync, LowSync } from "lowdb";
+ import { LowSync } from "lowdb";
+ import { JSONFileSync } from "lowdb/node"; // in electron

// background.js
import { LowSync } from "lowdb"
import { JSONFileSync } from "lowdb/node"

This dependency was not found:

* lowdb/node in ./src/background.js

To install it, you can run: npm install --save lowdb/node

not work in electron

Could you please retry with lowdb v6.0.1 which contains @Krak798’s fix #569

Still have some problem in electron

it works now @typicode 😃

Could you please retry with lowdb v6.0.1 which contains @Krak798’s fix #569

I think this is related to https://github.com/microsoft/TypeScript/issues/50794

Just as @GrinZero did I got it working but with

declare module 'lowdb/node' {
  export * from 'node_modules/lowdb/lib/node';
}

try this solution:

useage

import { JSONFile } from 'lowdb/node'
import type { JSONFile as JSONFileType } from 'lowdb/lib/node'

type DBData = {
  hosts: string[]
}
const adapter = new JSONFile<DBData>(path.join(USER_DATA_PATH, 'db.json')) as JSONFileType<DBData>

.d.ts

declare module 'lowdb/node' {
  export function JSONFile<T>(path: string): void
}
// you can add more

I took this plan back, not because I couldn’t run. It’s because I really don’t think it’s necessary to insist on using such a bad type system, and the demo can’t be opened

I’m able to reproduce this with just lowdb + TypeScript. See https://github.com/Smiley43210/cannot-find-lowdb for minimum repro.

lowdb@5.05 typescript@4.8.4

I am not sure if the case matters

Both nodenext and NodeNext are fine 😃

However, the build still seems to fail:

That’s disappointing. My guess is that there are some inconsistent behaviours.

Do you think I should report this to Next.js instead?

There seems to be already several issue and discussions: https://github.com/vercel/next.js/issues/35572 https://github.com/vercel/next.js/discussions/41189