|
|
|
|
|
by jillesvangurp
1212 days ago
|
|
A different way to think about this is that most of the dependency hell relates to dependencies of your build tools. Not to dependencies of your actual application. And then of course some of those tools might be node.js tools and others might be things written in rust, go, or other languages. So, you need multiple package managers to deal with all of that. A neat way to organize that mess is to just use docker for tools and use maybe a simple Makefile to call those tools. Build your docker container once, push it to a docker registry and use it many times. Also nice for CI/CD. I did that for my website which is a simple static site that I generate with some bash scripts, pandoc, and other tools from markdown files. The scripts run in Docker. I don't use node.js for this but it doesn't matter. It's just another set of tools. The only tools I need on a laptop are docker and make to build this website. The issue with npm is that it pretends that everything happens inside of npm/node.js. Just npm this or that. It's a package manager. It's a build tool. And it's a way to run tools that you install via the package manager. And then almost as an afterthought there are a few run-time dependencies that it minifies into your actual application as part of some convoluted bundling toolchain (typically installed via npm). The actual size of those run-time dependencies is surprisingly small for most applications. And of course with modern web browsers and html 2 & 3, loading them as one blob of minified js is not necessarily even the best way to pull in dependencies anyway. You can load a lot of this stuff asynchronously these days. |
|