Open Faker for custom/community modules

[xDivisionByZerox]

Clear and concise description of the problem

Faker has many different modules but even more requested features.
Many of these features are sadly too complex to be maintained by the Faker-JS team.

Suggested solution

The Faker class should accept a list of modules that will be used under the created Faker instance. These modules will be plugins maintained by the community.
Like:

const myModule = {
    test() {
        return 'test';
    }
}

const fakerWithCustomModule = new Faker({
    customModules: [
        { name: 'testModule', module: myModule },
    ],
});
fakerWithCustomModule.testModule.test(); // 'test'

Alternative

No response

Additional context

Somewhat related to #444

[ST-DDT]

Here is a workaround to do this right now in a typesafe way:

import type { Faker, UsableLocale } from "@faker-js/faker";
import { faker } from "@faker-js/faker";

function withCustomModule<
  S extends Faker,
  Name extends string,
  T,
  U extends S & Record<Name, T>
>(base: S, name: Name, value: T): U {
  return {
    // Class level functions
    seed: (seed: number | number[]): void => base.seed(seed),
    setLocale: (locale: UsableLocale): void => base.setLocale(locale),
    // Previous modules
    ...base,
    // Custom Modules
    [name]: value,
  } as U;
}

const customModule = {
  abc: () => "sjkdfhajkshdf",
} as const;

const fakerPlus = withCustomModule(faker, "test", customModule);

console.log(fakerPlus.test.abc());

[xDivisionByZerox]

I really like the approach typeorm is taking with their repository.

[ST-DDT]

Isn't that almost like my example above?
(Just with new/a constructor and Object.assign instead of a Record)

[xDivisionByZerox]

Yes, I just wanted to provide an example of how other communities handle the extendability approach.

[ST-DDT]

If you are interested in this feature, please upvote it.