Live data from Hacker News

NPM: 429 Too Many Requests

github.com

121–130 of 171 posts

Re: NPM: 429 Too Many Requests

#121

I’ve been considering checking node_modules into source control for some time now, has anyone else done that successfully? There would be a variety of benefits: 1. Eliminate redownload of packages on every CI build 2. Reduce the amount of gigantic IO operations from unpacking the tens-of-thousands of files sitting in node_modules. 3. Better security: code checked in can be audited better if not downloaded every singl…

Helps if you only have one platform you're developing on and deploying to (e.g. x86-64 Linux). If developing on macOS there can be Mac specific binaries installed, depending on the package.

That's why npm has a command `npm install --ignore-scripts`. It download the dependencies, but doesn't run the postinstall scripts (that either download pre-build binaries or run a compiler locally).

In early days of node (circa 2011-2013) we used to do the following: 1. run `npm install --ignore-scripts` first. 2. Check the node_modules folder to source control, 3. run `npm install` again - this time without the flag 4. put all extra files generated by install scripts to .gitignore

This way the third-party code (at least, the JS-part of that code) was in the repository, and every developer / server got the version of binaries for their architecture.

It wasn't a bullet-proof, though, since: 1. The scripts could do different things anyway 2. More importantly: one could upload a new version of library to npm with the same version number.

These days, lockfiles and stricter npm publishing rules largely eliminated both issues, and updating dependencies doesn't produce 10k-line diffs in git history anymore.

Re: NPM: 429 Too Many Requests

#122

Earlier quoted context omitted.

I mean there is a difference between having fun and conducting yourself in a professional manner where appropriate. With the increase in adoption of certain technologies (node etc) I have noticed a relationship with the people employed to work with them and their poor level of professionalism in the workplace with regard to their work and how they deal with other people (in the UK) and even how they dress. Similar ag…

> [..] and even how they dress. While there are many points in your post that I agree with, we really should stop worrying about how people dress. If it's a developer sitting behind a computer screen all day long with zero customer contact whatsoever, he really shouldn't be forced to wear a certain dress code just to satisfy someone's standard of professionalism. Such feelings are in similar spirit as "woman should n…

In addition to the first reply to your post, you may find it strange but having dress codes actually help promote diversity in workplaces.

Re: NPM: 429 Too Many Requests

#123
I'm always surprised that npm, a for-profit company with a lame business model, is graciously serving redundant package requests millions of times per day to everyone's CI/CD flows.

One day this is going to happen for real and it will be because npm org decided to charge for API requests by `npm ci`.

Re: NPM: 429 Too Many Requests

#124

Earlier quoted context omitted.

I mean there is a difference between having fun and conducting yourself in a professional manner where appropriate. With the increase in adoption of certain technologies (node etc) I have noticed a relationship with the people employed to work with them and their poor level of professionalism in the workplace with regard to their work and how they deal with other people (in the UK) and even how they dress. Similar ag…

I'm not saying I want memes everywhere, but since I'm spending 1/3 of my life at work I'd rather it be a good time. > Go post memes on the LKML and see what happens I think the seriousness (almost angry tone) in certain communities also is a disservice to attract new members. If I make my first PR in some project, it's easy too feel attacked when the reply is a negative one, albeit strictly professional. If it howeve…

The serious tone is a huge draw to the LKML and that way of working. They really do care about not having left-pad type meltdowns. They really do care about being able to find information easily, even years after the fact.

There's a big difference between shooting the shit in your private communications and cluttering up places where people are looking for solutions.

Re: NPM: 429 Too Many Requests

#126
post #10
post #6

This seems to be slowly clearing up. Regardless, can we talk about the conduct in this GitHub thread? I know every community is different but is it common to have memes and jokes posted this quickly and often in a GitHub issue? It makes it really hard to follow and discourages genuinely useful discussion of workarounds or progress.

Some people getting in the workforce in the last few years have troubles making the distinction between work and play contexts. It's extremely visible on github, slack, &c. which are more and more looking like discord / reddit (gifs, memes, random jokes in the middle of serious discussions)

You can also blame current corporate practices and culture in the development industry for encouraging this sort of behavior and tailoring environments to attract fresh grads.

It's certainly acceptable to blow off steam but there are times and places for that. The official issue thread is not one of them. It looked like a Reddit post more so than the official NPM repo. I have nothing against Reddit just pointing out it's a reasonable venue for this sort of commentary (or even HN).

The thread looked like folks celebrating like the power went out and they'll be going home from school for the day instead of "oh crap, this is my job and I have to fix this issue or my livelihood is at risk because I decided to have no backup plans in place for such a situation where NPM is down."

Re: NPM: 429 Too Many Requests

#127
1) Glad we have a Nexus proxy in front of npm... [a] 2) Cloudflare strikes again, this one company is at the same time making the internet better and worse. I'm constantly blocked by cloudflare for something that should not be, it's extremely frustrating. Then when you complain to them they throw their hands up and say "owner hasn't configured their site for that". Ugh.

[a] https://blog.sonatype.com/using-nexus-3-as-your-repository-p...

Re: NPM: 429 Too Many Requests

#129
post #116

Earlier quoted context omitted.

Your comparison of today's js/node to PHP from 20 years ago is interesting. I wonder if javascript will be in similar place in 10-20 years that PHP is today (e.g. "its not like it used to be and things a actually quite good now")? The language it self (javascript) might be there already, but is the community anywhere close yet? SQL injections used to be the thing PHP was known for in the past but not so much these da…

Javascript is a far better designed language than PHP. The identifiers don't have lengths picked because the maintainer used length as a hash function to name one notorious feature.

Thats just one data point, and for which you could argue that javascript has not one, but two null values: null and undefined.

PHP got (or is getting?) type hinting, while javascript doesn't have such thing (typescript or flow doesn't count). Javascript is event loop based, while PHP is (afaik) request->response based. These days, javascript usually is compiled for web, while PHP just sits there on the server and you can swap out the source files when you upgrade. You could go on and on.

Re: NPM: 429 Too Many Requests

#130
post #127

1) Glad we have a Nexus proxy in front of npm... [a] 2) Cloudflare strikes again, this one company is at the same time making the internet better and worse. I'm constantly blocked by cloudflare for something that should not be, it's extremely frustrating. Then when you complain to them they throw their hands up and say "owner hasn't configured their site for that". Ugh. [a] https://blog.sonatype.com/using-nexus-3-as-…

Cloudflare must value my ability to identify fire hydrants and crosswalks, because I sure get a lot of these challenges...
Post reply on HN