mirror of
https://github.com/aljazceru/turso.git
synced 2025-12-25 12:04:21 +01:00
e4d4e5cd5d
In order [experimentally compile](https://github.com/DougAnderson444/wit-limbo) `limbo_core` to a [wasm component](https://component-model.bytecodealliance.org/), limbo needed to have no reliance on `js`, `js-sys`, `wasm-bindgen`, et al. (for those who aren't familiar, there are many `wasm` runtimes and not all of them play nice with `wasm-bindgen`) This PR simply cleans up the dependencies, and puts them behind optional flags and whatnot in order to enable this. Both `log` and `tracing` were being used, so I reduced this only to `tracing`. End result is limbo can be used like this: https://github.com/DougAnderson444/wit-limbo We can open a discussion on the possibilities that running limbo as a wasm component can offer, including potentially using composable components to implement the sqlite runtime extensions, as well as giving us a clean interface for PlatformIO operations -- define them once, implement many ways on various platforms. I'm new to limbo, but it looks like current extension are Rust based deps and features flags, whereas sqlite is runtime, right? What if limbo was runtime extensible too? The WIT interface is largely sync (though I believe wasmtime has an async feature), but in my limited exposure to limbo so far a lot of the wasm seems sync already anyway. Again, topic for further discussion. Suffice to say, aligning these deps in this way paves the road for further experiments and possibilities. Related: https://github.com/neilg63/julian_day_converter/pull/2 Related: https://github.com/tursodatabase/limbo/issues/950 Closes: https://github.com/tursodatabase/limbo/issues/950 Closes #983