bob had this idea already a while back. why don’t we build a package manager into rescript, for a repo with pure rescript libraries? part of the repo could even be ready-made bindings for npm packages. what would this entail, what are the pros and cons, and why haven’t we done it already?
Git repos suck for package managers. Ideally you host them on a DB you own. (Package managers keep using git as a database, it never works out | Andrew Nesbitt)
So this probably needs resources that need to be paid. We try to be very conservative on that front. We had this idea of a bindings manager for a long time now but we have to apply lessons learned from flowtyped et al. It has to be a platform that is explicitly made for this. And it’s basically a copy-paste package manager so the sources would just be vendored in your repo so you can easily adapt them to your needs.
But if you extend the idea tho whole libraries, you end up like Elm where you might now be able to do real semantic versioning and stuff (i.e. the main .resi changed so it’s a breaking change), but we are not sure it’s really worth the effort.
Also you’d need to install it differently to be really useful. Global npm installs suck.
2 Likes
For me, part of the appeal is that everything ReScript-related flows through the existing Node-style ecosystem. Introducing a second package manager for ReScript feels like a step back. I can see the build-system advantages, but developer experience would suffer for most users, and with our limited contributor pool it doesn’t seem worth the time.
3 Likes