Andrew Plaza

> Thanks for providing that context. That's at least helpful to understand why you made this change. For me that raises a more fundamental question: Why do you believe that...

> So just to summarize everything: It's basically required as wa-sqlite bindings generate futures that are not Send, right? Yes, pretty much :) Although I would generalize this -- it's...

That makes sense, and overall a more robust solution. Even with this PR, I had to end up replicating a bunch of the trait definitions to fit them into WASM....

FWIW there is a sqlite crate for rust, with a native rust VFS: https://github.com/Spxg/sqlite-wasm-rs/ SQLX could be potentially interesting here, since it can contribute a rust-native _async_ vfs, maybe based...

To add to this, if the resulting wasm package has errors that look like "Can't resolve 'env' in ../pkg' or similar, the wasm.js tries to "import 'env'", you must disable...

hey! That makes sense. I switched over to just putting wasm-bindgen feature in futures-timer for my project. It does seem like a win to get futures-timer to switch automatically based...

* **#606** * **#603** 👈 (View in Graphite) * `main` This stack of pull requests is managed by Graphite. Learn more about stacking.

> [!WARNING] > This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite....