I actively use both platforms, GitHub by choice, NPM by general acceptance. I personally see this acquisition as a perfect answer to a lot of pain points I had using the GitHub Package Registry (GPR).

When I saw the GitHub Packages beta announcement and demo at GitHub HQ in San Francisco, I remember turning to Shanku Niyogi and clumsily blurting out, β€œWhy aren’t you trying to buy us?”

– Isaac Z. Schlueter, npm inventor

Honestly, I thought the same thing when I saw the announcement. There's a history of frustration both with GitHub and NPM that led to why I was on the fence about GPR, but why I'm in full support of the road ahead with this acquisition.

GitHub Package Registry (GPR)

Since I've already put a link to the marketing page above, I'll give a summary of how I feel GPR could be explained. It's basically NPM, in essence at least. It's a package registry where you can publish a package both publicly and privately, but with the added benefit now that you can authorize a package download using your GitHub credentials (or access token).

This is convenient, except ... not? It's convenient if you want to use it to within an organization only, I see the current implementation of GPR working extremely well that way. However, this is not the end of the story for library developers and popular open-source package maintainers. GPR added a new layer of complexity, with no real perceivable benefit (opinion). I used GPR purely for the added item on the Repository that displays package data, no other reason, I didn't consume it, don't even think it's been downloaded, and that's true for every single package I've published to the GPR (7 if memory is correct).

I would publish it to GPR, and in the same GitHub Action, would publish it to NPM, where it would actually get consumed and downloaded.

I used GPR for the vanity, and NPM for the actual package sharing. This remained true throughout the beta and has since adjusted to me dropping GPR entirely. Purely because it did not add any additional value to a workflow that has plenty of room for improvement.

In order to use the GitHub Package Registry, I'd need to adjust my registry endpoint url from the default registry.npmjs.com to npm.pkg.github.com. Easy enough. In order to publish to the Package Registry, I'd have to authorize the publish using my scoped namespace @pqt in the case of my GitHub, and either use an appropriately permission'ed personal access token, or the handy GITHUB_TOKEN provided in an Action. All and all, it was fine, the implementation was acceptable and it was nice to see all the new things pop up on the repository when I finally got it up and running. But I didn't find any use for it.

Disclaimer: This may be entirely wrong, but from my couple months of using GPR, I still haven't a clue how parts of my setup worked and successfully published, it was inconsistent and my authentication process was very broken, a lot of my success came from random attempts and documentation readings between the hours of 1AM and 4AM.

I loved the idea of GPR, but no matter which way I sliced it, just couldn't find a good way to incorporate it into my projects over the already-perfectly-acceptable NPM solution we all have come to know. For no value-added, and a higher barrier of entry I didn't see it getting the real traction it needed to be a contender. At least not in it's current state.

Node Package Manager (NPM)

NPM and I have a love-hate relationship. I use it every day, love how it's changed the way we share code, but hate how many vulnerabilities have snuck through, the lack of website functionality and just a general feeling of it being an amateur product.

Quick aside, I have no ill-will towards NPM, I just genuinely didn't know how else to word the statement above. I know it's not run my amateurs, but the design and usability to everything always felt like it wasn't quite a finished product.

The NPM website on it's surface does a good job. The profile view is iffy, and the package view is ... eh, I'll give it a pass. Nothing special but no real criticisms on it either. It kind of falls apart in the overall permissions, design (opinion) and just the management of organizations and packages in general.

The views I find confusing, between your profile, packages listing, organizations list, and then to the package view, then into the settings, I always end up clicking 3 or 4 times more than I feel like I need to, just to find whatever the hell I needed to search for, and then ultimately figure out it's not straight forward to do something I wanted to do or that I adjusted some package settings in a way that I didn't mean to (?). Like, I'm a pretty understanding person and I'd like to class myself in the technology-literate group given that I wrote code for a living, but NPM has continued to give me self-doubt over the years and I'd like to blame that on NPM more than accept it as my own fault πŸ˜….

Acquisition

GitHub is uniquely in a position where their entire business thrives around the open-source community and the health of a good package registry under their belt (read: control) is positive step to the value-added problem aforementioned. They don't need to push GPR anymore (I'd think at least) and instead can focus just on NPM and the integrations with it.

NPM is now afforded wonderful resources that I welcome to the shortcomings also mentioned above. They could inherit Primer and take advantage of the GitHub look and feel, and piggy-back on your GitHub account for integrated permission sets right from the root of your open-source account.

Personally, I'd be perfectly happy with NPM just getting ingested into the GitHub ecosystem entirely. It's a great acquisition on GitHub's part and they've certainly earned the trust of the open-source community time and time again, I am confident (and hopeful) this will be no different.