chore: rename Gender to Sex

[hankucz]

Fixes #352

Questions:

• I don't know how to deprecate Gender type in favor of Sex
• I haven't added Intersex nor Nonbinary to the enum, as I felt that the way it is used, it would be better not to specify the sex, which would lead to randomizing the value despite the sex. For example 'faker.name.firstName()` would provide either a female or male first name, which IMHO would provide inclusivity for non-binary data...
• I could also create a separate category of names, which are not sex-specific, like Alex, Max, Sam, etc and then I could add a new enum value for picking them up. Although some (or maybe even many) languages do not have such names (eg. in Polish, every female name must end with an a, and if a name does not, it is considered male - there are no exceptions to this rule).
• Some other fixes in this module will follow in a separate PR, for example Use enum for male/female references #352

[codecov]

Codecov Report

Merging #1163 (f746d11) into main (4fa243e) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head f746d11 differs from pull request most recent head b603613. Consider uploading reports for the commit b603613 to get more accurate results

@@            Coverage Diff             @@
##             main    #1163      +/-   ##
==========================================
- Coverage   99.62%   99.62%   -0.01%     
==========================================
  Files        2153     2153              
  Lines      236521   236547      +26     
  Branches      979      980       +1     
==========================================
+ Hits       235643   235659      +16     
- Misses        857      867      +10     
  Partials       21       21              

Impacted Files	Coverage Δ
src/index.ts	100.00% <100.00%> (ø)
src/modules/name/index.ts	100.00% <100.00%> (ø)
src/modules/internet/user-agent.ts	81.74% <0.00%> (-2.65%)	⬇️

[xDivisionByZerox]

I don't know how to deprecate Gender type in favor of Sex

As far as I can tell there is no way to do that other than documentation since the type will be gone as soon as the TypeScript code is compiled to JavaScript.

I haven't added Intersex nor Nonbinary to the enum, as I felt that the way it is used, it would be better not to specify the sex, which would lead to randomizing the value despite the sex. For example 'faker.name.firstName()` would provide either a female or male first name, which IMHO would provide inclusivity for non-binary data...

I could also create a separate category of names, which are not sex-specific, like Alex, Max, Sam, etc and then I could add a new enum value for picking them up. Although some (or maybe even many) languages do not have such names (eg. in Polish, every female name must end with an a, and if a name does not, it is considered male - there are no exceptions to this rule).

We have already talked about this possibility in a team meeting. But, you also came to the conclusion that it's not as easy as just providing an extra set of names to pick from (your Polish example). Because of that, we decided to keep the options as they are, for now. When the library is considered stable and easier maintainable we will think about such features.

[xDivisionByZerox]

The current change would be considered a breaking change since the Gender enum would be removed. But like I said in an earlier comment, I'm not sure if you can deprecate and enum. I'm just pinging @Shinigami92 and @ST-DDT so they will see this (but they are currently on vacation).

One other think is that I'd like to get the additional type (now SexValue) removed. But this doesn't belong in this PR. Just leaving this here for reference.

Otherwise this looks good to me.

[hankucz]

The current change would be considered a breaking change since the Gender enum would be removed. But like I said in an earlier comment, I'm not sure if you can deprecate and enum.

I am not sure if anybody would use the enum, as initially, I changed types to use it, and all tests were failing compilation when called with strings like firstName('female'), which is how they all were documented. I was thinking whether it makes sense to export the enum at all, and maybe only use the string type? Eventually, I decided to go with both but export only enum. What do you think?

One other think is that I'd like to get the additional type (now SexValue) removed. But this doesn't belong in this PR. Just leaving this here for reference.

I can't do it, if we want to support param values as strings, eg firstName('female') - or I don't know how to do it...

[hankucz]

@xDivisionByZerox @ST-DDT @Shinigami92 is this ready for merge? I left some unresolved comments from @Shinigami92 - can you help me with this, as I am not sure if I should tackle them or not as it seems there are some contradictory opinions...

[hankucz]

Suggestions from @xDivisionByZerox are done. Is this ready for merge?