Please share your thoughts on Dependabot security alerts on Github, more specifically for NPM packages in package-lock.json.

In 99% of cases I've found them useless as:
- package-lock.json is in the repo, but not in the NPM package (=no value to users)
- most of the updates relate to devDependencies (=no value to users)
- it clutters the git history (and changelog if it is auto-generated) with a batch of patch updates (updated depx to .1, .2, .3) while the only important thing in the next release notes is the delta (updated depx from .1 to .3) (=no value to users)

Yeah, to a certain extent. Renovate does a lot better.

It is bad, it tries to work around a root problem that needs to be addressed. Such workarounds can never work good. The root cause is dependencies.

Some developers need to learn that you only should add dependencies if absolutely necessary. People that think it is a good idea to use a NPM-Package because they don't want to write 100 lines of code themselves shouldn't code.

@happygimp0 A lot of NPM packages are actually several hundred lines, solving a problem you would solve in 100 lines while accounting for all the edge cases it's uneconomical for you to cover but some of your users will absoutely hit.

Please don't reinvent the wheel.

@happygimp0 If a package is just a couple files nowadays I tend to just skim all of it and see if it does something beyond the basics, and if it's up to my standards. Code that I can't read at a glance has no place in my product because when bugs occur I'll need to read that too. On the other hand, dependencies of high code quality can even help debugging because you start with nonzero test cases that are guaranteed to work.

There are two approaches to dependencies. One's to treat them as functionality that just exists. This works with dependencies that are developed by large organizations with very strict quality standards and solve inherently complicated problems, but it breaks down with a package manager that cherishes atomicity such as NPM.

The other is to treat them as code you don't have to write. You still have to review it, and while you're not alone with this effort you still have to debug and test it to some extent, like all other code in your project. This is infeasible for large libraries with a complex internal structure, but excellent for the little NPM package or crate that just implements some random control flow pattern you happen to need or something.

In my opinion, a biweekly / monthly update check which bumps everything in a separate branch is cleaner than "smart" scripts / bots trying to do it automatically.

Especially in regards to transitive dependencies...

Given that NPM fucked everything over regarding packaging, it's hopeless for NPM / NPMs alike, as there is no sane approach to packaging / version updates.

@lbfalvy Yes. I didn't say don't use any external dependencies (you can't avoid them) but only when it is necessary. Too many developers just add long lists of deep (packages that depend on other packages that depend on yet other packages, ...) dependencies.

Sometimes a package may have 3000 lines and 60 functions but a developer needs only 3 functions.

@happygimp0 Utility aggregators are pretty bad, but in the particular case of JS tree-shaking bundlers are supposed to eliminate 2850 lines and all dependencies if all you're using are those 3 self-contained functions.

What would better suit my needs is a scanner that only suggests a batch of package.json updates on manual trigger (a button). For all other purposes npm audit can be run manually or in an npm hook script (eg pretest).

So I conclude that dependabot is pretty useless if you know your dependencies & keep them clean

DependaBot is fucking AMAZING!

Simply enable it, and it automatically prevents suits and useless compliance people from raising stupid requirements.

"Is our code supply-chain secure?"

"Yes! Dependabot!"