@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 thefast
export is usingnanoid
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
oruuid
, but to provide a type-safe way to generate unique identifiers. nanoid
anduuid
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 asisID
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.