[question] Is it possible to cover code which uses sqlite-wasm with jest tests?

[doing-art]

I am using Sahpool VFS in my codebase. I am curious whether it is possible to cover my code with tests, e.g., using the Jest library. In the documentation, it is mentioned that Node.js is currently only supported for in-memory databases without persistence. Technically, tests are executed in the Node.js environment. Does it mean that the code that uses Sahpool VFS can not be covered with the tests?

[sgbeal]

In the documentation, it is mentioned that Node.js is currently only supported for in-memory databases without persistence.

Please point out where you read that, as that would be a documentation bug. Our documentation very specifically says that only browser clients are supported.

Technically, tests are executed in the Node.js environment. Does it mean that the code that uses Sahpool VFS can not be covered with the tests?

Both of the OPFS VFSes are browser-only VFSes, so they cannot be tested outside of a browser.

[doing-art]

Thank you for confirming that it is not possible to run tests outside of a browser. I had the same feeling, but now I am confident.

Please point out where you read that, as that would be a documentation bug. Our documentation very specifically says that only browser clients are supported.

It is mentioned on the repository main page on GitHub:

[sgbeal]

If @tomayac is okay making that claim for the npm packages, i'm fine with that, but the upstream project very specifically doesn't develop for or test any server-side use of the JS code.

[doing-art]

@sgbeal So, as far as I understand, it is possible to use an in-memory DB for Node.js testing, right? We are considering it as a workaround. We are planning to use the OPFS for real scenarios and in-memory storage for testing.

[sgbeal]

@sgbeal So, as far as I understand, it is possible to use an in-memory DB for Node.js testing, right? We are considering it as a workaround. We are planning to use the OPFS for real scenarios and in-memory storage for testing.

Officially, node is 100% not supported by the upstream project. i can't say anything definitive about guarantees made solely within the scope of this subproject.

[doing-art]

Ok, thank you anyway. We will try to experiment.

[tomayac]

Node.js support without persistence was added in #48. For something battle-tested, you probably want to use a dedicated Node.js SQLite package.

[sgbeal]

For something battle-tested, you probably want to use a dedicated Node.js SQLite package.

Trivia: one of the reasons i push back on node support in the upstream project is because people tend to reflexively prefer "official" over "unofficial" solutions, and providing "official" node support would (A) possibly disrupt well-established solutions while (B) not being anywhere near as mature as they are, which, in turn, would (C) put me in the unenviable position of having to become a Deep Nodist to catch it up to them, all the while fielding support posts like "wrapper X can do this thing, it would be cool if yours could too." If we had a team of people eager to work with node, that would be one thing, but we're three developers, none of whom use node in any capacity, so we gladly leave All Things Node to those who use it.

[tomayac]

Have you considered hiring for such a position, or have a contractor work on adding support? Or maybe even the open source Node.js SQLite community would be happy to work with you if there's some certainty about getting their contributions merged upstream? But then maybe also this is more of a question of sitting it out: https://nodejs.org/api/sqlite.html.

[sgbeal]

Have you considered hiring for such a position, or have a contractor work on adding support?

That would (A) be up to Richard and (B) would be a large cost for us, with no benefit for the project or its maintainers.

Or maybe even the open source Node.js SQLite community would be happy to work with you if there's some certainty about getting their contributions merged upstream?

Likewise, that would be a huge maintenance burden for us/me (as the team's dedicated JS Guy), with zero benefit for the project and lots of benefit for Someone Else. We'd strongly prefer not to take on other folks' maintenance burdens. (We don't consider "wider usage" to specifically be "a benefit for the project", as wide usage equates to a higher support burden.)

That said: corporate sponsorship is key to getting the project to take on burdens which wouldn't otherwise be part of the project, and any interested parties are encouraged to speak to their financiers about it.