What is the present state of NPM Packaging System?
As I recall, about 2-3 years ago I had experimented with what is called the npm install xyz through some tutorials, etc. The objective was to improve my tooling or toolchain at least with things like css/js minification, etc. along with Bootstrap customization. The idea was to then move on to other newer learnings like react, etc.
But I was soon disgruntled by the whole process! Neither bootstrap turned out to be an easy horse to tame, and NPM was like this astronomical universe of packages that keep on downloading into your folders! I soon lost taste of the whole thing and kept using my tried and tested stack of PHP scripts and using stock Bootstrap through CDNs.
But today, I want to give it another shot. Has NPM improved than earlier days? What is the best way to go about building a toolchain using it? Are there any useful guides that make the whole process easier to digest?
I don’t think there was really anything wrong with it 2 years ago but from regular usage I haven’t seen it change much since then other than more packages moving to namespaces (very good).
You probably just need to push through the initial learning. It works perfectly fine once you work it out which shouldn’t take long. I’d start with the react guide and it will show you how to set it all up
Agreed. Going back a few years beyond that there were some consistency issues, but since
package-lock.jsonandnpxwere added I find that things pretty much just work.For anyone unfamiliar:
package-lock.jsonis an autogenerated file that you check into source control. It contains the full dependency tree, including all derived dependencies, precise versions, and hashes so that you can be confident that what gets installed with a specific commit is always identical over time and across different systems. Way back in the mists of time (pre-2017) it would calculate that tree from scratch every time at runtime, which... honestly actually worked fine most of the time, but very occasionally broke things in difficult to diagnose ways, at times that were impossible to know or predict in advance.npxis used to execute a CLI tool from within the project'snode_modulesdirectory rather than installing it globally or hardcoding brittle paths to specific executables in your config. Prime example of where it's useful would be developing multiple React Native apps on the same workstation - rather than runningreact-native run-iosand having to remember which version of the CLI is installed system-wide, which is installed on the CI server, and potentially juggle compatibility issues between older and newer codebases, you just usenpx react-native run-iosand it'll call the binary [edit: or script] that's stored with that particular project and library version.I'm a newbie, but I've noticed that NPM isn't really uniquely bad, but just shows the symptoms of a modern language with tightly integrated package manager.
Namely, that you'll get giant dependency chains of imports, as the easy import makes library makers more willing to import other dependencies rather than just working with the standard library. I first noticed with a moderate sized (but somewhat amateur) Rust project, where'd you have hundreds of dependencies, with many duplicate-but-different-version packages in the chain.
I don't recall this being quite so common in Perl/Python compared to Rust/Node. And it's really not a problem per-se, but there definitely are security implications. And the disk usage is annoying.
It's not common in Python, because for the longest time it was a pain in the ass to release python modules.
NodeJS made it easy, so more people made more, smaller libraries. And because people did that, the language evolved around this concept of using small external libraries, and it kind of picked up from there.
I believe the pendulum is slowly swinging back to a more reasonable state, but of course, there's a lot of legacy.
webpack-dev-server brings in a ridiculous amount of cruft. I think a lot of dev tooling has been streamlined quite nicely which is probably responsible for a lot of this
I think part of the problem is that there's a need for a division between micro and macro imports
A micro-package acting more like a Co-pilot autocomplete, where the import gets embedded in your code, ideally as a single file (or perhaps even just inline).
A macro package being something beefy, like database abstraction.
And that ideally, macro packaging doesn't support multiple versioning for cross-dependency. If there is a conflict, it forces the 'fix the conflict' rather than 'hide the conflict,' in the way a type-safe language prevents you from mis-typing variables.
Python and Go have very rich standard libraries, and Go's standard library includes a number of standard interfaces that people try to adhere to even in their third party libraries. I think they (and maybe Perl?) don't suffer from cascading dependency trees despite the same ease of imports because you just need fewer dependencies.
Go also has a culture of having larger modules that do more, and also not importing a module just for one convenience function. "A little copying is better than a little dependency" is a Go proverb.
Contrast with JavaScript where people would try to use small libraries to avoid code bloat in browser apps. That's no longer needed now because build tools are better at removing unused code, but it resulted in a different culture where small libraries that just do one thing were considered better.
In older languages the dependancies were just invisible. You’d use libraries as compiled blobs where you have no visibility in to how many things those libraries imported themselves. And many projects just copy pasted libraries in to a vendor folder so again you’d see nothing.
Exactly, PHP and Python are different in that their core libraries are so powerful that you can do a lot of things without ever using their package managers (PyPi/Composer). But with Node, you're absolutely crippled without npm. Even for basic things like database access which are taken for granted in other languages, you need an npm package here which is quite an anti-pattern.
Part of is just that JS has a bit of a Jekyll and Hyde thing going on - nodejs is just one possible runtime. The whole other half is in browsers, where you're never going to have a large standard library available by default in the runtime - it's split into three different runtimes after all. Node was always lightweight since it's basically just V8 ripped out of Chromium.
I think Deno, which is in general trying to be highly opinionated to rectify some of node's issues, has more batteries included.
You could try https://create-react-app.dev