Extending faker with external generators experiment #3191

Activity

1. stefannibrasil

   added

   ⚒️ Improvement

   on Jan 19, 2026
2. stefannibrasil

   added a parent issue on Jan 19, 2026

   • Experiment with different loading mechanisms #3161
3. stefannibrasil

   assigned

   stefannibrasil

   and

   thdaraujo

   on Jan 19, 2026
4. stefannibrasil commented on Jan 22, 2026

   

   stefannibrasil

   on Jan 22, 2026

   Last edited by stefannibrasil

   ContributorAuthor

   More actions

   I finalized experimenting with extending Faker classes so users can create their own external generators and/or add new functionalities to faker-ruby generators. I created two example repositories of external generators exemplifying that:

   • Faker::Git - a new generator that produces random git branch name. Examples include setting a different locale as well.
   • Faker::Omniauth - adds new functionality to an existing faker-ruby generator by adding a new provider.

   I tested them by building and installing the gem. Then I used the generators in an irb session:

   irb(main):001> require 'faker_omniauth'
   => true
   irb(main):002> Faker::Omniauth.microsoft
   =>
   {provider: "entra_id",
    uid: "b67d9a218badbfc029591d2554e0d34295204faa7db76d3bc37b9787f8d62e81",
    info: {name: "Jamika Fay", email: "jamika.fay@emmerich.example", nickname: "jamika.fay", ...}
   
   
   irb(main):003> require 'faker-git'
   => true
   irb(main):004> Faker::Git.branch
   => "develop"
   irb(main):005> Faker::Config.locale = 'pt-BR'
   => "pt-BR"
   irb(main):006> Faker::Git.branch
   => "principal"

   This shows that we don't need to change anything in faker to have users creating their own external generators! Fun surprise. It turns out all that is needed is to inherit from Faker::Base to get access to faker's helpers.

   Recommended next steps

   • test examples above in a real world application beyond an irb session ✅
     • think of edge cases to test
   • document best practices on how to name the gems (for ex. faker-$name), avoid overriding faker's functionalities, etc., list them in our docs so people can find them. Fore example, roda's list of external plugins.
   • ask users to use external generators (even create their own) and report any bugs
   • start extracting non-core generators to external gems. There are a few options to consider:
     • it might not be necessary after we stop requiring all generators by default.
     • we could follow faker JS SimpleFaker and have a core set of generators without locales and then another gem that has the remaining generators and locales. This would be nice because we could not load i18n as a required dependency.
5. stefannibrasil

   changed the title [-]Lazy load generators experiment[/-] [+]Extending faker with external generators experiment[/+] on Jan 22, 2026
6. stefannibrasil commented on Jan 23, 2026

   

   stefannibrasil

   on Jan 23, 2026

   Last edited by stefannibrasil

   ContributorAuthor

   More actions

   I tested the example generators shared above on CASA:

   https://github.com/rubyforgood/casa/compare/main...hexdevs:casa:sb-use-faker-external-generators-example?expand=1

   It worked great and I think we can get started documenting how people can create their own plugins. I created an external generator under faker's organization so people can use it as as example (private repo for now until we decide on naming, etc.):
   https://github.com/faker-ruby/faker-database
7. stefannibrasil commented on Jan 29, 2026

   

   stefannibrasil

   on Jan 29, 2026

   ContributorAuthor

   More actions

   Will revisit this after the loading experiments are done.
8. stefannibrasil commented on Feb 19, 2026

   

   stefannibrasil

   on Feb 19, 2026

   ContributorAuthor

   More actions

   Closing in favour of #3162

   After we push a beta release with the new loading mechanism, we will work on this.
9. stefannibrasil

   closed this as completedon Feb 19, 2026