Closed steida closed 2 years ago
Once Kysely is deno and browser compatible, we should add some kind of automatic tests that make sure it stays that way. Browsers can be tested pretty easily using puppeteer or playwright. Deno is trickier.
Should be fairly simple to add a github actions step that runs deno.
And thanks, it runs straight away now 👍 I'm currently debugging it in actual runtime, I copied the postgres driver and replaced pg
with https://deno.land/x/postgres/mod.ts
. Still getting some errors so trying to figure out if that's because of me or not.
Alright it works now, I published the driver here https://deno.land/x/kysely_postgres
I had not published any deno modules yet so mainly trying to see how it works. We might be able to move it to this repo, deno land accepts a subdirectory so you could expose the node-less code along with deno drivers from a /deno
directory and publish it to deno land quite easily.
Awesome! I think you could import PostgresIntrospector
, PostgresAdapter
and PostgresQueryCompiler
directly from Kysely
instead of re-implementing them in the library. As far as I can see, they are identical?
I don't know if we should move the driver to this repo though. It will end up being something I have to maintain, and I've never used deno, and have no plans to use it in the near future. I'm not the right person to maintain deno code.
Ah yes that makes sense i'll change that. Also I'm a bit worried about how the driver package now depends on kysely which can cause a version mismatch with a project using both. This is something that in node, npm's peer dependencies would solve but I don't think deno can do the same that easily. It would also be possible to make a generic kysely
deno package and re-implement all the drivers to get around it, then you can also export the core lib from there and have no version mismatch, with downside that the deno package needs to be updated for every new version.
Either way, it works now, even if implementation details are not perfect. Thanks for your efforts, would be cool if some of the other participants in this thread could also see if their browser use cases work now :)
I just added an esbuild+browser smoke test here. It simply tests that kysely (bundled with esbuild) can be run in a browser and some query can be built.
Now there's a smoke test for deno and I've even added a mention of browser and deno support to the readme.
Now there's a smoke test for deno and I've even added a mention of browser and deno support to the readme.
You could make it use local paths instead of CDN to actually test the current commit instead of the last published npm version?
Should work pointing directly at the typescript entry point could also build first and use dist so it will also test the build version as consumers would use it
Yep, there are million ways to improve that, but it's not trivial. For one thing, I didn't know how to create a github action that has both node and deno installed (could probably just run apt install deno
or something). I also want to have the current test to make sure there's at least one cdn that works. PR would be awesome!
Now there's also a local deno test.
@koskimas Thank you very much for all your work.
@steida @midwesterntechnology hey, do any of you guys have a working sql.js/absurd dialect implementation and would like to share?
@mszczepanczyk I use https://github.com/koskimas/kysely#browser example with a custom worker.
I know it's not Kysely goal to be multi-platform aka universal, still, I believe it would be a very nice addition with relatively minimal effort. With the advent of local-first software, especially awesome SQLite, it would be nice to be able to use Kysely in browsers or React Native without hacks.
I'm opening an issue because this can be helpful for someone else. Maybe it should be mentioned in the readme.
From the architectural point of view, I don't see a reason why a typed string builder should depend on Node.js at all. The single-responsibility principle FTW.