I’m following the odin project to learn web development. I had read about malicious packages in npm multiple times, so I avoided it until now. I’m on the webpack lesson now, and to use webpack, I need to install it using npm. I also see that it has many dependencies, and those dependencies will have other depenedencies and so on.
Why is it like this? Is there any other tool like webpack that doesn’t require npm? Or rather, can someone clarify how to properly use npm or link a guide that explains it? I have this kind of fear and reluctance about using npm after all the things I read.
You must log in or # to comment.
You’re good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you’ll just go ahead with it. (Like most people do without questioning it.)
You’ll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.
It’s also worth noting that your potential impact is considerable lower if you’re only doing local test and development work, not publishing or publicly serving anything. I’m not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.
You shouldn’t eat candy given to you by strangers. If you’re in a large group and someone knows the candy, maybe. Code is food for your computer. Be wary. Our large Open Source group of friends has learned about many kinds of candy and shouts loudly when some in the group becomes ill. You don’t want to become ill. Some risk exists, but with a large group it is generally ok. Don’t install packages as root, don’t install what you don’t need.
I run my frontend builds through Docker (also during development). By isolating access to the host system to the files/folders necessary for development I’ve shielded off the majority of current realistic attacks I’ve seen as NPM based exploits. I’m certain the approach can be replicated for other frameworks, but we use Ember and docker-ember. I doubt it runs as smoothly on a non-Linux OS.
Can you provide a guide for how to use containers for that? I’m not familiar with them so I have no idea how to do that.
You could find out about the way we do it at https://github.com/madnificent/docker-ember but I would not if I were you.
The real risk, today at least, does not seem utterly huge. Jumping in this rabbit hole of containers is another topic in itself. I suggest continuing your learning as you do now and maybe revisit this later. You will learn faster that way.
Feel free to check what we did on the link above and ask questions later or whenever you feel ready for this topic.
I don’t really understand a lot of things in the repo
I’ll have a look at it sometime later thanksFor now I have made a container image with node installed in it after following some guides
I enter the project directory and then run this
podman run -it --rm -p 8080:8080 -v $(pwd):/app/$(basename "$PWD"):z my-node-image:latestLooks good to me.
docker-ember largely automates such a setup with specific mounts for linking node modules from other folders, being able to bind to localhost for when you run the backend on your own machine, and exposing ports for livereload. May include other secret sauce. Some of that is closely tied to EmberJS.
I’m a fan of using tools you understand. What you show here is comprehensible and sufficient for now👌
Finding a Webpack replacement that doesn’t use NPM at all is going to be hard, but there are certainly alternatives that don’t require the 1000+ NPM dependencies required to use Webpack.
Some alternatives you can consider are Rsbuild and Farm. Part of the reason they use so much fewer NPM dependencies is because they’re written in Rust, so they’ll have Cargo dependencies instead, but you shouldn’t notice anything of that. Of course if you want to audit everything it’s not that much easier, but at least the Cargo ecosystem seems to have avoided quite some of the mistakes that NPM made. But yes, in the end it still comes down to the extent that you trust your dependencies.
I really do enjoy that the web development community is finally getting excited about faster development tools, but…
written in Rust
It seems like there’s a new version of the old joke about vegans.
Q: How do you know someone
is a veganwrites code in Rust?
A: They’ll tell youI don’t understand why the developers of these tools have to point out that they’re written in Rust in the first few sentences about the project, as if that’s the main feature? Programming language is an implementation detail, not a core feature. I don’t care what language my developer tools are written in as long as they’re fast.
Hehe, yeah, I actually agree in principle, although in the context of web tooling I think it’s at least understandable. For many years, web tooling was almost exclusively written in JavaScript itself, which was hailed as a feature, since it allowed JS developers to easily jump in and help improve their own tooling. And it made the stack relatively simple: All you needed was Node.js and you were good to go.
Something like the Google Closure Compiler, written in Java, was for many years better than comparable tooling written in JS, but remained in obscurity, partially because it was cumbersome to setup and people didn’t want to deal with Java.
Then the JS ecosystem ran into a wall. JS projects were becoming bigger and bigger, and the performance overhead of their homegrown tooling started frustrating more and more. That just happened to be the time that Rust came around, and it happened to tick all the boxes:
- It showed that it can solve the performance bottlenecks.
- It has great support for WASM, which many web developers were having an interest in.
- Its syntax is familiar enough for TypeScript developers.
- It has a good story around interior mutability, which is a common frustration among TypeScript developers, especially those familiar with React.
I think these things combined helped the language to quickly win the hearts and minds of many in the web community. So now we’re in a position where just name dropping “Rust” can be a way to quickly resonate with those developers, because they associate it with fast and reliable and portable. In principle you’re right, it should just be an implementation detail. But through circumstance it seems to have also become an expression of mindshare – ie. a marketing tool.
Yeah don’t worry about it too much. Ensure you have the correct name when installing your library but that’s about all you can do personally.
Any other solution will have some security flaws. NPM has a few more than it should but essentially the entire web is built around it. Sorry man, you don’t have any other choices.
How to use it properly? Any npm tutorial will show you quickly. Always check you’ve got the right thing, always check the library is large enough that if something goes wrong it’ll be noticed, and know there’s no way to be completely safe without never using libraries.
If you’re learning the web though there’s no way to avoid npm.
As an alternative to Webpack, I like esbuild. Not as powerful, but way simpler to use, and handles maybe 85% of common use cases.
