Alternative to Zod Mock.

[louiss0]

Motivation

I'm here to ask for an alternative to a library called Zod Mock. Due to the recent popularity of Zod as a universal validation library.
Someone decided to create a Mocking library that is built on top of faker and Zod called Zod Mock. While it's a good library developers can't be sure that it will update along with faker or that it will evolve with better features.

Concerns

I did go on discord to talk about this but it seems like the faker team is busy with the main library. Time dedicated to learning Zod seems to be too much. I don't know what to do to help but Zod is becoming the standard finding someone who can understand it shouldn't be too difficult. I believe that that most of the understanding of this library is mostly important before initial release.

Benefits

The benefit of creating this library is more downloads which means better reliance and support for faker.
Developers have a mock library that is updated when faker is.

Overall I believe that supporting zod will also boost faker.

[JessicaSachs]

Yeah, I’d love to see better integration for mock data and Zod. It’ll take a while and probably doesn’t need to live in the Faker repo itself, but I’m happy to keep this discussion open.

[Shinigami92]

You are writing that zod is the defacto standard, but what if one day e.g. https://github.com/fabian-hiller/valibot will take the lead? Do we, the Faker Team, also need to maintain this as well?

Are you interested in that the core maintainers of Faker maintain these cross libs? (Then actually no, sorry)
Or are you just interested to publish e.g. something from the @faker-js/* npm scope and have a faker-js GitHub repo? (Then we could discuss that)

But if second: what is holding you back from releasing just your own lib? Like zod-faker?
Or even help contributing to the already existing zod mock repo?

[louiss0]

I understand that you guys want to remain neutral when it comes to the Valibot vs Zod problem.

Are you interested in that the core maintainers of Faker maintain these cross libs? (Then actually no, sorry)

I really thought It would be best if experts on mocking and fake data would be able to create a better API for things an average dev would never think about.
But since this seems to be too much for the team I can only rely on Jessica to do it.

But if second: what is holding you back from releasing just your own lib? Like zod-faker?

What's stopping me is that I'm not an expert in mocking in fact testing is a new concept to me. I'm a scrub programmer.

Thanks for the response I hope you guys can help If Jessica wants to tackle this problem.

[ST-DDT]

I think you are looking at it with a different mindset then we do.

We as the Faker team are currently congested with our current tasks for this library alone to a point where actual contributions to this repository cannot be reviewed on time.
We would like to change that, but our time is limited. If you could help with the reviews that would help a lot.

Now back to topic: You come along and share this library with us that uses faker under the hood to generate data mock data. We love hearing about usages of our library as it gives us valuable insights into real world usecases. We use these and our vision of Faker to improve the api and the developer experience.

Now to the problematic part: You suggest that we take over the project:

• because "we probably know how to do it better"
• you expect that we help Jess without offering your help
• you think that the developer might stop improving the library and fear it getting stale
• You try to sell us the potential benefits without taking the costs of that into consideration.

1. We do have lots of experience in that regard.
   And generating useful complex data is hard.
   In fact it is very hard.

Let's have a look at the following example:
email: z.string().email().optional()

You might think, easy just generate an email address. But in reality you might want to have an email address based on the users name.
That might be split across multiple fields e.g. firstName and lastName. The fields may not be called like that. Maybe it uses snake case. Maybe it uses surname. What about countries where you have multiple surnames based on your parents?

As you can see there are a lot of things to consider, that's why we aim to help developers create their data, but dont provide any "complex object generators" ourselves.

2. OpenSource lives because everyone is putting some effort into it. We all started as beginners and got better over time.
   If you dont want to start big consider contributing to an existing project like zod-mock or Faker with small suggesions and fixes. Thats how I started on this journey.

3. Fun fact: If you contribute to zod-mock, it is less likely to go stale and maybe you can even help them improve their API as you have asked. 😉

4. You may suggest features, but please dont try to sell it to us like that is the hottest stuff in the universe.
   We do this because we like the project and consider it fun and worth our time.
   Maybe try to sell us why this would be fun to do 🤔?! Or more more realistically what you expect us to do better than the existing library.

---

Sorry if this got a little bit long/hard.
I just wanted to explain our(my) thought process a bit.
We are glad you like Faker and want it to grow.
Thanks for sharing your suggestions with us.

[JessicaSachs]

Let's chill for a min. It's a Sunday on a holiday weekend, and I think it's good to remember that we're mostly unpaid humans that are tryna do our best to solve problems for the community. 🌸

Now, to be clear:
I did not mean that the Faker org and maintainers take on additional responsibility.

I meant that I, personally, think that Zod is amazing and awesome and needs something like this~! At most, I meant my comment as a call to action for the community (that includes you @louiss0 - you're the one who wants it the most) to make this happen.

Faker might be the backbone to solve the problem, or it might not be!

Either way, it'd be dope to have you build an alternative package to Zod Mock, on top of Faker's localized string collection (if you think that's the right match) that you'd like better and go from there.

Each of us on the Faker team use Faker for different use-cases, so you're feeling some resistance for package-specific integrations.

I use it for testing, Shini uses it for DB seeding, so if you want deep integration into a specific (awesome!) library, feel empowered to build on top of us and ask questions! 💪🛠️

[louiss0]

You have raised some strong points there.
I should have put more thought into this! I didn't want to pressure anyone.
I simply wanted a better and more thought-out alternative Zod Mock.

[louiss0]

I think you are looking at it with a different mindset then we do.

We as the Faker team are currently congested with our current tasks for this library alone to a point where actual contributions to this repository cannot be reviewed on time. We would like to change that, but our time is limited. If you could help with the reviews that would help a lot.

Now back to topic: You come along and share this library with us that uses faker under the hood to generate data mock data. We love hearing about usages of our library as it gives us valuable insights into real world usecases. We use these and our vision of Faker to improve the api and the developer experience.

Now to the problematic part: You suggest that we take over the project:

• because "we probably know how to do it better"
• you expect that we help Jess without offering your help
• you think that the developer might stop improving the library and fear it getting stale
• You try to sell us the potential benefits without taking the costs of that into consideration.

1. We do have lots of experience in that regard.
   And generating useful complex data is hard.
   In fact it is very hard.

Let's have a look at the following example: email: z.string().email().optional()

You might think, easy just generate an email address. But in reality you might want to have an email address based on the users name. That might be split across multiple fields e.g. firstName and lastName. The fields may not be called like that. Maybe it uses snake case. Maybe it uses surname. What about countries where you have multiple surnames based on your parents?

As you can see there are a lot of things to consider, that's why we aim to help developers create their data, but dont provide any "complex object generators" ourselves.

2. OpenSource lives because everyone is putting some effort into it. We all started as beginners and got better over time.
   If you dont want to start big consider contributing to an existing project like zod-mock or Faker with small suggesions and fixes. Thats how I started on this journey.
3. Fun fact: If you contribute to zod-mock, it is less likely to go stale and maybe you can even help them improve their API as you have asked. 😉
4. You may suggest features, but please dont try to sell it to us like that is the hottest stuff in the universe.
   We do this because we like the project and consider it fun and worth our time.
   Maybe try to sell us why this would be fun to do 🤔?! Or more more realistically what you expect us to do better than the existing library.

Sorry if this got a little bit long/hard. I just wanted to explain our(my) thought process a bit. We are glad you like Faker and want it to grow. Thanks for sharing your suggestions with us.

Let's chill for a min. It's a Sunday on a holiday weekend, and I think it's good to remember that we're mostly unpaid humans that are tryna do our best to solve problems for the community. 🌸

Now, to be clear: **I did not mean that the Faker org and maintainers take on additional responsibility**.

I meant that I, personally, think that Zod is amazing and awesome and needs something like this~! At most, I meant my comment as a call to action for the community (that includes you @louiss0 - you're the one who wants it the most) to make this happen.

Faker might be the backbone to solve the problem, or it might not be!

Either way, it'd be dope to have you build an alternative package to Zod Mock, on top of Faker's localized string collection (if you think that's the right match) that you'd like better and go from there.

Each of us on the Faker team use Faker for different use-cases, so you're feeling some resistance for package-specific integrations.

I use it for testing, Shini uses it for DB seeding, so if you want deep integration into a specific (awesome!) library, feel empowered to build on top of us and ask questions! 💪🛠️

In order for me to come up with an alternative I would have to see what's missing myself. I have experience building my own libraries this year. I have not had to do anything complicated when it comes to testing. I'll use the Zod Mock library in my own projects and let you know if I do create my own version.

If you want to do this then I can help set up the project repo and even help with TS. I'm pretty sure I know it better than you.
I'm glad you are open to this idea. I had no idea that this library had so many problems and sucked up so much time.

I regret using the Zod is trending as an argument. That pissed them that guy off. To be honest I don't think Zod is going to die anytime soon.

[matthewmayer]

Other projects that make use of Faker.js are definitely a good thing. I think we could do things that help third-party projects without directly writing code like:

• Having a page where we highlight other projects that use Faker.js data in interesting ways
• Invite collaborators of those projects to join the Faker.js Discord, involve them in testing beta versions of the project so we can spot any incompatibilities sooner
• Strictly follow semver rules so we don't accidentally break anything
• Avoid unnecessary deprecations that puts burden on downstream maintainers
• Have excellent documentation around migrations

i like the unix philosophy of Do One Thing And Do It Well - we should make the absolute best faking library we can, and make it easy for other open source projects, e.g. mocking libraries, to use Faker, while remaining "neutral" to what other tools people choose to use.