what should this be made with
More seriously, as much as I'm personally not a huge fan of JS (but this is TypeScript?) I don't see how such comments add to the conversation. This particular package even seems to be very considerate with its dependencies: there's only a half dozen, and relate to obvious things like terminal coloring/manipulation, syntax highlighting, and diff generation… Now, I've not explored the full tree to see if those drag in the world, of course.
Sometimes, I think the hate on dependency trees gives them a bad rap. Code reuse lets people build things easily & quickly without having to badly reinvent every wheel! Sometimes, I get notified of a JS dependency with a security vulnerability where if a user can control how many spaces are used for indentation in some library's pretty-printer they can RCE and I die a little inside.
I think there are easier ways to get a side-by-side diff, but this tool does do a remarkable job of reproducing GitHub's aesthetics.
EDIT: Anyway, didn't mean to shit on author's work. (S)he apparently put fair amount of work into it, and the result looks great.
If there are dependencies, there could be security risks.
JavaScript and NPM just have higher market share, so that's where attackers are more likely to focus their efforts. This is akin to all the people who used to say Macs aren't or can't be infected with malware.
What you could do is just audit the package list and try to make a reasonable decision. 35 different packages for a small script, some with almost no GitHub stars or downloads? Maybe cause for concern. A few well-known libraries? Probably less concerning. You'd need to audit the entire lock file to really be sure, but this gives you some idea, at least.
It's true that JS developers generally seem to tend towards using a larger number of smaller libraries on average, so it's possible the risk is a bit higher both due to that and the market share, and maybe a few other reasons, but it's not like there are any fundamental differences here.
Each project will have their own way of handling dependencies, regardless of the language. You have to evaluate individual projects in any language on a case-by-case basis, and not just stereotype based on the language used. If your comment instead was ripping on the actual contents of package.json (or requirements.txt etc.), then you'd quite possibly have a valid point, but balking at the mere existence of the file is pretty ridiculous.
Or to say "When I depend on a library A in say Python I can be reasonably sure that it won't download and execute random shit from Internet", which is just completely untrue and misguided in a lot of ways. It's absolutely just as easy for anyone to backdoor a Python package as it is to backdoor an NPM package, and it happens all the time. It's possible it could happen a lot more frequently in the future, too.
You could argue that statement's true in a sense, but given that same sense it's also true of Node; it's not a good way of thinking about dependency supply chain attacks.
Can you give an example?
I'm aware of the banner thing, but I think that was only a few projects, and that's something else entirely.
But then again, I'm not that well versed in nodejs to judge by that experience alone. As I said in the middle, I'm not trying to dismiss author's work. I'm sorry for the tone of my previous replies. This comment thread I spawned is also very off-topic.
>Over a year ago, I was investigating using Prisma to be the ORM for a GraphQL API of a Postgres database. When doing a proof-of-concept, I discovered that under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres. This extra middleware layer between my frontend code and postgres generated some pretty poor performing queries that took 50% longer to complete than the queries generated by using Hasura as our whole GraphQL API.
Doesn't seem like it's worth writing off Node/JavaScript/NPM just due to this large project making a questionable design decision
>like create-react-app, which feels the right thing to do is to spawn my $EDITOR when it sees exception in the log (which it hides)
Just seems like it's Facebook's problem. I wouldn't be surprised if there's some Python package out there that does something similar. There's nothing inherent about JavaScript that makes this more likely to happen. Maybe there's something inherent about the community, but I'd really need to see a thorough empirical analysis of packages across a lot of languages before I start making judgments about that.
It might be worth making fun of a particular package if they pull in way too many other packages, but it's still all a case-by-case evaluation.
I personally strongly dislike JavaScript and much of its ecosystem, myself; it's just the kneejerk pattern-matching reaction that I thought was unwarranted.