chore: deprecate faker.seedValue

[ST-DDT]

The faker.seedValue has no impact on the generated values at all, thus it being there is more confusing than doing any good.

[codecov]

Codecov Report

Merging #851 (d46ccf3) into main (3a5a2f2) will decrease coverage by 0.00%.
The diff coverage is 68.75%.

@@            Coverage Diff             @@
##             main     #851      +/-   ##
==========================================
- Coverage   99.35%   99.35%   -0.01%     
==========================================
  Files        1922     1922              
  Lines      183052   183082      +30     
  Branches      900      901       +1     
==========================================
+ Hits       181878   181901      +23     
- Misses       1118     1125       +7     
  Partials       56       56              

Impacted Files	Coverage Δ
src/faker.ts	94.97% <68.75%> (-5.03%)	⬇️
src/finance.ts	100.00% <0.00%> (+0.70%)	⬆️

[Shinigami92]

It is a ⚠️ must have ⚠️ to get the initial seed value from the faker instance.
Relying on the user to store the seed in it's own constant and reusing that somewhere is IMO bad UX as the user just want to e.g. log out the seed for debuggings.

It's also not necessary to know the runtime seed, but only the initial provided seed passed by the user, as this it the value that the user can only control from "outside".

[pkuczynski]

I agree with @Shinigami92. I was actually planning to use it soon in one of my projects to be able to debug randomly failing test, by always writing the value before the tests starts and exposing a way for the developer to start the tests with the same value on his local as failing tests in CI.

[ST-DDT]

It is a ⚠️ must have ⚠️ to get the initial seed value from the faker instance.

Before saying it is a must, I would rather refer to outlining use-cases.
You have done so in the following sentence:

the user just want to e.g. log out the seed for debuggings.

The problem with that is, since we are generating (pseudo) random, there are unknown many steps in between (potentially in both in our code and theirs). So they should rather log the seed at their entry point. Every later seed logging doesn't yield any value, as it cannot be used in that place anyway.

It's also not necessary to know the runtime seed, but only the initial provided seed passed by the user, as this it the value that the user can only control from "outside".

The only way to control the seed from the outside is where they set it, so they should log it there, if it is relevant at all.
Why would they want to/should we allow them to access it from somewhere, where they don't have control?

faker.seed(1);
// console.log("S" + 1);
for (let i = 0; i < 10; i++) {
  console.log(
    "I" + i + " S" + faker.seedValue + " = " + faker.datatype.number()
  );
}

I0 S1 = 41702
I1 S1 = 99718
I2 S1 = 72032
I3 S1 = 93255
I4 S1 = 11
I5 S1 = 12812
I6 S1 = 30233
I7 S1 = 99904
I8 S1 = 14675
I9 S1 = 23608

If there was an error with I8, then there is no value in knowing the s=1, unless you also know i=8.
Every attempt to set the seed the value inside the loop would result in entirely different values.
If you log the seed value, then doing so above the loop is sufficient.

None of our tests use the seedValue anywhere other than where we define the tests and know our seed.

AFAICT: Neither JS Math.random(), C# Random (Net6), Java Random allow accessing the original seed afterwards, so why should we?

---

TLDR:

I'm not against having the getter, but you have to give me an explicit example, where there is non-trivial value in using faker.seedValue over a const/logging it once at the beginning.
Then we can add it to our repository to ensure we don't break that use case.

[ST-DDT]

@Shinigami92 have agreed to not agree on whether the initialSeed should be accessible.
I don't think it shouldn't be because of the unknown n iterations on the seed value between setting it and using it.
I will abstain from further comments on this PR. And will let the remaining team decide.

The other PR: #853

[pkuczynski]

My use case is as follows. I do not currently set any seed in my tests. So they all random. Sometimes they do fail in CI due this randomness and its hard to reproduce this locally as you have to run same tests multiple times without any guarantee to get to the faulty state. Faker is only initialised once in my case. So I wanted to print the seed in the beginning of the tests, so anybody looking at the CI logs could reproduce it locally. I didnt want to set the seed myself though in CI...

Does this make sense?

[Shinigami92]

@pkuczynski Yes, that is exactly what I solved with #853

So you now can do:

import { faker } from '@faker-js/faker'

console.log(faker.initialSeed)
// faker.seed(... the initial seed value you got from a previous script run ...)


// ... do stuff
const a = faker.datatype.number()
console.log(a) // `a` will be the same for the logged seed

---

Previously it was not possible to access the initialSeed when not setting it on your own

[ST-DDT]

So I wanted to print the seed in the beginning of the tests, so anybody looking at the CI logs could reproduce it locally. I didnt want to set the seed myself though in CI...

So all you need is console.log('Seed: ', faker.randomizeSeed()), where randomizeSeed returns the newly set seed?

See also: https://github.com/faker-js/faker/pull/853/files#r855586225

[ST-DDT]

@pkuczynski Yes, that is exactly what I solved with #853

@Shinigami92 Just that you store and expose the value inside faker, to be accessed later when it's no longer safe/reproducible to set it.

[Shinigami92]

Superseded by #853