Upgrade dependencies, switch Mocha tests from TS to JS

[raucao]

Adds a new mocha suite for the RemoteStorage class as well, and also refactors some code.

The reason for using JavaScript in tests is that we cannot test the JavaScript usage of RS functions from TypeScript, when the test code doesn't compile due to mismatching types (i.e. when we validate wrong input from JS within the function). Also, it simplifies the Mocha setup and makes it more stable, since even the Mocha/TS combination is rather fragile and building blocks and setup hooks keep changing over time. This dependency upgrade wouldn't have worked with the existing setup for example.

refs #1270

[raucao]

@remotestorage/core If someone could have a quick look at this, it would be much appreciated. 🙏

[raucao]

Could still use a review for merging this...

[silverbucket]

@raucao I'm a little confused by the rationale for switching from TS to JS for tests, when the RS code is written in TS. Can't we simply compile the tests to JS to run against the compiled JS code?

[DougReeder]

Looks good overall, but a few things are unclear; see line notes.

[raucao]

@raucao I'm a little confused by the rationale for switching from TS to JS for tests, when the RS code is written in TS. Can't we simply compile the tests to JS to run against the compiled JS code?

The compilation fails if you pass the wrong type, so you cannot test how the library handles bad input.

[silverbucket]

The compilation fails if you pass the wrong type, so you cannot test how the library handles bad input.

You can use different typing techniques to account for that.

rs.myMethd(badObj as ProperObj) for example.

Or you can go even more extreme, with (badObj as unknown as ProperObj).

Things like that usually work for 90% of cases. For more extreme cases, there are ways to work around it but maybe in a less generic way that described above.

[raucao]

Things like that usually work for 90% of cases. For more extreme cases, there are ways to work around it but maybe in a less generic way that described above.

The point is that there's no need to work around anything for this use case (both for new and existing contributors), and it also fixes dependency issues with Mocha and TypeScript at the same time. Types keep the source code safe and easy to reason about, but have honestly just been in the way most of the time for tests, without enjoying the same benefits.

[DougReeder]

When I run test:mocha, the tests all pass, but I get the message https%3A%2F%2Fnote.app.com%2F&scope=notes%3Arw&client_id=opaque&state=CSRF-protection&response_type=token&code_challenge=ABCDEFGHI&code_challenge_method=plain and the process doesn't exit. Is that an inescapable side effect of testing the timeout?

[raucao]

Is this happening on Node.js 18 and 20? Testing timeouts is indeed a bit tricky, because there's no AbortController for Node's fetch. This can cause the test run to look finished, but take another few seconds to exit after that.

[DougReeder]

Sometimes the tests exit, sometimes they don't. This is using node v18.18.2, v20.11.1 and v21.7.3 under MacOS Sonoma 14.6.1

[raucao]

And it's not happening on master? I.e. it's definitely something caused by the changeset here?

[DougReeder]

And it's not happening on master? I.e. it's definitely something caused by the changeset here?

I'm observing this sometimes on master as well, so it doesn't appear to be anything new.

[DougReeder]

LGTM