Maintainers

[perry-mitchell]

It's quite clear that this repository is lacking maintainers to help review and merge PRs.

I can't offer a day-to-day availability to do so, but I would definitely have time each week to dedicate to helping keep this library alive and help merge the occasional bugfix etc.. I use it very regularly in many projects, both personal and work. I'd love to become a maintainer of ulid/javascript, and I'm sure there are others that would readily do the same.

@alizain would you consider adding someone as a maintainer? I'd be happy to discuss the responsibility further if you'd accept help for this project.

[jpbourgeon]

@alizain
Hello ! ULID is a great piece of software. I use it for all my uid needs and I am also willing to help you make it last ! I agree with @perry-mitchell that you should add (a) maintainer(s) to the repos and/or the organisation. To help you sort and handle the opened issues and PRs.

You may also consider archiving the whole project to make it official that it is not supported anymore. The community (we) would then be free to fork the repo and keep it alive there.

Please, take a few minutes today to, at least, configure @perry-mitchell and/or me as maintainers of the javascript package.

I look forward to your answer !

[jpbourgeon]

You may also consider archiving the whole project to make it official that it is not supported anymore. The community (we) would then be free to fork the repo and keep it alive there.

It would be a real shame because the project is downloaded 277,353 times per week on NPM, on a steadily increasing trend!

[jpbourgeon]

In the meantime or as a replacement, there is a maintained implementation of the ULID specs in https://github.com/aarondcohen/id128

[perry-mitchell]

I've built a replacement, which I'll be maintaining from here on out: ulidx. It'll adhere to the same spec, and is more or less a transposition of this library (but with the inclusion of some PRs). It also has almost all of the same tests, to confirm that it's functional.

ulidx because it's designed to target node/web/webworker environments.. and eventually react-native.

[samal-rasmussen]

Ok this situation is becoming dangerous. As of right now ulid package has 1.1 million download per week but hasn't had an update in 7 years. These are a lot of people using unmaintained code.

Ulidx is still actively maintained and has regular updates by many people and has a relatively low download rate of 85.000 thousand per week.

The ulid package should really be deprecated in favor of the ulidx package. Actually the best resolution for users would be if the ulidx package became the ulid package.

[alizain]

Damn, that’s not a great situation.Would anyone, including the maintainer of ulidx, like to take over maintenance of this project?On Jan 30, 2025, at 4:02 AM, Sámal Rasmussen ***@***.***> wrote: Ok this situation is becoming dangerous. As of right now ulid package has 1.1 million download per week but hasn't had an update in 7 years. These are a lot of people using unmaintained code. Ulidx is still actively maintained and has regular updates by many people and has a relatively low download rate of 85.000 thousand per week. The ulid package should really be deprecated in favor of the ulidx package. Actually the best resolution for users would be if the ulidx package became the ulid package. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[perry-mitchell]

Hi @alizain! Thanks for taking the time to reach out here.

I'd personally be interested in maintaining ulid - are you at all open to a transfer of ownership, or granting me such a role on the ULID org? Not looking to move or swipe the project in any way, just wondering if such a thing were of interest in the effort of making maintainership an attractive move (being that I maintain a number of projects already, and this would slightly add to that burden).

I'd be more than happy to bring ulid in-line with the current ulidx (in terms of improvements, environment support and bugfixes), and would potentially even consider _eventually folding ulidx into ulid considering the vast popularity difference in favour of ulid. Feel free to contact me on Keybase or Mastodon if you'd prefer.

[perry-mitchell]

Thanks @alizain! I now have access to the org. Would you consider granting me owner access here, as well as on npm?

To be completely transparent here - I'm not looking to take the project or org from you or anything like that. If I'm to manage this implementation going forward I just want to avoid any barriers, structural, for releasing and otherwise. If those are fine for you I would expect nothing further, and will follow my initial roadmap:

• Stable update for current ulid users (deps, bug fixes etc)
• New major version, containing ulidx fundamentals, ensuring API similarity
• Eventual deprecation of ulidx in favour of ulid

I'd continue to push ulid to a place of compatibility, ensuring its wide user base is using the best utility out there as the name implies through its originality. I would hope that my existing array of projects would lend some credibility to these words.

I'll stop selling myself here - I would be honestly quite excited with the prospect of moving forward with this, so long as the terms work for all sides.

[alizain]

hey @perry-mitchell - i've given you write access to all the repos on the org. i don't feel comfortable handing you owner access yet. if you come across any barriers please let me know.

also, let's switch over to mastodon.