11 ms·
GitHub has completed its acquisition of NPM
- deleted 7y ago[deleted]
- fzil 7y agodang, Microsoft going around acquiring dev tools like its a monopoly game
- pezo1919 7y agoSame feeling. Next ecmascript might be called Microscript. :)
- wp381640 7y agoIt's called Typescript
- tobyhinloopen 7y agoIt’s called a joke
- kevin_thibedeau 7y agoLike borg assimilation.
- pluc 7y agoThat's a key offering from AWS and one where they arguably have been ahead for years.
- throwaway894345 7y agoFor those who were having deja vu, this is a notification that GitHub completed its acquisition of NPM.
- dang 7y agoSince that's also how the first sentence of the article puts it, we've put that in the title above.
- behindsight 7y agoIndeed, and here is the accompanying HN discussion when they first announced their intent https://news.ycombinator.com/item?id=22594549 https://news.ycombinator.com/item?id=22594549
- rhacker 7y agoThey just made Github teams free, so I imagine npm private repos is next?
- dcchambers 7y agoI think they've indicated that the plan is to make NPM the ultimate public JS package registry and move paid plans to GitHub Packages. See Nat's original words about the acquisition: https://github.blog/2020-03-16-npm-is-joining-github/ https://github.blog/2020-03-16-npm-is-joining-github/ GitHub Teams get 2GB of free private package storage (unlimated for public packages) https://github.com/features/packages https://github.com/features/packages He did mention that they were using their enterprise customers to subsidize the cost to allow them to offer Teams for free, so maybe if they get enough enterprise customers using GitHub Packages we might see unlimited free private packages for individuals/teams. I don't see a ton of value for GitHub/MS in that situation, but maybe.
- jillesvangurp 7y agoGithub has repositories already.
- judge2020 7y agoI hope this only goes as far as being able to sign up with and link a GitHub account to NPM. Any tighter integration seems like it would be in bad faith, in terms of allowing integration with other git services/non-GH package hosting.
- ocdtrekkie 7y agoOn the contrary, I'd vasty prefer if a package repository required the source be hosted within the same account (even if just a mirror) that is offering the package, so that they can verify the authenticity/reproducibility of anything inside.
- snazz 7y agoIsn't that kind of the point of the GitHub Package Registry?
- ocdtrekkie 7y agoPresumably a good reason to push NPM over to it.
- rl3 7y agoCurious world we live in, where the infrastructure behind so many OSS projects can simply be acquired. What's preventing the dream of decentralization from taking off? We have the technology.
- xrendan 7y agoWho pays for that decentralized infrastructure though?
- ocdtrekkie 7y agoNPM by it's very nature is a centralized repository, not really an agent of decentralization, where you'd get code from the authors' sites/servers directly.
- briffle 7y agoUbuntu and Debian have mirrors of their apt repositories hosted all around the world by groups, schools, businesses, etc. There is no single point of failure, you grab from the best mirror near you.
- ocdtrekkie 7y agoThat still isn't decentralization: There may be a bunch of mirrors, but there is still a single "source of truth". One entity determines what is acceptable and valid in a repository model, as the entire ability to trust packages you install tends to be on the assumption that entity is making good choices.
- metreo 7y agoWhat does that do for overall code quality on GitHub I wonder?
- RussianCow 7y agoWhy would it have any affect on that?
- metreo 7y agoIsn't npm like a dumping spot for pretty much anything javascript good, bad and ugly?
- beefalo 7y agoPretty much all of the code was already on github
- aaomidi 7y agonpm is just a low friction package registry.
- RussianCow 7y agoThe acquisition doesn't mean all existing NPM packages are suddenly going to get dumped into GitHub repos, though. The services still do two different things.
- kalium_xyz 7y agoNPM is joining GitHub => NPM has joined GitHub
- Pmop 7y agoI don't have a good feeling about this kind of centralization.
- mtm7 7y agoOut of curiosity, what benefits does Microsoft/GitHub get from owning a package registry? I'd be fascinated to learn more about their long-term strategy here.
- sneak 7y agoControl. Getting to decide what goes into npm (the client tool) and what does not allows them to focus the ecosystem onto brands that they own and encourages people to buy their proprietary software and services. It also provides them the option of cutting off third-party tools (e.g. yarn) in the future if they deem it beneficial. My prediction is that they will prioritize the platform features that can only be accessed by first-party, branded tools, like the forthcoming GitHub mobile app. Eventually they will stop maintaining support for the APIs that the other tools use, and it'll be Microsoft tools from end-to-end. Pushing to GitHub and publishing to NPM from right within VS Code, et c. Of course, using them on Windows will always work best, and deploying to Azure will always be easiest.
- lstamour 7y agoI’m less pessimistic. Microsoft has engineers with a business mindset in charge. For now, it’s true. But we saw node vs IO.js — Microsoft can’t afford a fork or they lose their own control. They won’t close open source, they’ll add subscription or cloud usage fees for large enterprises. The value, like GNU “open core” is that open is popular, while enterprise features on the other hand are expensive. The enterprise is being led now by open source because it’s cheap, then value add to solve the problems they still have around control and oversight, etc. If anything, I expect basic Visual Studio internals will eventually get open sourced as cheaper to maintain that way than Roslyn rebuild-all-the-things. And VS Code will adopt them and continue to cannibalize VS mindshare.
- lioeters 7y agoThe first word that came to mind was "integration", but I suppose "control" is another way of putting it. I doubt Microsoft would intentionally degrade developer experience, like "cutting off third-party tools". Rather, they're seeking to gain market advantage from the tight integration of services. It would make sense for them to encourage third-party tools to play well in that "Microsoft ecosystem". > Pushing to GitHub and publishing to NPM from right within VS Code That's exactly what I picture coming soon, if not here already. Also: develop in VS Code, click to build, push to GitHub, deploy to Azure.
- montroser 7y agoI never quite got a warm-fuzzy feeling from npm -- the tool, the service, the company. This announcement does nothing to help, from my perspective. Is my dependency on this or that JavaScript library something that really needs to be owned by a for-profit company? I also kind of wonder what is the real value of a centralized repository versus just directly referencing git repos. I haven't used this gpk[0] project yet, but it looks like an interesting alternative, on paper. [0]: https://github.com/braydonf/gpk https://github.com/braydonf/gpk
- Waterluvian 7y agoYou can still reference repos directly with npm.
- coderzach 7y agoYou'd be surprised how often git repos disappear when you have 100s or 1000s of deps.
- Touche 7y agoImmutability and semver are the reasons
- KenanSulayman 7y agoMuch better: mandatory vendoring of packages. Can't break and being forced to push the packages to the repo makes you appreciate the lack of transient dependencies.
- anm89 7y agoNpm has joined Microsoft
- mythrwy 7y agoGreat. They deserve each other.
- sdan 7y agoNext is pypi
- brian_herman 7y agoI really hope so, there is probably a bunch of malware on there that people don't even know about when is the last time that place has been audited? I don't blame them they are probably running with limited funds etc...
- deleted 7y ago[deleted]
- animalCrax0rz 7y agoThis brought up in my mind the thought that while Deno is still WIP (for example, packaging of Rust plugins is not yet resolved) and the ecosystem around it barely exists it was designed to have no dependency on 3rd party tools like npm and yarn.
- jakear 7y agoIt also provides none of the benefits of npm/yarn. In my understanding it’s as if every package you used pinned all of their deps.
- Tistron 7y agoWouldn't you just include a file by it's minor version like this: import * as E from 'https://cdn.jsdelivr.net/npm/fp-ts@2.5/lib/Either.js'; Whenever you `--reload` you'll get the latest 2.5.x release, no? This should work out recursively for all the deps if they follow the same pattern, no?
- Tistron 7y agoThis seems to be what is suggested as per https://dev.to/pika/introducing-pika-cdn-deno-p8b https://dev.to/pika/introducing-pika-cdn-deno-p8b that was posted by somebody else.
- jakear 7y agoI wasn't aware of the semver URL scheme, but it just brings more problems. At this point they've just replaced `npm` with `pika` and expect people to think it's an improvement to not have a centralized file containing package dependencies and the last resolved versions of packages. Criticisms: 1. Updating dependencies becomes much more of a diff (every file that uses it needs to be updated). The alternative solution to this is creating a single `packages.ts` file that imports all the external deps, and all your modules import from there. Which just `npm` with more steps. 2. No lock file. I saw them present this at tsConf and I believe the original idea was that this wasn't needed because the URLs are the lock, but as you point out in practice people use URL's that aren't unique identifiers. This means no way to guarantee that all developers or even users of the project have the same dependency state. This will be a massive pain for debugging and maintaining packages. (Edit: see below, you can lock deps (unclear exactly how) - but only if you pay them!) Looking at the Pika home page, they tell me I can build and release without a bundler.... so you're telling me that they expect people to put out production software that downloads it's dependencies at runtime and thus: - Is unstable because if they use the semver-URL scheme you mentioned and a patch version comes out that breaks the website, all users are instantly broken instead of the internal build being broken. - Is unstable because if a dependency/host goes offline, all users are broken instead of an internal build being broken (think leftpad but much worse as your users are instantly impacted, likely before you even know about it) - Is insecure because if a host is malicious, they can choose to supply different packages for a small subset of the requests, such as those coming from govt. requests against political targets, hosted build machines, etc. and nobody will have any way of knowing because there's no lock file/integrity hashes. I further see on the Pika CDN page that they share packages across websites. This is seems to be a massive security flaw, as websites are able to modify these packages and now those modifications will apply to all websites using the package. It's prototype pollution-as a-feature! Oh, and at the bottom of the page: > Want to get more out of Pika CDN? The CDN will always be free, but you can also access paid, production features like: > Granular Semver Matching & Version Pinning > ... So base features that are the core of working with npm/yarn/any modern package manager are a paid feature in Pika. I'll pass.
- VonGuard 7y agoThis is a good thing. When they were independent, NPM was a disaster area. The company spent 100% of its time chasing down social issues and insanity in the community and never figured out how to make money, or at least, it took them FOREVER to figure that out. Years ago, they introduced "orgs" which they sat there and explained to me with slides and pictures and concepts and business bullshit for an hour. I did not understand a thing they'd said. Finally, they were like "We're selling private namespace in the npm registry for blessed packages for groups or businesses." I understood that. If they'd just said that up front.... They had some great people, some very smart folks like CJ, but they completely biffed every business decision they ever made, and when you'd go in and talk to the leadership, they were always acting as if they had some sort of PTSD from the community. I mean, people were putting spam packages in NPM just to get SEO on some outside webpage through the default NPM package webpages. People were squatting and stealing package names. Leftpad... the community management here is nightmarishly hard, and I was never convinced they'd ever make money on it. MS doesn't NEED to make money on it. They can just pump in cash and have a brilliant tool for reaching UX developers around the world, regardless of whether they use Windows or not. I feel like the GitHub group at Microsoft is now some sort of orphanage for mistreated developer tool startups. GitHub had similar management issues: they refused to build enterprise features at all for years unless they were useful to regular GitHub.com. And there were other people issues at the top for years. Chris seemed more interested in working with the Obama administration on digital learning initiatives than with running GitHub, for example.
- redthrowaway 7y agonpm is still a disaster, but for other reasons: $ time rm -rf node_modules/ real 1m2.969s user 0m0.409s sys 0m15.853s
- tracker1 7y agoAre you using a 5400rpm hdd? In an existing UI project repo... ci (which clears node_modules) then installs from lock... added 1880 packages in 23.283s real 0m24.073s user 0m0.000s sys 0m0.135s Still slower than I'd like... but I'm pretty judicious in terms of what I let come in regarding dependencies. That's react, redux, react-redux, material-ui, parcel (for webpack, babel, etc) and a few other dependencies. For one of the API packages ci over an existing install... added 1069 packages in 12.911s real 0m13.708s user 0m0.045s sys 0m0.076s So either you're including the kitchen sink, or you're running on a really slow drive.
- sytse 7y agoSomeone asked "Would this have made sense for a company like GitLab if they didn't have the corporate backing of something like MS?" and deleted their comment while I was writing the answer below: Being the canonical registry for a language (Rubygems) or technology (DockerHub) tends to be a huge expense. The main expenses are cloud costs (bandwidth and storage) and security (defense and curation). I've not seen examples of organizations turning this into a great business by itself. For example Rubygems is sponsored by RubyCentral http://rubycentral.org/ http://rubycentral.org/ who organize the annual RubyConf and RailsConf software conferences. Please note that running a non-canonical registry is a good business. JFrog does well with Artifactory https://jfrog.com/artifactory/ https://jfrog.com/artifactory/ and we have the GitLab Package Registry https://docs.gitlab.com/ee/user/packages/ https://docs.gitlab.com/ee/user/packages/ that includes a dependency proxy and we're working on a dependency firewall.
- gowld 7y agoWhy is non canonical better? Because they get to charge a fee?
- kortilla 7y agoYep, in particular the use case is private packages.
- sytse 7y agoYep, non-canonical registries are used by business and they are more likely to pay. For example our dependency firewall will be a paid feature that delays updates from packages that are recently updated under suspicious circumstances like: author changed, author information changed, different programming language, activity after a long period of inactivity, large change to the code, etc.
- JMTQp8lwXL 7y agoI am curious what proportion of compromised packages fall under the umbrella of scenarios you have outlined.
- wp381640 7y agoI'd say the three biggest namespaces in dev are github, npm and docker hub - will Microsoft go 3 for 3? Docker Hub feels a bit neglected - it could be aliased to docker.pkg.github.com and that'd be a huge improvement
- paxys 7y agoDocker is definitely getting acquired in the near future, and Microsoft is as good a guess as any.
- jillesvangurp 7y agoYep. IMHO if Google would want to make a move here, now would be a good time. And as the creators of Kubernetes, they have some nice incentive to try to stay relevant. MS gobbling this one up would not be a big surprise.
- pavlov 7y ago“DEVELOPERS DEVELOPERS DEVELOPERS!” — Steve Ballmer, 2000
- DeathArrow 7y agoToo bad he didn't act on it. He was just talking...
- toyg 7y agoHe didn't say which developers though. Arguably, Office and enterprise developers have been served fairly well even during his tenure. As long as you colored between the lines, the experience was alright.
- SenHeng 7y agoI'm curious what's the roadmap for the npm CLI tool. Any word?
- aforty 7y agoI like how Microsoft basically just acquired a whole slew of open source tools and no one seems to notice or care.
- judge2020 7y agoThere were Microsoft discussions in both the GH thread[0] and the NPM thread[1]. 0: https://news.ycombinator.com/item?id=17221527 https://news.ycombinator.com/item?id=17221527 1: https://news.ycombinator.com/item?id=22594549 https://news.ycombinator.com/item?id=22594549
- metreo 7y agoWhy should anyone? Open source has always been about freedom. MS hasn't acquired the tools to my knowledge, they've acquired popular infrastructure built around tools. Anyone can still start GutBub based on the same `git` source tomorrow if they wanted. To be sure a lot of this may be about talent as well. They may need to be liked in the community otherwise they have a hard time hiring top talent. They are buying a community since they probably couldn't build it themselves.
- frandroid 7y agoBecause open source has always been defined in its very definition by its definition to the for-profit software industry, which Microsoft basically invented? Because in spite of having made a turn towards open source, Microsoft once treated it like a mortal enemy, akin to cancer? Because of how other large companies like Google have smothered open source projects? I'm personally not worried about the acquisition (I think it's a net positive for the community), but there are plenty of reasons to discuss this interaction.
- metreo 7y agoIt's a common misconception that open source is antithetical to profit. The concern is really about the freedom to inspect, modify and distribute the codes which run your computer without restriction. I hear you, I think MS is prone to mismanage the nicest things we have. And yes part of this will be some PR mess up. We definitely cannot trust a large cash reserve to guarantee the survival of these technologies, it's just not how businesses work.
- bamboozled 7y agoWhich is now owned by Microsoft? :)
- doctoboggan 7y agoQuestion from a new JS developer: Should I be using NPM to manage my dependencies? I have recently started getting into JS programming. I have thus far avoided NPM, because I've been trying to use CDNs for all my external dependencies. My thinking is that it saves me bandwidth costs and potentially saves my user's bandwidth as well if they get a cache hit. I get the downsides are that I don't control the CDN and they could go offline, but honestly I expect I am much more likely to go down from some mistake in my own deployment rather than a well known CDN being offline. I am wondering if I am missing something though, because absolutely every JS package I read about suggests you use NPM (some also link a CDN, many don't). Should I be using NPM to manage my JS dependencies instead of using CDNs?
- giantDinosaur 7y agoIIRC it turns out the cache hits from CDN'ed Javascript files ended up being fairly low and neglible, due to how many different versions there are of everything. Better just reduce the file size.
- doctoboggan 7y agoI feel like bootstrap and jquery stand a decent chance of being caches in a large enough portion of the user base. And even ignoring my user's bandwidth, it would still save me significant bandwidth (depending on the size of my website). I guess eventually your site might grow such that your dependencies are not a significant portion of your total download size, but I am not currently there.
- giantDinosaur 7y agoDo you 'feel like' or do you actually know? It's important to make decisions based on actual data. I haven't researched it in depth, but if these asset sizes matter to you, then it is worth researching.
- lioeters 7y agoPersonally, I only use external library CDNs during early stages of development, or quick prototypes. There are advantages to having all needed assets locally. The main point for me is to minimize external dependencies during runtime - fewer points of failure. Also, vendor libraries can be a single minified bundle served from the same domain. In production they can be moved to a CDN, i.e., CloudFlare. Using NPM makes sense once you start having more than a few dependencies, or a build step. On the other hand, if you can get by with library CDNs and don't feel the need for NPM - I'd say that sounds fine, to keep it simple and practical.
- asiachick 7y agoHopefully they'll revisit the decision to allow ads in install scripts that NPM sanctioned.
- tomcooks 7y agoSerious question: am I the only one worried that this is yet another EEE strategy, typical of MS?
- toyg 7y agoNo. Unfortunately, there is little we can do. Most people don't take a strategic or ethical view to their development stack: they are getting a job done, so they take the most convenient / fastest / easiest way to do so (price being equal). And if they get screwed 5 years from now on, who cares - their employer will pay them again to re-do the work.
- chvid 7y agoIt would be nice to have free private npm repositories like the free private github repositories ...
- tobyhinloopen 7y agoIf you cannot beat them, buy them.