Allow Faker to Take Initial Seed on Construction

[xDivisionByZerox]

Clear and concise description of the problem

As a developer I want to be able to directly provide a seed when creating a new faker instance. Currently I have to write a separate line mutation the faker instance to configure it the way I want. I feel like it would be good DX to directly create a desired faker instance without having to call additional configuration methods.

Suggested solution

Add initialSeed property to the faker constructor, which will set the seed of the internal randomizer instance on creation.

const faker = new Faker({ locale: [base] });
faker.seed(123);

// alternative
const faker = new Faker({ locale: [base], initialSeed: 123 });

Alternative

Make Faker#seed chainable and return a reference to the current instance. That way I can at leas write it in a shorter way.

// now
const faker = new Faker({ locale: [base] });
faker.seed(123);

// alternative
const faker = new Faker({ locale: [base] }).seed(123);

Additional context

Same could be argued for setDefaultRefDate which could be present as a parameter in Fakers constructor.

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest

[ST-DDT]

This looks sufficiently requested by our users and looks like it is relatively easy to add.

I'll go ahead and provide a PR to implement this.