I recently cleaned my NPM cache at work after 9 months, it was 6GB. ES6 is a massive improvement, but Node's standard library is still lacking and the sheer amount of tooling needed to be effective and up to date is too much.
It is badly designed.
> There’s no clear design philosophy. Early PHP was inspired by Perl; the huge stdlib with “out” params is from C; the OO parts are designed like C++ and Java
There's even complaints about PHP 5.2, but PHP 5.4 had just been released a month earlier:
> If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. [...] Note that this flag was removed in PHP 5.2.5.
> foo()[0] is a syntax error. (Fixed in PHP 5.4.)
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all. (Fixed in PHP 7)
> There is no finally construct (Fixed in PHP 5.5)
> Methods cannot be named e.g. “list”, because list() is special syntax (Fixed in PHP 7)
I'm going to stop there. Not saying any of it wasn't valid criticism or that some of it doesn't apply to this day. Just that too many people, yourself included, are happy to throw a 6 year old blog post at a language that has continued to evolve since. It's also strange that you say it isn't criticized for a big and clumsy library, because in the link you provided about half of the page is complaints about the library.
The author never actually used PHP and just collected a bunch of "facts" from the Internet without even testing some of these things himself.
Relevant article: https://hackernoon.com/im-harvesting-credit-card-numbers-and...
Is that how people use NPM?
Also maven central does NOT support unpublishing of binaries. So if you have version 1.2 of something and you have scanned it once for vulnerabilities, it should always be the correct one. Nobody can publish again 1.2 in the central repo
Who told you that? I don't think "inherently secure" is a thing in the tech industry.
1. Package naming: All the good names will be gone soon, which'll probably lead to big players trying to get package names of little players. Which will then result in broken dependencies a la left-pad. Afaik the latter has been solved in NPM [1]. The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.
2. The power of deps and our reliance on good will: When installing dependencies, we basically grant them the power to wreak any kind of havoc they want. The ways we mitigate the worst: Belief in the magical power of open source, mostly using libs that are popular (hence might've gotten a good read by an IT-sec person) and at enterprise scale some static analysis tools to get an idea of how it interacts with your system. I think we're in need of a technical solution at the package manager level, where a dependency has to explicitly ask for certain capabilities (similar to how Android apps work).
[1] http://blog.npmjs.org/post/141905368000/changes-to-npms-unpu...
> The former is probably more of a usability problem, we want installation to be simple and able to install deps just by remembering their name.
There's a point beyond which the desire for simplicity creates dangerous abstractions. A developer should expect to put more effort into installing deps than just remembering a package name.
Worth noting that ES2017 added String.prototype.padStart and String.prototype.padEnd. The whole left-pad thing is blown out of proportion.
Second, you shouldn't be relying on npm for deployments. You dig your own grave. If package deletion is a concern, then host a mirror with something like Nexus [0], or pay for a service [1] [2] to do it for you. Over the years there have been a few local npm mirror tools [3], but I don't think any of em have really caught much traction. There's also the option of bundling each release. For that you can use a tool such as Webpack [4], or take it one step further and generate a single binary using something like pkg [5].
Developers also have the option of forking their dependency graph and updating references in package.json. Sooner or later you'll start to find bugs in your dependencies and have to fix them. It's your responsibility, you own all that code. Don't be afraid of maintaining your own fork. If you find a critical issue you'll probably need to be able to deploy your update without depending on a third-party anyway. This is fairly common in other ecosystems. Heck, you can also just check in your node_modules folder into version control.
Don't get me wrong, npm certainly has its fair share of problems, and historically they haven't had the best defaults... But there's usually ways to work around the issues, and they're gradually working towards improving things. It's the developer's responsibility to handle their ecosystem's problems, which is also nothing new in the world of software development.
[0] https://www.sonatype.com/download-oss-sonatype
[1] https://jfrog.com/artifactory/
This is where you have to start questioning the benefits of using node/npm/js on the backend. We're all stuck with it on the front end for the foreseeable future.
I've never had any of the problems in node/npm using NuGet/C# for example.
At some point, I raised my hands and emailed my boss about a new project using node, essentially saying "this is dumb. left-pad is dumb. is-number is dumb. is-odd is dumb. the amount of packages depending on these is dumb. And I won't be arsed to fix it because I value my time, so I'd rather just jump back to an ecosystem that has its shit together because the result is the same simple API pushing json either way we go."
node/npm sucks IMO. Sorry, but the problems I have to fix daily are not interesting, and conquering the mountain and being able to say I fixed all those every-day problems with it is not worth much on the job market.
If the amount of web backends suddenly needs node because they suddenly stop pushing json all day long, because node/npm is the only ecosystem that offers that solution, then you have a compelling reason. But other languages do json APIs just fine right now and have less ecosystem paper cuts.
[0] http://blog.isquaredsoftware.com/2017/07/practical-redux-par...
When Node and NPM first came out and I thought, while not perfect, they were a really promising set of technologies. Now, NPM specifically is something I will go out of my way to avoid. And by virtue of the fact that NPM is so closely tied with Node, I tend to avoid Node as well. Which sucks because I have always enjoyed programming in Javascript.
If anyone has come out with a curated alternative to NPM, please let me know.
It took a while to learn this lesson, but it pm;u tales a few seconds in the process of deciding if you want to use a package, to check out it's dependencies, I also check out the git page and license. Is it active, is it open-source, does it have far too many dependencies, is it in regular use.
https://www.npmjs.com/package/serverless
That's serverless. I was surprised to see it uses graphql as a default, and looking at graphql, how many dependencies does it have? Just one, which has no more. So that chain ends quite quickly.
It doesn't take long looking at the dependencies to see that the same packages get used again and again throughout the community. So you'll find you won't keep going down this path once you are comfortable with the packages.
Having said all of that, it is also good practice to look at the source of a package, and decide if you could do it better and easier yourself. It is amazing how many packages are only a few lines of code, and fairly unnecessary.
Personally I'm not to worried about the size of my node_modules since it doesn't reflect what gets transpiled into the target anyway, but yes, if you have a bunch of projects sitting on your hard drive, it can get a bit busy.
https://www.reddit.com/r/programming/comments/886zji/why_has...
The package situation is a serious problem for distro maintainers, which AFAICT have basically given up packaging any npm packages the traditional way. Luckily Nix[1] and Guix[2] can most likely support automatic importing from npm.
Incidentally, one of the many things I love about typescript is that it has zero non-dev dependencies [3].
[1] https://github.com/svanderburg/node2nix [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg008... [3] https://www.npmjs.com/package/typescript?activeTab=dependenc...
You don't need to use NPM to run node programs. The binaries provided by node.js website are standalone (no dependencies): http://www.nodejs.org/dist/
