Issue 1:
see the screenshot

❯ deno --version

deno 1.19.1 (release, x86_64-apple-darwin)

v8 9.9.115.7

typescript 4.5.2

test.js is

// Generated by CoffeeScript 2.6.1
(function() {
//!/usr/bin/env coffee
var i, ref;

ref = [1, 2, 3, 4, 5];
for (i of ref) {
console.log(i);
if (i > 3) {
throw new Error(i);
}
}

}).call(this);

//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoidGVzdC5qcyIsInNvdXJjZVJvb3QiOiIuLiIsInNvdXJjZXMiOlsic3JjL3Rlc3QuY29mZmVlIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7QUFBcUI7RUFBQTtBQUFBLE1BQUEsQ0FBQSxFQUFBOztBQUVyQjtFQUFBLEtBQUEsUUFBQTtJQUNFLE9BQU8sQ0FBQyxHQUFSLENBQVksQ0FBWjtJQUNBLElBQUcsQ0FBQSxHQUFJLENBQVA7TUFDRSxNQUFNLElBQUksS0FBSixDQUFVLENBQVYsRUFEUjs7RUFGRjtBQUZxQiIsInNvdXJjZXNDb250ZW50IjpbIiMhL3Vzci9iaW4vZW52IGNvZmZlZVxuXG5mb3IgaSBmcm9tIFsxLi41XVxuICBjb25zb2xlLmxvZyBpXG4gIGlmIGkgPiAzXG4gICAgdGhyb3cgbmV3IEVycm9yIGlcbiJdfQ==
//# sourceURL=/Users/z/rmw/rcp/test/src/test.coffee```

Issue 2:
So far I have been watching node compatibility features, wasm features, and ffi features all to serve one purpose for myself, to expose a a reliable, fast sqlite interface in deno. There are several good sqlite implementations that exist in deno userland thus far:

https://deno.land/x/sqlite (a wasm compilation)

https://deno.land/x/sqlite3 (an ffi binding)

https://github.com/denodrivers/async-sqlite3 (ffi bindings using rusqlite)

These projects are usable, but they all have their own pitfalls. The wasm libraries are portable, but suffer a reduction in speed, and their memory usage is capped at 4GB. The FFI libraries are generally faster, but still cannot match native bindings, and have an added difficulty of requiring an external dependency. Developers of FFI libraries also have the headache of dealing with end users using different versions of sqlite underneath their js interface.

Here is a small benchmark report given by the async-sqlite3 library:

insert 10_000 rows in bench.db: 1114.5801ms
query 10_000 rows in bench.db: 30.3004ms

x/sqlite3
insert 10_000 rows in bench.db: 1306.1578ms
query 10_000 rows in bench.db: 163.2021ms

node-sqlite3
insert 10_000 rows in bench.db: 1165.0645ms
query 10_000 rows in bench.db: 8.1728ms

better-sqlite3
insert 10_000 rows in bench.db: 592.1117ms
query 10_000 rows in bench.db: 11.3483ms

x/sqlite
insert 10_000 rows in bench.db: 28672.3261ms
query 10_000 rows in bench.db: 16.8747ms

Wherever I see a javascript interface to sqlite, better-sqlite3 always seems to win out. It uses NAN (Native Abstractions for Node.js). Deno already includes a rusqlite implementation inside it for things like localStorage, so exposing the library to users would not require pulling more dependencies into deno, just exposing more of the underlying systems. I feel (but dont know for certain) that if we had native rust v8 bindings to a library inside deno core, we could achieve some very impressive speeds, and avoid some of the traps that come with wasm compilations.

The interface could be very simple, just exposing prepared statements, database open & close and query execution. That alone would allow deno developers to write their own database abstractions with a solid foundation. The existing sqlite library authors do not need to go away if this is implemented,. Of course, an STD implementation of a sqlite database would be fantastic, but I think starting with the building blocks here makes the most sense.

drawbacks to deno exposing rusqlite

So far as I can tell, here are the arguments against this:

This is another interface to maintain, and localStorage has its own special considerations, so making rusqlite exposed generically would be difficult

being able to pick and choose your version of sqlite is actually a feature, not a bug. Tying sqlite version to the deno version limits the flexibility of sqlite

I think these are valid points, but they certainly wouldnt be true for me, but Ill let others speak to their own concerns.