You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Heyho, one of the things that held me back from using jk was the lack of typescript support and then over time I thought about using deno (which supports) TypeScript out of the box in a jk-like fashion.
Turn out at least someone has already thought in this direction: https://github.com/nvbn/l9t.
I was wondering what your thoughts are on basing off jk off deno or make it more deno-like.
In particular the way how packages managed (no need for package.json) and that TS is supported out of the box makes its ergonomics a bit nicer.
The text was updated successfully, but these errors were encountered:
Yeah, deno is an accomplished project, and supporting TypeScript in jk is quite a big job. I was thinking recently about whether the jk library and commands could be ported to use the deno runtime. One advantage lost is that it was quite easy to add e.g., OpenAPI schema validation to jk because it's just an RPC to call into Go code -- this could be harder with deno, both finding an appropriate library in either Rust or JavaScript, and calling it.
Heyho, one of the things that held me back from using jk was the lack of typescript support and then over time I thought about using deno (which supports) TypeScript out of the box in a jk-like fashion.
Turn out at least someone has already thought in this direction: https://github.com/nvbn/l9t.
I was wondering what your thoughts are on basing off jk off deno or make it more deno-like.
In particular the way how packages managed (no need for package.json) and that TS is supported out of the box makes its ergonomics a bit nicer.
The text was updated successfully, but these errors were encountered: