So...just you, in your career, have spent between 1 and 2 total weeks of developer time building the exact same functionality, and you're curious why an open source project that cuts that time down to like an hour is popular?
I'm also a little suspicious of the claim that it's the exact same, because Faker has a lot of functionality under the hood, but you've more or less demonstrated why it's useful in this comment.
And of course the reason this new version exists is because the previous version was deliberately broken.
Why add significant dependencies for the sake of a few hours (maybe a day or two in the long run if you need to add functionality)?
A) most of the dependencies that Faker has are common with lots of JS projects that I work/have worked on in the last few years. Looking at that dep list[0], I'm familiar with most of them. They're mostly common packages. To some degree, I'm relying on the thousand eyes here.
B) In terms of security risk, Faker runs in test suites to generate data and locally on dev machines, sometimes, to populate sample DBs. It lives and runs in managed environments and doesn't get packaged into prod anywhere. The risk profile isn't nonexistent, but it's also not a massive risk.
C) I really think we're underrating the amount of work that would required to recreate this project (not uncommon here). Faker can spit out 205 different types of random data in 46 different languages/dialects. Building that is not a two day project (evidenced in the fact that people have been working on this for years now); making sure you can generate all that data correctly in all those different languages is a non-trivial task; building and maintaining it internally will take dev time and energy and will continue to require that time and energy on an ongoing basis.
You're talking about this choice here and in other comments with an air of "silly JS devs, just build this easy thing!". I don't know if it's your intention, but you're coming off dismissive and ignorant. People think about these tradeoffs all the time, and sometimes decide to use packages like this. I think it might behoove you, if you find someone's decision confusing, to start from the position that they are also reasonably competent professionals and see if you can understand why a competent professional might make a different decision than the one that seems obvious to you, rather than assuming that if someone makes a different decision they're stupid and/or incompetent.
[0]: https://github.com/faker-js/faker/blob/main/package.json
`npm install --save faker` and boom you have access to a huge variety of random test data, across different locales. Doesn't stretch my imagination to see the appeal.
I wonder if those who say "2 days?! Just npm install!" answered those questions, or if they googled "nodejs fake data generator" and installed it onto their businesses main product in the next 5 minutes.
1) Is the project built correctly
2) Is it the correct project for your issue
3) Is the project maintained
4) Is the project going to be maintained for the lifetime of your project
5) Is the project secure, and how risky is including it to your project?
And if these are all good then sure, it makes sense to include it in your project. And this is good engineering. But what people seem to do is go "Oh hey, I need to get a random name from a dictionary of names. Let's google that. Oooh faker!" without even thinking these questions through.
`npm install @faker-js/faker --save-dev`
Could I/anyone else build this? Of course. Could I do it so thoroughly, provide support for it, and still do my day job? Not easily, not as easily as I could install this project and use it.
Also keep in mind it's not like those 8 contributors are throwing a full 40 at this project every week.
I don't think it's a bad philosophy, just different perhaps from yours (and mine).