TL;DR: There are three options to fix an NPM dependency:

• Open a bug ticket on the repository of the maintainer
• Fork & Fix
• Create a patch and fix it

J'avais tendance à privilégier la 2e solution, mais elle a l’inconvénient de créer une dépendance à github.com au moment du build, ce qui n'est pas toujours pratique dans un contexte d'entreprise... patch-package peut donc s'avérer bien pratique dans ce cas

What happens if malicious code is uploaded to npm under these names? Is it possible that some of PayPal’s internal projects will start defaulting to the new public packages instead of the private ones?

Have you ever wondered what happens exactly when you run pip install? This post will give you a detailed overview of the steps involved in the past, and how it all changes with the adoption of PEP-517 and PEP-518.

Some gripes about Go from this blog, specifically around developer ergonomics (syntax highlighting and language-inherent error detection), politics, packaging and distribution, GOPATH, and the tuple-oriented error handling idiom. As R. I. Pienaar noted, the Go community seems full of “at-Google-wes”, which is an excellent way of putting it.

👍

Another one: https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html

Both from: http://taint.org

Speed, reproducibility, easy rollbacks, and predictability is what we strive for when deploying our diverse Python applications. And that’s what we achieved by leveraging virtual environments and Linux system packages.

Or how I obtained direct publish access to 14% of npm packages (including popular ones)

Used by netsuite.com to build and upload packages of Python libs depending on C extensions, before pushing them to a Nexus with repositorytools