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.
> 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.
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.
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.
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.
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!
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.
This sort of cavalier attitude where 1000 dependencies are yawn-inducing in their commonality is why I feel vindicated in never having wasted my time with this kind of ecosystem. Eventually the house of cards will come down. Let's all pray that it happens sooner rather than later.
When WebAssembly gets direct DOM access we'll finally have options and we'll no longer have to tolerate JavaScript. I expect the JS community will settle down and get somewhat saner after that, too.
I suspect that over time there will be more pushback against dependencies, as I've seen in other communities, viewing dependencies as liabilities carefully chosen.
The problem isn't reading 1000+ dependencies, the problem is the 1000+ dependencies... There's no way, setting up a view renderer, in the context of a webpage, requires a 1000+ dependencies. I honestly did this exact thing with `create-react-app` and it's one of the reasons why I don't use/choose react. Too much bloat for no batteries included.
this doesn't make any sense. cra is webpack, but in a way that doesn't blow up every week. you can use react without bundlers, but what is the point. you'll be sitting there, without a dev env, no hot reload, no module resolution, minification, types, jsx, babel, ... any single one of these will get you 1000+ packages on the dev side. none of this is going into the published build of course.
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.
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.
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?
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.