10 ms·

Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is sma

Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah, that's the obvious, easy way of doing this" it's not a package, it's a pattern. I can promise you, this was only ever added to packages because people wrongly assumed because since it's about "promises" (spooooky) it must be complex and worthy of packaging. As someone who doesn't do front-end work regularly, but also sank about 3 consecutive weeks (~6-8 hours/day) in the last year into understanding generators, yielding, and promises... I can tell you, the actually scary part about all of this, is pretty much no one just reads the fucking docs or the code they're adding. Moral of the story, especially in the browser: the reward of reading the code before adding it is enormous, you'd be surprised how often the thing you want is just a simple pattern. Taking that pattern and applying it to your specific use case, instead of imposing that pattern on your use case will give you giant wins.... Learn the patterns and you're set for life.

xyst 7y ago
tbh, it's something that should be included in a standard library (not a third party package or dependency)
- globular-toast 7y ago
  Or just copy and paste it into your project. Using a dependency for one line is beyond ridiculous.
ganstyles 7y ago
I wish I had as much time as you. Looking through the source code of the millions and millions of lines of code that get packaged with any modern application before you add things to your projects sounds daunting!
bdcravens 7y ago
create-react-app contains over 1000 packages. How long would it take to review all of those?
- hu3 7y ago
  There are alternatives to create-react-app. In fact, there are alternatives to React.
  - oldmanhorton 7y ago
    Have fun telling that to your boss
    - recursive 7y ago
      I rarely justify technical decisions to my boss, and when I do, they smile and nod.
      - bdcravens 7y ago
        I work in a similar environment, but I think it's fair to realize many do not.
      - hu3 7y ago
        Same. My boss doesn't micromanage technical decisions. Wouldn't work there otherwise.
    - michaelcampbell 7y ago
      Or the 25 people you work with across 4-8 different teams that finally settled on something that can allow people of different teams to move around without a lot of anguish.
    - karatestomp 7y ago
      Plus, pick the consensus option, any problems that come up are that option's fault. Fight for anything else, and everything's your fault. Even if it is actually better it can make you, personally, look worse.
overgard 7y ago
Unless the packages you're adding are trivial I seriously doubt you're looking that close. Are you really going to code review 20000 lines of someone elses code every time you're adding something? 100,000? Also their dependencies? Those are very reasonable numbers by the way.
- dirkt 7y ago
  I do review a list of dependencies when I investigate which node package to use. For those for which I can choose, that is. Sometimes I also take a look at the code. And I've chosen the one with less dependencies often enough.
- rubyn00bie 7y ago
  I said I look at them, I didn't say I inspect every single line of them. My point, which you've missed, is that simply looking at the code before you add it (spend a even a couple minutes) saves a lot of problems (like the one in create-react-app). FWIW, I also won't add something to my project if I see it has a ton of dependencies on stupid shit. Literally, I gave up on react after realizing `create-react-app` is what the community recommends. I'm glad I did too. It's an insane amount of bloat, for nothing included but a view renderer, and if that's how that community rolls... I'm gonna have to pass.
  - overgard 6y ago
    If you don't read the source, how can you claim such moral superiority? Whatever security issues, nefarious code, etc., are almost assuredly hidden down in the weeds where you're not looking. You think other programmers don't glance at the structure? Of course they do.
gramakri 7y ago
Do you also copy/paste the tests? https://github.com/then/is-promise/blob/master/test.js https://github.com/then/is-promise/blob/master/test.js . Just curious, sometimes it's really not just about the code but that it's continuously tested as well.
- SahAssar 7y ago
  When would the actual function body need to change in this case? These micropackages almost never break because of the actual implementation, they break because they are unpublished (like left-pad) or because they change how they are exported (like in this case). If the code is in your codebase it does not need a test.
grensley 7y ago
The bad code is almost never in the surface level library, it's in one of the buried dependencies.
throw_m239339 7y ago
> Call me crazy, but... I don't add things to my projects without looking at the source. This is manageable when you are using Packagist, this is manageable when you are using Maven, where all dependencies are flat. When compatibility issues arise they have to be dealt with upstream. This is NOT manageable when you are using NPM that will go fetch 30 different versions of the same package because crazy dependency resolution. This is not a JS issue like people claim here, this is 100% a NPM issue because whoever designed this was too busy being patronizing on Twitter rather than making sensible design decisions.
- deleted 7y ago
  [deleted]
Vinnl 7y ago
Note that in this case the dependencies also include compilers (for several languages, because front-end projects use multiple languages, have to be compatible with varying levels of support for those languages, and there's some leeway for the consumer of the scaffolding tool as well to choose which toolchain they use - but the other options get installed as well). Do you also review the code of your compilers and runtimes? Test frameworks? Static analysers?

xyst 7y ago

tbh, it's something that should be included in a standard library (not a third party package or dependency)

globular-toast 7y ago
Or just copy and paste it into your project. Using a dependency for one line is beyond ridiculous.

ganstyles 7y ago

I wish I had as much time as you. Looking through the source code of the millions and millions of lines of code that get packaged with any modern application before you add things to your projects sounds daunting!

bdcravens 7y ago

create-react-app contains over 1000 packages. How long would it take to review all of those?

hu3 7y ago
There are alternatives to create-react-app. In fact, there are alternatives to React.
- oldmanhorton 7y ago
  Have fun telling that to your boss
  - recursive 7y ago
    I rarely justify technical decisions to my boss, and when I do, they smile and nod.
    - bdcravens 7y ago
      I work in a similar environment, but I think it's fair to realize many do not.
    - hu3 7y ago
      Same. My boss doesn't micromanage technical decisions. Wouldn't work there otherwise.
  - michaelcampbell 7y ago
    Or the 25 people you work with across 4-8 different teams that finally settled on something that can allow people of different teams to move around without a lot of anguish.
  - karatestomp 7y ago
    Plus, pick the consensus option, any problems that come up are that option's fault. Fight for anything else, and everything's your fault. Even if it is actually better it can make you, personally, look worse.

overgard 7y ago

Unless the packages you're adding are trivial I seriously doubt you're looking that close. Are you really going to code review 20000 lines of someone elses code every time you're adding something? 100,000? Also their dependencies? Those are very reasonable numbers by the way.

dirkt 7y ago
I do review a list of dependencies when I investigate which node package to use. For those for which I can choose, that is. Sometimes I also take a look at the code. And I've chosen the one with less dependencies often enough.
rubyn00bie 7y ago
I said I look at them, I didn't say I inspect every single line of them. My point, which you've missed, is that simply looking at the code before you add it (spend a even a couple minutes) saves a lot of problems (like the one in create-react-app). FWIW, I also won't add something to my project if I see it has a ton of dependencies on stupid shit. Literally, I gave up on react after realizing `create-react-app` is what the community recommends. I'm glad I did too. It's an insane amount of bloat, for nothing included but a view renderer, and if that's how that community rolls... I'm gonna have to pass.
- overgard 6y ago
  If you don't read the source, how can you claim such moral superiority? Whatever security issues, nefarious code, etc., are almost assuredly hidden down in the weeds where you're not looking. You think other programmers don't glance at the structure? Of course they do.

gramakri 7y ago

Do you also copy/paste the tests? https://github.com/then/is-promise/blob/master/test.js https://github.com/then/is-promise/blob/master/test.js . Just curious, sometimes it's really not just about the code but that it's continuously tested as well.

SahAssar 7y ago
When would the actual function body need to change in this case? These micropackages almost never break because of the actual implementation, they break because they are unpublished (like left-pad) or because they change how they are exported (like in this case). If the code is in your codebase it does not need a test.

grensley 7y ago

The bad code is almost never in the surface level library, it's in one of the buried dependencies.

throw_m239339 7y ago

> Call me crazy, but... I don't add things to my projects without looking at the source. This is manageable when you are using Packagist, this is manageable when you are using Maven, where all dependencies are flat. When compatibility issues arise they have to be dealt with upstream. This is NOT manageable when you are using NPM that will go fetch 30 different versions of the same package because crazy dependency resolution. This is not a JS issue like people claim here, this is 100% a NPM issue because whoever designed this was too busy being patronizing on Twitter rather than making sensible design decisions.

deleted 7y ago
[deleted]

Vinnl 7y ago

Note that in this case the dependencies also include compilers (for several languages, because front-end projects use multiple languages, have to be compatible with varying levels of support for those languages, and there's some leeway for the consumer of the scaffolding tool as well to choose which toolchain they use - but the other options get installed as well). Do you also review the code of your compilers and runtimes? Test frameworks? Static analysers?