[qwerty2021]

I checked the readme of both those packages and I can't for the life of me understand why would anyone use either of them.

Why the fuck do all these leftpad is-even hello-world tic-tac-toe packages have millions of downloads?

[afavour]

Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.

[havkd]

Command line argument parsing and config loading both seem like something that the standard library should provide.

[megumax]

Ok, now, what languages beside Python and Go provide Command line argument parsing? And Go doesn't do that in a `professional` way. You either write your own, which can easily turn into a clusterfuck or use a third party library. Even in Go, people use cobra[1]. Also embedding a lot of functionality in a standard library isn't great as well, because if some vulnerability is found, it's really hard to patch it, because you need to push versions and (for example on Linux) some distro maintainers won't push it for `stability` etc. A standard library should provide basic functionality (in most general areas), but not very advanced one.

[1] https://github.com/spf13/cobra

[morelisp]

> what languages beside Python and Go provide Command line argument parsing?

Even POSIX gives you getopt(1) and getopt(3). What other language doesn't? I can only think of Java.

[megumax]

POSIX is not ISO C or C++ standard. On Windows, what are you gonna do?

Also, other languages are Rust, Kotlin, Swift (to name a few `modern` ones). Yes, Kotlin and Swift have `first class` CLI parsing libraries, but they are not part of standard library.

[morelisp]

"First-party" is distinct from "first class". The difference between a first-party library and the standard library ranges from "slightly weaker compatibility guarantees" to "it's supported in all environments where it makes sense, but the language can run unhosted so that's not everywhere" to "no difference at all, we just didn't want to package it with the compiler".

You're also missing the forest for the "well actually" trees: Lots of languages have argument parsing in their stdlib.

[afavour]

Sure, and Node gives you the process.argv array. The point is having higher level APIs than that.

[voldacar]

it feels like the more higher level APIs we add, the shittier and more annoying software becomes

[morelisp]

getopt is a higher-level API. process.argv is equivalent to, uh, argv.

[kitsunesoba]

It's not part of the standard library, but Swift has the first-party ArgumentParser[0]. Other languages could use a similar model (though what "first party" means for JavaScript is unclear).

[0]: https://github.com/apple/swift-argument-parser

[Groxx]

as if there even was one command-line or config standard. especially across different operating systems.

it absolutely does not belong in stdlibs, where it can never be changed. that's how you end up with too many terrible CLI tools using Go's `flags` package.

[chakkepolja]

I don't understand, what's wrong with Go's flag, compared to, say, python's argparse?

[MrStonedOne]

php

[qwerty2021]

>Command line argument parsing

20-30 LoC maybe. `process.argv.slice(2).forEach(str => ... )`.

there is no access to the raw command-line invocation, sadly, so you really can't really do anything fancier than that.

>config loading

that thing "RC" package does - looking up the config file in random locations - is really strange to me. aren't you the one in control of where it is stored?

[afavour]

Just looking at the readme for Coa it’s very obviously more than the code you outlined. You’re arguing against a strawman here.

[qwerty2021]

honestly, yeah. I just saw "command line parser" and dismissed the rest as useless bloat

[tyingq]

Chained dependencies? If you can fool one popular package to depend on you, you ride their coattails.

And perhaps some faked download numbers to lend an air of authenticity.

[havkd]

Maybe we need to hold the popular packages accountable for stuff like this.

[jart]

Before we go mobbing innocent open source devs on Twitter, it'd be great to know how far NPM has progressed on 2FA. Up until 2018 NPM didn't have 2FA at all. They just introduced it. It'd be nice if they could give some kind of progress report on how widely adopted it's become. Ideally it should be required for publishing packages. Or at the very least, it'd be great to have some transparency about which package authors are actually using it, who aren't, and who's delegated their authorization to some other vendor like Travis -- so we as users can make our own informed choices about risk. It'd also be useful to have charts that log dependency gravity over time since an important question in situations like this is: did RC and Coa go from 70k to 17m users yesterday? Or have they been established for a long time?