6 ms·

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

by qwerty2021 5y ago

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 5y ago
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
- havkd 5y ago
  Command line argument parsing and config loading both seem like something that the standard library should provide.
  - megumax 5y ago
    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 https://github.com/spf13/cobra
    - MrStonedOne 5y ago
      php
    - kitsunesoba 5y ago
      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 https://github.com/apple/swift-argument-parser
    - morelisp 5y ago
      > 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 5y ago
        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 5y ago
        "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 5y ago
        Sure, and Node gives you the process.argv array. The point is having higher level APIs than that.
        morelisp 5y ago
        getopt is a higher-level API. process.argv is equivalent to, uh, argv.
        voldacar 5y ago
        it feels like the more higher level APIs we add, the shittier and more annoying software becomes
    - Groxx 5y ago
      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 5y ago
        I don't understand, what's wrong with Go's flag, compared to, say, python's argparse?
- qwerty2021 5y ago
  >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 5y ago
    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 5y ago
      honestly, yeah. I just saw "command line parser" and dismissed the rest as useless bloat
tyingq 5y ago
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 5y ago
  Maybe we need to hold the popular packages accountable for stuff like this.
  - jart 5y ago
    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?

afavour 5y ago

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

havkd 5y ago
Command line argument parsing and config loading both seem like something that the standard library should provide.
- megumax 5y ago
  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 https://github.com/spf13/cobra
  - MrStonedOne 5y ago
    php
  - kitsunesoba 5y ago
    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 https://github.com/apple/swift-argument-parser
  - morelisp 5y ago
    > 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 5y ago
      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 5y ago
        "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 5y ago
      Sure, and Node gives you the process.argv array. The point is having higher level APIs than that.
      - morelisp 5y ago
        getopt is a higher-level API. process.argv is equivalent to, uh, argv.
      - voldacar 5y ago
        it feels like the more higher level APIs we add, the shittier and more annoying software becomes
  - Groxx 5y ago
    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 5y ago
      I don't understand, what's wrong with Go's flag, compared to, say, python's argparse?
qwerty2021 5y ago
>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 5y ago
  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 5y ago
    honestly, yeah. I just saw "command line parser" and dismissed the rest as useless bloat

tyingq 5y ago

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 5y ago
Maybe we need to hold the popular packages accountable for stuff like this.
- jart 5y ago
  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?