v9 migration guide polish

[xDivisionByZerox]

Description

I've done some proof reading on the "finished" migration guide for v9 and noticed some things that should propably be addressed before the final release.

• Upgrade to TypeScript v5 and Usage of TypeScript 5 Features directly contradict each other: "While generally not breaking for users, this might have small side effects on our types." vs "[...] so if you are using Faker with TypeScript, you must use TS5."
• Fix Tree Shaking should have a visual representation (build screenshots, raw data tables) of th impact of the change.

• Use High Precision RNG by Default

  • The variable names in the code example in make it harder to understand than necessary. Suggested replacements:	current names	suggested names
    f32	oldFaker
    r32	oldValue
    f53	newFaker
    r32	newValue

    Alternativly, instead of having the comparison source code in the same code block, we could place two code blocks next to each other in a table (code highlighting doesn't seem to work on GH, I don't know about vitepress).

  • The adoption list includes an example for vitest specifically. Eigther include on for the most common test libraries or don't include on at all.
  • The section in general seems pretty long compared to the other sections in the guide. Maybe we find a way to get rid of some content and place it in a "In Details"-Blog-Post (or similar).
• The section Using tsup for the Build Process feels out of place. I don't get why the end user might be interested in this. If there is a reason, the section should be rephrased to make the intend more clear.
• Removals of Deprecated Code
  • The subsections contain the table headers "old" and "replacement". I think "removed" and "replacement" would clearify that the first column is not being "the old way starting this version" but has actually been removed already.
  • The "Note" block in Company Name Affix files reorganized should be properly formatted
  • The syntax for function references in the tables is inconsistent. Sometimes parentheses are includes, somethimes they aren't (not talking about signature changes, example: Finance Module)
  • The Helpers Module section is very long and detailed. It should propably contain a "Read More" link instead of going into several implementation details.
  • The section faker.helpers.arrayElement and faker.helpers.arrayElements feels out of place as it is not a removal but a breaking change. It should be moved to a section in Breaking Changes to Specific Methods. It should also emphasise that invalid input values are not possible due to typescript.
• The naming schema in Renamed Locale Definitions should make clear that category_name and entry_name are singular. This might be something that should be included in another guide as well.
• Breaking Changes to Specific Methods
  • The last part in Birthdate New Default Mode read weirdly.

    We also improved the error messages in case of invalid min/max age/year ranges.

  • "create a new issue" in Separate Timezone Methods should have a link to the GitHub
  • Images Have Random Options by Default is very repetitive. Wewrite to a more generic description with a table pointing out the options to restore the old behaviour.
  • Phone Number style Replaces Explicit format feels duplicated to Phone Module.

[ST-DDT]

Here is my opinion on this.

1. TypeScript v5 -> yes
2. TreeShaking examples -> yes
3. High precision randomizer
   1. yes, but r => randomizer instead of value
   2. maybe, use --update-snapshot isntead of -u and maybe add e.g. or also mention jest
   3. not sure about that
4. tsup -> yes, can be removed, but this was added specifically by @Shinigami92 <- What do you think?
5. Deprecated Removals
   1. yes
   2. yes
   3. yes
   4. not sure about that
      1. not sure about that
6. Renamed singular -> yes
7. Specific Methods
   1. yes
   2. yes
   3. yes
   4. yes

EDIT: yes => should be edited

[xDivisionByZerox]

• Fix Tree Shaking should have a visual representation (build screenshots, raw data tables) of th impact of the change.

While this is interesting and should propably be done, I'm discurraged to put this in the migration guide itself. While users are interested that the feature exists, more details are not required for migrating itself.

We will propably add another blogpost which goes into more detail about the v9 features.