481–490 of 797 posts
Earlier quoted context omitted.
Rand, uuid, and no built in logging implementation are three examples that require crates but probably shouldn’t.
No built in logging seems pretty crazy. Is there a story behind that?
Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…
The e18e community are reducing dependencies in popular libraries and building tools to prevent and reduce the impact of such attacks. Join if you want to help out! https://e18e.dev/
Just this morning, after trying to make the case over the past year, we had a change landed to remove more than a dozen dependencies from typescript-eslint! https://bsky.app/profile/benmccann.com/post/3m6fcjax7ec2h
Earlier quoted context omitted.
> if I am going to run some code from somewhere and I haven't read it, it goes in a container How does this work? Every single npm package has tons of dependency tree nodes
Everything runs in the container and cannot escape it. Its like a sandbox. You have to make sure you're not putting any secrets in the container environment.
Earlier quoted context omitted.
What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?
I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates. I don't run much on the root OS of my dev machine, basically everything is in a container…
Why the biggest package mess is always with the Node ecosystem? Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good") Why certain kind of mindset is typical to this community? Why the…
Why the biggest package mess is always with the Node ecosystem? Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good") Why certain kind of mindset is typical to this community? Why the…
Feels good, just for a second, to type pretence you're above everyone doesn't it? Just for those few seconds, you're better than a big whole arbitrary collection of people, and for those few seconds you have relief from the reality of your life.
ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
Funny that this is getting downvoted, but it installs dependencies super fast, and has the same approval feature as pnmp, all in a simple binary.
See also: https://news.ycombinator.com/item?id=46005111 As it arguably would have reduced impact (I'm one of the Renovate maintainers and have recently pushed for this to be more of a widely used feature)
Earlier quoted context omitted.
I might say that every interpreter has a different minimum dependency level just to create a simple application. If we're talking about Node.js, there's a long list of dependencies by default. So yes, in comparison, modern vanilla PHP with some level of developer discipline (as you mentioned) is actually quite suitable, but unfortunately not popular, for low-dependency development of web applications.
The language and capabilities of the platform indeed have a lot of influence on how many packages the average project depends on. With Swift on iOS/macOS for instance it’s not strange at all for an app to have a dependency tree consisting of only 5-10 third party packages total, and with a little discipline one can often get that number down to I think it’s time to beef up both JavaScript itself as well as the platfo…