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

Could you please explain what exactly bothers you with the emojis (just so we understand what exactly we have to implement/change)?
Do you want just plain text? What about emoji text ¯\_(ツ)_/¯?

Please remember to upvote your own feature request😉

Currently using faker to generate medium to long phrases of text (fake LLM promps) and the emojis stand out, visually.

Do you want just plain text? What about emoji text ¯_(ツ)_/¯?

My preference is plain text, but I think others may like the option for emoji text / ASCII.

In which case the former suggestion might be better off:

faker.person.bio({ emoji: '...' })

type BioOptions = {
  emoji?: 'unicode' | 'text' | 'ascii' | 'none' | false // etc
}

Maybe a helper function which strips emojis, or non ascii text would be more genetically useful than adding a parameter to this method specifically?

Maybe a helper function which strips emojis, or non ascii text would be more genetically useful than adding a parameter to this method specifically?

May you explain how a second, separate method can be more generic than making the signature allow options that customize the output? Allowing custom output by parameters is literally the most generic option there is. Might nit be the best in terms of DX, but I don't see where you come from with your argument and want to understand it.

Because other methods might emit emoji or non ascii characters, not just this one.

I'm not sure about removing certain things from our strings or providing a separate method for that.
Because if we add that, why don't we have a method to remove all as from the value?

I think having a parameter is different because we could control which parts we would like to add to the output, but I'm not even sure I would like to do that. (Only if there is community interest for it)

As a workaround you could strip the emojis from the patterns:

faker.rawDefintions.person.bio_pattern = faker.rawDefintions.person.bio_pattern.map((v) => v.replaceAll("{{internet.emoji}}", "");

As another workaround you can easily strip emojis from a string using Unicode property escapes:

faker.person.bio().replace(/\p{Emoji}/gu, '');