• @yaupon/id is a library that provides a simple way to generate unique identifiers.
• Application provides two exports @yaupon/id/safe and @yaupon/id/fast, with @yaupon/id/safe being the default export.
  • @yaupon/id/safe is a safe implementation of unique identifier generation, which is type-safe by default ( prefixing id with safe generation algorithm) and the fast export is using nanoid to provide a 32-character ID which is there to be used on infrastructure level.
• There are ready-to-use presets of IDs and aliases to Node.js functions which ensures compatibility with the generic ID type from @yaupon/id library, to avoid type-casting everytime ID is generated outside library.

@yaupon/id are unique to the place used and are not compatible one with another.

class User {
    id: ID
}

class Post {
    id: ID
}

const user = new User()
const post = new Post()

console.log(user.id === post.id) // compilation error

I come down to this idea just because some retarded coworker was trolling me on codebase with functions that take userId which is later used at ORM as productId - no such things possible with this approach.

function updatePost(postId: Post['id']) {
    // ...
}

"But Jay, Post["id"] makes me import Post everywhere where I just want to use ID type!", you say?

Overall recommendation is to use import type { Post } from "post.ts" and use Post["id"] where needed, send approach is creating a new type alias for ID type in your project.

import type { ID } from '@yaupon/id'

type PostID = ID // Or PostID = Post['id']

function updatePost(postId: PostID) {
    // ...
}

However, I find it more readable to use Post["id"] in this case.

"Why I would use this library instead of nanoid or uuid?"'

• We did not write this library to compete with nanoid or uuid, but to provide a type-safe way to generate unique identifiers.
• nanoid and uuid are great libraries, but they do not protect against ID misuse.
• @yaupon/id is a library that provides a simple way to generate unique identifiers, which are unique to the place used and are not compatible one with another.

"But xyz library does the same thing!"

They had bad marketing, tags, description or something else—at the time I was building library there was only typeid from Jetpack which would provide similar functionality, container this package as fork of typeid.

• [TODO] Ahead-of-time compilation/validation with typia and helper function such as isID to ensure that ID is valid.
• [TODO] Integration with ORM libraries to ensure that ID is always valid and is not used in wrong context.