Mirror of forum.nim-lang.org

2491 :: dts2nim: A TypeScript -> Nim bridge

• mcc (orginal) [2016-08-26T03:04:33+02:00] view original

  Hello. I wanted to make a little announcement post for a project I've been working on. It's called "dts2nim" and it's a way of bridging between TypeScript and Nim.

  TypeScript is a minimal extension of JavaScript which has type annotations. When you bridge directly to JavaScript in Nim you have to write `cimport` type annotations for any variable, function etc you work with. However, with dts2nim, you can automatically import the type annotations that already exist in TypeScript. I think this is similar to the existing "c2nim" tool for C, but I have not used c2nim.

  Using dts2nim grants several advantages:

  • You can write TypeScript glue code that works with pure JavaScript objects in complex ways and call that glue code directly from Nim, with no need to write additional type specs.
  • TypeScript ships with a set of type definitions for the entire JavaScript standard library; dts2nim grants instant access to this.
  • TypeScript has an existing ecosystem for distributing typings for third-party JavaScript libraries: There is a community of people writing aftermarket typings for popular JavaScript libraries and there's a tool for downloading them automatically. With dts2nim you gain access to this in your Nim code.

  For an example, here is a small WebGL demo I wrote leveraging this tool. The standard Nim "dom" module does not contain WebGL bindings, but the TypeScript standard typings do, and dts2nim allowed me to use those standard typings from my Nim program.

  If you would like to try dts2nim out, you can install a copy locally from NPM by running `npm install dts2nim`. You can also find the NPM project page here, and there is source for an example project (the WebGL demo I linked above) here. There is a more verbose description of the project and how to use it on the NPM page.

  There is still a lot of work to be done on this tool. The biggest limitation right now is it doesn't understand generics, which not only means it can't translate the TypeScript any type, it can't translate arrays(!). Long term, my goal with this tool is to leverage it to create a library for OpenGL-using games which can run either in the browser or on desktop.

  If this is useful to anyone, or if anyone tries to use it but has problems, I'd be curious to hear!

---

• vega (orginal) [2016-08-26T05:08:24+02:00] view original

  Wow, cool! Thats what I wanted to do in the nearest future :-) But I want to create this tool as a Nim macro that imports .d.ts files at compile time

---

• euant (orginal) [2016-08-26T10:19:36+02:00] view original

  Oh, wow that's neat. Nice work! I've been meaning to look at TypeScript for a long time now, but have never got around to it.

---

• mcc (orginal) [2016-08-27T00:16:36+02:00] view original

  Vega: That would be cool! My current implementation is standalone because it actually loads the TypeScript compiler as a library, so it is also written in TypeScript.

  However, a pure Nim implementation is probably possible. There is something called "tsserver" which runs the TypeScript compiler as a server and allows you to query (some subset of?) the compiler API using a socket interface. Also if you were willing to limit yourself to supporting .d.ts files, those would be much simpler to parse than full TypeScript code...

---