WONDERFUL!!! Some Complements & Question.

[SemAiSoft]

Wow, this looks soo promising - I would really like to give it a try.
I have few questions though:

1. Is this REALLY production ready?
2. Since you implemented some MongoDb-like query apis, have U thought of aggregation? How do I implement it?
3. What do you think of using the battle-tested mingo lib for advance queries?
4. What of using worker_threads for enhanced file ops and offloading off the main thread?

In the meantime, Kudos To U Man, U are GREAT.

[Xzdes]

Hi! Thank you for your interest in WiseJSON and for these thoughtful questions. It’s great to see such constructive feedback. Here is my take on each point:

Is it production-ready?
I am already using WiseJSON in my own production projects. So far, no issues have been reported by users. The core focus was on data integrity (WAL, fsync, locks), so it's built to be much more stable than standard JSON-based storages.

About Aggregations:
Currently, the documentation covers basic CRUD and filtering (like $gt, $in, etc.). Full aggregation pipelines (like in MongoDB) are not yet implemented.
How to implement it now: You can use .select() to get the data and then use standard JavaScript reduce/map/filter for complex calculations. However, I am considering adding a native aggregation API if there is enough demand.

About Worker Threads:
This is an interesting idea for offloading heavy JSON parsing/stringifying. However, my main concern is maintaining the strict reliability and atomicity that WiseJSON guarantees. Moving file operations to workers might introduce race conditions or complexity in lock management. I need to research this deeper before implementation to ensure it doesn't compromise data safety.

About Mingo:
I haven't considered using Mingo yet. My goal was to keep the library lightweight and gather feedback on what features are truly necessary before adding heavy dependencies. But I'm open to suggestions!

[SemAiSoft]

Hi! Thank you for your interest in WiseJSON and for these thoughtful questions. It’s great to see such constructive feedback. Here is my take on each point:
Is it production-ready?
I am already using WiseJSON in my own production projects. So far, no issues have been reported by users. The core focus was on data integrity (WAL, fsync, locks), so it's built to be much more stable than standard JSON-based storages.
About Aggregations:
Currently, the documentation covers basic CRUD and filtering (like $gt, $in, etc.). Full aggregation pipelines (like in MongoDB) are not yet implemented.
How to implement it now: You can use .select() to get the data and then use standard JavaScript reduce/map/filter for complex calculations. However, I am considering adding a native aggregation API if there is enough demand.
About Worker Threads:
This is an interesting idea for offloading heavy JSON parsing/stringifying. However, my main concern is maintaining the strict reliability and atomicity that WiseJSON guarantees. Moving file operations to workers might introduce race conditions or complexity in lock management. I need to research this deeper before implementation to ensure it doesn't compromise data safety.
About Mingo:
I haven't considered using Mingo yet. My goal was to keep the library lightweight and gather feedback on what features are truly necessary before adding heavy dependencies. But I'm open to suggestions!

Wow, thank you for the fast reply. You are structured!

1. About the worker threads, I fully agree with your concerns, I will wait.
2. "Production ready and mingo": I am requesting this cos, I am planning on going 100% in, on my next project, and mingo - I believe will save US from re-inventing the wheel for all these operators (of course, except when there OBVIOUS ADVANTAGE, e.g in performance").
3. AGGREGATION & DOCUMENTATION: thanks on pointing out the direction, the challenge left is me NOT UNDERSTANDING the documentation at all - can't read it. For example, the select method you just mentioned CAN'T be FOUND in my attempted translation to ENGLISH. Looks like I can't trust the AI's to properly tell me what the DOCUMENTATION is saying. WHAT DO I DO? What if I want to contribute to this wonderful lib?

MY ACTUAL USE CASE?

1. App's data will continue to grow. For example, in one collection I currently have about 300,000 thousand data in a collection. That data comes from four years of daily use.
2. As you can see, it's already a production app, so I want something I can really trust. And this your library PROMISES the exact specs I am interested in.
3. And aggregation? IT'S FUNDAMENTAL to my apps, not a second voice. So?
4. THE DOCS AGAIN, and not only it! Even thrown errors are not in ENGLISH!

[SemAiSoft]

Oh, and TypeScript supports?

[Xzdes]

My apologies, I got confused with the method names.
English is not my native language, so I made a mistake in my previous reply. There is no .select() method. The correct methods for querying are .find(filter) and .findOne(filter).

About the documentation:
I've provided all the documentation files in the repository. Even if they are in Russian, you can simply feed them into an AI (like ChatGPT or Claude) — it will explain everything perfectly in English.

Project status and updates:
The project is not perfect, and I'll be honest: I am not planning to add major features (like aggregations or worker threads) in the near future. Right now, I am only in the "gathering feedback" stage.

About TypeScript:
I am not adding TypeScript at the moment because it would require a massive refactor and too much work.

I appreciate your interest and your offer to help, but I won't be able to dedicate time to major changes anytime soon.

[Xzdes]

I want to be clear about the purpose and scope of this project.
WiseJSON was created as a lightweight library for basic data durability. I personally use it only for small tasks where losing data isn't a total disaster, but would be very annoying. The goal was to have a simple tool to avoid the hassle of setting up "heavy" databases.
Regarding your scale: the library should be able to handle 300,000 records. It is built to pull through that amount of data, provided you use indexing correctly.
However, if you already have a project with such serious requirements and you need advanced features like built-in aggregations or TypeScript, WiseJSON might feel too simple for you. If your use case is mission-critical and very "serious," you should probably stick to established professional databases. I am currently just gathering feedback and don't plan to add heavy features or a TS refactor in the near future.

[SemAiSoft]

Ooook, I got it now. I understand the scope of this lib and the limitations. Still, since this will be used as local-first db, and data will be backup or sync (thanks, you have that included) to a server, I CAN GO WITH IT.

Now, I have a few requests.

1. I would like to convert this to a Typescript library. Might not be instant, but I will give it try. Can I?
2. The docs too, and code comments, I will translate them to English. Can I?

Of course, I will try them offline, and if it work out, I will show you for further procedure IF ANY. Do I have the permissions?

[Xzdes]

Hey! Glad to hear that.

Of course, you have my green light! It’s Open Source, so you don’t even need to ask — feel free to go for it.

About the docs and comments: That would be a huge help. Translating everything into proper English is exactly what the project needs right now, so I’d really appreciate that.

About TypeScript: It’s a massive task, but if you’re up for it, I’m not stopping you. Just a heads up — I’m pretty busy, so I won't be able to review a huge Pull Request quickly. But I’ll definitely check it out when I have a moment.

Just fork the repo and do your thing. I’m curious to see what you come up with. Good luck!

[SemAiSoft]

Hey! Glad to hear that.
Of course, you have my green light! It’s Open Source, so you don’t even need to ask — feel free to go for it.
About the docs and comments: That would be a huge help. Translating everything into proper English is exactly what the project needs right now, so I’d really appreciate that.
About TypeScript: It’s a massive task, but if you’re up for it, I’m not stopping you. Just a heads up — I’m pretty busy, so I won't be able to review a huge Pull Request quickly. But I’ll definitely check it out when I have a moment.
Just fork the repo and do your thing. I’m curious to see what you come up with. Good luck!

DONE! DONE!! DONE!!!

[Xzdes]

Hi! Thanks for the PR — but I can’t approve it in its current form.

Issues / blocking points:

GitHub shows a “hidden or bidirectional Unicode text” warning in this PR. This is a serious security red flag.

The PR changes the tests and explicitly excludes CLI tests, which reduces coverage of a critical area.

The migration introduces parallel JS and TS implementations (new src/**.ts while the legacy JS is still present/modified). This creates two sources of truth, and they will drift over time.

Switching the package to ESM (type: module) is a breaking change for CommonJS (require) users.

Tooling changes (pnpm/workspace, CI/build changes) are supply-chain sensitive and should be reviewed separately.

Given the scope: if the goal is a full modernization to TypeScript + ESM with new architecture/tooling, I strongly recommend doing it as a separate project rather than rewriting this repository in one large PR.

Unfortunately I didn’t have time to verify everything in detail, but I think you’ll be able to make it work. Building your own library is a good idea so mine doesn’t lose backward compatibility. You’ve done a huge amount of work — well done, and thanks for sharing!

[SemAiSoft]

Hi! Thanks for the PR — but I can’t approve it in its current form.

Issues / blocking points:

GitHub shows a “hidden or bidirectional Unicode text” warning in this PR. This is a serious security red flag.

The PR changes the tests and explicitly excludes CLI tests, which reduces coverage of a critical area.

The migration introduces parallel JS and TS implementations (new src/**.ts while the legacy JS is still present/modified). This creates two sources of truth, and they will drift over time.

Switching the package to ESM (type: module) is a breaking change for CommonJS (require) users.

Tooling changes (pnpm/workspace, CI/build changes) are supply-chain sensitive and should be reviewed separately.

Given the scope: if the goal is a full modernization to TypeScript + ESM with new architecture/tooling, I strongly recommend doing it as a separate project rather than rewriting this repository in one large PR.

Unfortunately I didn’t have time to verify everything in detail, but I think you’ll be able to make it work. Building your own library is a good idea so mine doesn’t lose backward compatibility. You’ve done a huge amount of work — well done, and thanks for sharing!

Good enough. I didn't expect you to attend to it right away, you have made yourself clear before. Attend to it anytime you see fit or pick whatever you need from it. I have two options: use this as an internal lib for my projects OR post it as a separate npm package. Anyways and once again, thanks for the background work.