Proposal: Design for standalone module functions about faker HOT 14 OPEN

const { fakerCoreEN, email } = require("@faker-js/faker")
const email = email(fakerCoreEN)
// This is a few KB smaller after bundling than the old code (~620KB? vs ~600KB?)

Regarding the new syntax for this what happens to the module names? (Ie "internet" for email?)

from faker.

Provided it doesn't need to change that's fine. Anything which would require consumers to change the syntax of every call to faker they are currently making in existing code would be a big con.

But if this is only for new code, or if you want to take advantage of tree shaking, that's OK.

from faker.

• POC: Will add it when I (or someone) have some free time.
• Deprecation: -> See tracking issue

from faker.

I dont have a final idea for this, but I thought about omitting it in the export names unless required for disambiguation.

• Internet.email as email
• Animal.type as animalType
• String.sample as string or stringSample

Assigning the aliases/export names might be a manual task.

from faker.

Sorry I don't totally understand if this is a internal change or would affect consumers.

If I had existing code like

const { faker } = require("@faker-js/faker")
const email = faker.internet.email()

Would that need to change?

from faker.

Would that need to change?

Old code does not need to change

Could/as proposed:

const { fakerCoreEN, email } = require("@faker-js/faker")
const email = email(fakerCoreEN)
// This is a few KB smaller after bundling than the old code (~620KB? vs ~600KB?)

At full "capacity" (probably not part of the first implementation):

const { email } = require("@faker-js/faker/locale/en")
const email = email()
// This could be tiny (~5KB?)

from faker.

i think its also important to make sure that tree-shaking actually works after making this change!

This is going to require a LOT of changes to the code; we don't want to spend a long time doing that but then find out that there is some unrelated reason that causes tree-shaking to not be possible with this architecture. Maybe we could start with a proof of concept that this actually allows for tree-shaking to work before committing to changing this, maybe just for a single module or method?

from faker.

At first: thanks very much for taking the effort and proposing this draft via a GitHub issue 🙏

I already know a little bit more behind the scenes via private conversations and faker meetings, but I also want to write this down here to be more clear and referenceable in the future:
I'm 1_000% with @matthewmayer and want to be able to stick to the current usage of faker and so this proposal / implementation is just an addition / opt-in if wanted to benefit from. Also that means that there will no breaking changes introduced by this implementation and all current tests (except of the deprecation removals for sure) will still work afterwards.
However, I might be fine if we need something as a workaround then to support tree-shaking like import { email } from '@faker-js/faker/tree-shaked'.

Furthermore, like @matthewmayer I would really love to see a working implementation that results in <<< 600 KiB like you proposed here, before actually rewriting the whole src code base.

At full "capacity" (probably not part of the first implementation):

const { email } = require("@faker-js/faker/locale/en")
const email = email()
// This could be tiny (~5KB?)

And one last wish: I would prefer if we could do all the deprecation removals first, so we have more clean test files and also less to convert.

Tracking PR is mostly here (it got slightly more a tracking issue right now 😅)

• #2608

from faker.

Team Decision

• We will create a POC (after #2628 is merged), to verify that it actually helps with tree shaking.

from faker.

Blocked by #2628

• #2628

from faker.

It would be absolutely cool if it is somehow possible to call these functions without passing a specific faker instance, and it falls back to a default faker instance.
But not sure yet if that's possible.

I would be in favor for sampleString() because this reads a bit more naturally 🤔
But I have just put 2 seconds of brain power into that 😅

from faker.

It would be absolutely cool if it is somehow possible to call these functions without passing a specific faker instance, and it falls back to a default faker instance.
But not sure yet if that's possible.

I thought about exposing all methods bound to a specific locale (as minimal dataset) e.g. from the locale/en folder.

Note: I cut quite a few related/derived proposals from this issue entirely, because it is long enough as is:

• Nano-Localized-Functions for min bundle sizes

I consider that off-topic for the discussion, as the topic is already big enough as is.

from faker.

It would be absolutely cool if it is somehow possible to call these functions without passing a specific faker instance, and it falls back to a default faker instance.

But not sure yet if that's possible.

I thought about exposing all methods bound to a specific locale (as minimal dataset) e.g. from the locale/en folder.

Oh, I absolutely forgot 🤦, many of the functions do not need a localized faker instance at all and will just work more or less out of the box. So my request/idea was more related to just these non-locale functions. The localized functions can / should depend on a requested faker instance anyway.

Anyway, if something is confusing, I can also just shut up and do vacation if you want 😂

from faker.

many of the functions do not need a localized faker instance

But they still need the randomizer from it. We can discuss where to put them, after we have the capability to actually do so.

from faker.