big milestone: #orogene, a fully #rust #rustlang based package manager for the #npm ecosystem, has successfully resolved, and written a lockfile for, a project scaffolded by create-react-app!
@zkat
i love the name! is this a geology reference or an nk jemison reference?
@tarajdactyl Broken Earth ;) some of the sub-libraries are named after the theme, too: nassun and node-maintainer for now. syenite probably coming soon.

@zkat yessss! i have to admit i googled to see if it was anything outside of broken earth and discovered it's also a geology word 😅

Jemison well deserves her place among Tolkien and other authors in the SFF pantheon that tech folks take names from 😁

@zkat Huge milestone indeed! Great work
@zkat Where can I try orogene?
@dragnucs you can’t
@zkat Why?
@dragnucs because it's still in pretty early development? It's of no use to anybody.

@zkat super cool project! Curious if your plan is npm-like compatibility or something different?

For example, yarn v1 is (almost always) a drop-in replacement for npm, whereas pnpm is just slightly different and sometimes breaks things (and yarn v2 is entirely different). If that made sense? 😅

@codetalkio kinda somewhere in between. I plan to be as compatible as possible but it’s not going to do things exactly like NPM (what’s the point?)
@zkat nice! is there a major design philosophy that sets it apart from the npm/yarn/etc?

@zkat this is super exciting. Let us know if we can help or support this project!

Out of curiosity, what made you decide on a new lockfile format? (from what I can tell)

@rauchg the new lockfile format is partly just because I want to use KDL, partly so I have the freedom to make modifications without having to track whatever the other package managers are doing. At its core, this format is 1:1 convertible with the current version of package-lock.json. That is, it contains the same information, in a similar structure (as opposed to yarn.lock, which doesn't contain structure information, so dep trees can vary between yarn versions)

As far as helping, I don't know. If there's someone who's really interested in it, I'm happy to get discussions going, but this is a very casual project for me right now, and still kinda "proving it out". For example, due to performance of tokio and serde_json, the resolver is actually *slower* than NPM's own resolver right now. I'm hoping to make some gains on the installation front, but ultimately, package managers are IO bound.

@rauchg I do also plan to replace package.json itself at project and workspace roots (while still being package.json-compatible). The project is largely an opportunity for me to play with a lot of ideas that I couldn't in core NPM, because I'm no longer constrained by a large userbase that absolutely requires backwards compat with my specific tool. I have a lot of ideas on what to play with :)