Uuid: TypeScript rewrite?

[ctavan]

@defunctzombie suggested in this comment that the node-uuid module could be re-written in TypeScript.

What would be the benefits of such a rewrite over modern JavaScript?

[broofa]

It should be noted that the reason for this is to simplify support of ES modules in browsers and Node, not because TS is particularly well-suited to generating UUIDs per se.

I'm typically not a fan of Typescript for OpenSource projects. It complicates the toolchain and makes projects less approachable.

[defunctzombie]

(opinion) type information has made my development more pleasant and proficient - but I also understand not wanting to take on the additional build step or barrier for other developers. Typescript has let me use one toolchain to build rather than collecting a bunch of babel plugins like I would need to do before. The API surface is the uuid module is sufficiently small and often "obvious" in a way that it itself won't benefit all that much. Like with most things - it is just preference. I've found that where I use to favor plain JS and no build step - that with new tooling the build "step" doesn't get in the way of my iteration.

Practically - I don't consider my comment of porting to TS as something that would actually happen but threw it out there anyway - hopefully without it becoming a distraction to your work.

[ctavan]

Thanks! I still think that, given the broad adoption of TypeScript especially in application development, offering useful type definitions through @types/uuid should be a priority of this repository as well and I will work on that (#328).

For TypeScript users this should hopefully already provide most of the benefits.

[dstaley]

As a TypeScript user who uses the node-uuid package, my main desire is having types included with the package as opposed to downloading the @types/uuid package. I would prefer the library be written in TypeScript since that guarantees that the types match the behavior of the library, but I completely understand the hesitation there. I wrote a RFC for a TypeScript migration for the libraries I work on, and all of its points are equally applicable here. I'm actually of the opinion that TypeScript encourages outside contributors since it gives another layer of checks over their code. Think of it like an extra set of unit tests. In Kinto we use TypeScript to generate an ES-modules build and a CommonJS build, and then use Rollup to generate a browser-friendly ES-modules build alongside a traditional UMD build.

I'm also a big fan of using the TypeScript compiler in lieu of Babel even in pure JavaScript projects. TypeScript's inference is pretty great, so it can catch some errors even without any types. You can improve the quality of the checks by adding JSDoc formatted comments.

[sam-s4s]

Yes, having types included would be great. Also an important request - please make sure that @types/node is not being pulled in. It really ruins a project. I can't use the @types/uuid package at present because it pulls the node types in, and then you can't use things like setTimeout properly, because the non-browser, node versions of the types get pulled into your project, creating chaos :(

[broofa]

Let's close this - I think this is covered by #328

[ctavan]

OK, we'll first make sure to get the typings in order, see #328. Should not matter if the uuid code base itself is written in TypeScript or not as long as we provide useful typings.