You typical Node project
-
The package comes with all the bells and whistles but the final build only contains the tarp, if you import it right and tree shake it.
This person nodes…
-
As the guy people come to when they've spent days banging their heads against a dependency conflict problem rather than delivering value for the business, I wish the folks on my team would take the proverb "a little copying is better than a little dependency" to heart a little more.
Amen.
I have sorted out so many JS dependency tangles for my team members, both front end AND back end, that I am loathe to import anything I don’t absolutely have no choice about.
I will rewrite some stuff before I import it…
-
Depends on the use case, and what you mean by “external dependencies”.
Black box remote services you’re invoking over HTTP, or source files that are available for inspection and locked by their hash so their contents don’t change without explicit approval?
Cuz I’ll almost entirely agree on the former, but almost entirely disagree on the latter.
In my career:
I’ve seen multiple vulns introduced by devs hand-writing code that doesn’t follow best practices while there were packages available that did.
I have not yet seen a supply chain attack make it to prod.
The nice thing about supply chain attacks though: they get publicly disclosed. Your intern’s custom OAuth endpoint that leaks the secret? Nobody’s gonna tell you about that.
wrote last edited by [email protected]I didn't think I would have to spell this out, but when I wrote "as much as possible", I was acknowledging that some libraries are either too complex or too security-sensitive to be reasonably homebrewed by the unqualified. (Perhaps "as much as reasonably possible" would have been better phrasing.) Where the line lies will depend on the person/team, of course, but the vast majority of libraries do not fall into that category. I was generalizing.
And yes, some third-party libs might get so much public scrutiny as to be considered safer than what someone would create in-house, depending on their skills. But safety in numbers sometimes turns out to be a false assumption, and at the end of the day, choosing this approach still pushes external risks (attack surface) onto users. Good luck. It hardly matters to the general point, though, because most libs do not have this level of scrutiny.
Let's also remember that pinning dependencies is not a silver bullet. If I didn't trust someone to follow "best practices", I don't think I would trust their certification of a third-party library hash any more than I would trust their own code.
With all that said, let me re-state my approach for clarity:
- I minimize dependencies first. Standard libraries are great for this.
- When something more cannot reasonably be avoided, I choose very carefully, prioritizing the safety of my users over my own convenience.
- Sometimes that means changing my original design, or spending my time learning or building things that I hadn't planned to. I find the results to be worth it.
-
Until those wheels contain malware and spyware.
Or bugs that you only work out much later on.
-
Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.
wrote last edited by [email protected]Too late,
is_even_rsnow depends ontokio -
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
Yes, but my moon rover's wheels need to fulfill different requirements.
-
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
The problem is "I need function, library with 1000 functions has function, include." Library's 823rd function turns out to have a vulnerability.
-
What is that?
Dead code elimination but with a different name for some reason
-
This post did not contain any content.
Except in the picture on the left, someone's actually reading it.
Something's gone wrong if you're looking in the node_modules folder.
-
And this is why tree shaking exists.
It's great when it works, yeah.
-
Rust as well. Seems to just be a modern language thing.
wrote last edited by [email protected]At least Rust compiles down to what is used. I don't know if js has any of that, but at least with rust the final program doesn't ship tons of bloat.
-
At least Rust compiles down to what is used. I don't know if js has any of that, but at least with rust the final program doesn't ship tons of bloat.
Yes and no, the linker does nicely trim a lot of the fat, but rust binaries are still pretty chonky. Its good chonky (debug etc), and static compile doesnt help, but they are quite fat.
Also doesnt help compile times that you have to build all this extra stuff, only to throw most of it away.
-
Why write code, when someone else already wrote it?
Why not import all code ever created by human kind just in case we might need some of it.
-
This post did not contain any content.
Wait until OP finds out about interpreters and compilers.
-
Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.
"Yes, I'd like a wheel. I don't want to invent it. Why, of course, give me the full package of wheel, axis, rotor, engine, fuel tank, windshield, mirrors, tire, front panel, brakes. This wheel will be great for me manually spinning cotton!"
-
Dead code elimination but with a different name for some reason
Because we're monkeys
-
Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.
cries in legacy systems
-
Except in the picture on the left, someone's actually reading it.
Something's gone wrong if you're looking in the node_modules folder.
Sometimes you gotta monkey patch that library because they won’t accept your pull requests to fix that bug.
-
Why not import all code ever created by human kind just in case we might need some of it.
I want to build a kick scooter. For that I need some wheels. So I import the well-known semi-truck framework. From that framework I take some huge wheels. They are too large and too many, but I guess I can make do with them.
But I need to attach the wheels to one another, so I import the bridge-building-library, because they have steel bars in there.
Lastly, to attach all of that together I import the NASA space ship framework because there's a hand welder in there, that's been deprecated years ago, but it's still rotting away in there because some important products still require the hand welder class for some entirely unrelated use cases.
-
This post did not contain any content.
Also C programmers using glibc
