6 ms·

Fixing security issues is nice, how about we go a step further and learn to write a one or two liner instead of inundating every project with 400,000 indirect d

Fixing security issues is nice, how about we go a step further and learn to write a one or two liner instead of inundating every project with 400,000 indirect dependencies?

bayindirh 4y ago
No. We must move fast, break things, and trust the network (because it's reliable and all that thing). Implementing your good code with no dependencies is heresy! It's a relic of the past. </rant>. On a serious note, you can implement a lot of things with a standard library of any language, and only time consuming machinery should be incorporated as external dependencies, but somebody didn't get the memo, I guess.
_fat_santa 4y ago
I think these packages are just holdovers from "Before ES6". I can see it be reasonable to pull in a package like this back before the functionality was implemented in native JS. All these packages are just holdovers that are only used by: * Legacy Projects that pulled them in way back when and never migrated to the native API's * Inexperienced developers not knowing this is part of standard JS now. You can't really do much about the former. For the latter though, NPM would be wise to plaster a link to MDN's docs on some of these packages.
- EamonnMR 4y ago
  * Tutorials written in the pre-ES6 world being copied and used in the ES6 world.
- danlugo92 4y ago
  But "isEven"??? That's one line of code in your utils module...
  - kuschku 4y ago
    In typescript? Sure. In vanilla JS? It’s more complicated. How do you handle someone inputting undefined/null/a string/a random object/NaN/etc? For isEven, you first need isNumber. And that’s where the complexity lies. ({}) % 2 == 0 // false ([]) % 2 == 0 // true "" % 2 == 0 // true "a" % 2 == 0 // false "1" % 2 == 0 // false "2" % 2 == 0 // true undefined % 2 == 0 // false null % 2 == 0 // true
    - BigJono 4y ago
      You don't handle it. Garbage in, garbage out.
      - laurent123456 4y ago
        Or garbage in => throw an exception and crash the app. This stuff should be fixed as soon as possible instead of invalid data slowly spreading in every layers of the app.
        BigJono 4y ago
        Assuming you're importing it as a black box abstraction, then absolutely. 'isEven' really shouldn't be a dependency though, either through npm or internally. 'x % 2 === 0' works fine for integers and can be inlined, or if you're using it a bunch and want slightly cleaner code, you can define it as a lambda alongside the code that uses it. Then everyone can see exactly what it's doing with the full context. The real issue is overabstraction. Even if you do everything "right" and have it as an internal dependency with all the correct error handling, it still makes the code a pain in the ass to read.
    - leodriesch 4y ago
      typeof x !== “number” ? false : x % 2 === 0
      - UncleMeat 4y ago
        Somebody in your codebase is going to use !isEven(x) to test for isOdd and introduce a bug. IMO, it should crash if passed a non-number.
Macha 4y ago
I'm not sure how to avoid this sometimes. I have a Rust project I've been working on. It has dependencies for: axum: the web framework in use serde, serde_json: Serialization of API responses sqlx: To talk to sqlite time: Standard datetime format with localisation and serde support tera: templating tracing: async logging uuid: UUID generation Of these, I feel they're reasonable dependencies. You could maybe quibble about uuid (which itself only depends on rng + serde with the features I've enabled), or tracing maybe, but they provide clear value. Anyway, those direct dependencies expand out to 300-odd transitive dependencies. So what do I do? Do I write a templating engine, HTTP server implementation, SQLite driver and JSON library from scratch to build my little ebook manager?
- Tainnor 4y ago
  300-odd seems reasonable (or at least unavoidable, given modern realities). JS projects typically have much more, and additionally, you don't even get deduplication of modules, so you may have three different versions of the same module on disk.
  - criddell 4y ago
    I don't think you can reason about quality in a modern Javascript project. Keeping a close eye on thousands or tens of thousands of modules isn't practical. If Software Engineers were more like "real" engineers (ie PEs) they could never sign off on a project built like this.
- 65 4y ago
  300 is nothing compared to the typical Node project. It's typical for a basic React project to have over 14,000 dependencies.
  - zachrip 4y ago
    Can you please source this? A react project can be so many things...do you mean create react app? A custom react app?

Fixing security issues is nice, how about we go a step further and learn to write a one or two liner instead of inundating every project with 400,000 indirect dependencies?

bayindirh 4y ago

No. We must move fast, break things, and trust the network (because it's reliable and all that thing). Implementing your good code with no dependencies is heresy! It's a relic of the past. </rant>. On a serious note, you can implement a lot of things with a standard library of any language, and only time consuming machinery should be incorporated as external dependencies, but somebody didn't get the memo, I guess.

_fat_santa 4y ago

I think these packages are just holdovers from "Before ES6". I can see it be reasonable to pull in a package like this back before the functionality was implemented in native JS. All these packages are just holdovers that are only used by: * Legacy Projects that pulled them in way back when and never migrated to the native API's * Inexperienced developers not knowing this is part of standard JS now. You can't really do much about the former. For the latter though, NPM would be wise to plaster a link to MDN's docs on some of these packages.

EamonnMR 4y ago
* Tutorials written in the pre-ES6 world being copied and used in the ES6 world.
danlugo92 4y ago
But "isEven"??? That's one line of code in your utils module...
- kuschku 4y ago
  In typescript? Sure. In vanilla JS? It’s more complicated. How do you handle someone inputting undefined/null/a string/a random object/NaN/etc? For isEven, you first need isNumber. And that’s where the complexity lies. ({}) % 2 == 0 // false ([]) % 2 == 0 // true "" % 2 == 0 // true "a" % 2 == 0 // false "1" % 2 == 0 // false "2" % 2 == 0 // true undefined % 2 == 0 // false null % 2 == 0 // true
  - BigJono 4y ago
    You don't handle it. Garbage in, garbage out.
    - laurent123456 4y ago
      Or garbage in => throw an exception and crash the app. This stuff should be fixed as soon as possible instead of invalid data slowly spreading in every layers of the app.
      - BigJono 4y ago
        Assuming you're importing it as a black box abstraction, then absolutely. 'isEven' really shouldn't be a dependency though, either through npm or internally. 'x % 2 === 0' works fine for integers and can be inlined, or if you're using it a bunch and want slightly cleaner code, you can define it as a lambda alongside the code that uses it. Then everyone can see exactly what it's doing with the full context. The real issue is overabstraction. Even if you do everything "right" and have it as an internal dependency with all the correct error handling, it still makes the code a pain in the ass to read.
  - leodriesch 4y ago
    typeof x !== “number” ? false : x % 2 === 0
    - UncleMeat 4y ago
      Somebody in your codebase is going to use !isEven(x) to test for isOdd and introduce a bug. IMO, it should crash if passed a non-number.

Macha 4y ago

I'm not sure how to avoid this sometimes. I have a Rust project I've been working on. It has dependencies for: axum: the web framework in use serde, serde_json: Serialization of API responses sqlx: To talk to sqlite time: Standard datetime format with localisation and serde support tera: templating tracing: async logging uuid: UUID generation Of these, I feel they're reasonable dependencies. You could maybe quibble about uuid (which itself only depends on rng + serde with the features I've enabled), or tracing maybe, but they provide clear value. Anyway, those direct dependencies expand out to 300-odd transitive dependencies. So what do I do? Do I write a templating engine, HTTP server implementation, SQLite driver and JSON library from scratch to build my little ebook manager?

Tainnor 4y ago
300-odd seems reasonable (or at least unavoidable, given modern realities). JS projects typically have much more, and additionally, you don't even get deduplication of modules, so you may have three different versions of the same module on disk.
- criddell 4y ago
  I don't think you can reason about quality in a modern Javascript project. Keeping a close eye on thousands or tens of thousands of modules isn't practical. If Software Engineers were more like "real" engineers (ie PEs) they could never sign off on a project built like this.
65 4y ago
300 is nothing compared to the typical Node project. It's typical for a basic React project to have over 14,000 dependencies.
- zachrip 4y ago
  Can you please source this? A react project can be so many things...do you mean create react app? A custom react app?