Skip to content

Expose partial locale data for smaller bundle size #3590

Open

Description

@ST-DDT

Clear and concise description of the problem

Currently anything inside a locale object such as en is never tree shaken even if you only need one submodule/language file from it. This applies also if you manually deconstruct and reassemble it.

Suggested solution

Add imports/exports for localization files.

E.g.

import { person } from '@faker-js/faker/locales/en';
import { firstName } from '@faker-js/faker/locales/en/person';

For my usecase it would be sufficient to get access on the module level e.g. person, but others may want to narrow it down more.

This might require some changes on how locale files are joined at least if the imports should be most convinient.

// module.ts
export first_name from './first_name';
// locale.ts
export * as person from './person';

Alternative

Alt1) Provide other ways to access subsets of locales.

Alt2) Combine #2667 with pre-built per locale nano instances.

Additional context

No response

Activity

  1. github-actions commented on Aug 14, 2025

    @github-actions
    Contributor

    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 ( 👍 ) 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

  2. added this to the v11.0 milestone on Jun 22, 2026
  3. modified the milestones: v11.0, vFuture on Jul 5, 2026
  4. ST-DDT commented on Jul 11, 2026

    @ST-DDT
    MemberAuthor

    This now has 17 updates, maybe we can work on this in/for v11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions