If every dependent implements a dependency cooldown, then the cooldown might as well not exist.
We should all be using dependency cooldowns
261–270 of 287 posts
Re: We should all be using dependency cooldowns
#262Also protects against when a library developer suddenly goes rogue and enshittifies the library, to make a buck or two.
Re: We should all be using dependency cooldowns
#263A “cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use. My understanding of a cooldown, from video games, is a period of time after using an ability where you can't use it again. When you're firing a gun and it gets too hot, you have to wait while it cools down. I was trying to apply this to the concept in the article and it wasn'…
The dependency has just come out of the oven, so it's too hot and must cool down ;)
I addressed this though lol. Nobody says "my pie is on cooldown."
Re: We should all be using dependency cooldowns
#264I really wish homebrew supported this feature. There are a bunch of terminal tools I have installed through it (and wouldn't make sense to sandbox) that are basically one-person projects, and I imagine subject to supply chain compromises. I don't urgently need the very latest versions for any of them, as they are unlikely to have exploitable security vulnerabilities on my machine (due to not being involved with any network facing service).
Re: We should all be using dependency cooldowns
#265> vendors are still incentivized to discover and report attacks quickly, but are not as incentivized to emit volumes of blogspam about “critical” attacks on largely underfunded open source ecosystems.
How?
Re: We should all be using dependency cooldowns
#266Earlier quoted context omitted.
> No one can think that js has progressed substantially in the last three years Are we talking about the language, or the wider ecosystem? If the latter, I think a lot of people would disagree. Bun is about three years old. Other significant changes are Node.js being able to run TypeScript files without any optional flags, or being able to use require on ES Modules. I see positive changes in the ecosystem in recent y…
That is motion not action. The point of javascript is to display websites in the browser. Ask yourself, in the last three years has there been a substantial improvement in the way you access websites? Or have they gotten even slower, buggier and more annoying to deal with?
> The point of javascript is to display websites in the browser.
I don't follow. JavaScript is a dynamic general purpose programming language. It is certainly not limited to displaying websites, nor it's a requirement for that. The improvements I mentioned in the previous post aren't things you'd get the benefit of inside a web browser.
Re: We should all be using dependency cooldowns
#267Nice. Additionally we should be using dependency limits and dependency moderation.
Half of my job when reviewing work is telling junior devs to try to do something without the dependency. Usually they just learn about a very basic skill.
"Ok so you downloaded a thing called apscheduler, what does that do?" "So it's like cron?" "Can you use threads, or even better just use a separate process?" "Cool"
My (least) favourite example is the amount of juniors that download a dependency from a random indian dev to store and read credentials from .env . Just open() and read() the security critical file my dude.
Re: We should all be using dependency cooldowns
#268Earlier quoted context omitted.
I've seen this argument made frequently. It's clearly a popular sentiment, but I can't help feel that it's one of those things that sounds nice in theory if you don't think about it too hard. (Also, cards on the table, I personally really like being able to pull in a tried-and-tested implementation of code to solve a common problem that's also used by in some cases literally millions of other projects. I dislike havi…
Anything that pulled in chalk. You need a very good reason to emit escape sequences. The whole npm (and rust, python,..) ecosystem assumes that if it’s a tty, then it’s a full blown xterm-256color terminal. And then you need to pipe to cat or less to have sensible output. So if you’re adding chalk, that generally means you don’t know jack about terminals.
Chalk appears to be a great example.
I wonder how many devs are pulling in a whole library just to add colors. ANSI escape sequences are as old as dirt and very simple.
Just make some consts for each sequence that you intend to use. That's what I do, and it typically only adds a dozen or so lines of code.
Re: We should all be using dependency cooldowns
#269Earlier quoted context omitted.
Anything that pulled in chalk. You need a very good reason to emit escape sequences. The whole npm (and rust, python,..) ecosystem assumes that if it’s a tty, then it’s a full blown xterm-256color terminal. And then you need to pipe to cat or less to have sensible output. So if you’re adding chalk, that generally means you don’t know jack about terminals.
In the Python world, people often enough use Rich so that they can put codes like [red] into a string that are translated into the corresponding ANSI. The end user pays several megabytes for this by default, as Rich will also pull in Pygments, which is basically a collection of lexers for various programming languages to enable syntax highlighting. They also pay for a rather large database of emoji names, a Markdown…
Exactly! ANSI escape codes are old and well defined for all the basic purposes.
Pulling in a huge library just to set some colors is like hiring a team of electrical contractors to plug in a single toaster.
Re: We should all be using dependency cooldowns
#270Maybe the repositories should do this by default?