chore: consistent type import paths

[ST-DDT]

I noticed that the helpers module imports it's types directly from the root index, while all other modules import the faker instance from the faker file directly. This (minimally) speeds up build performance for partial builds, as a smaller set of files need to be parsed for the build process to complete.

I searched for: import (type )?\{ .*(\.|/)'
in: src
excluding: src/locales

src/locales always imports the definitions from the root index.
I plan to address that once this PR is merged, as it requires changes to the generate:locales script.

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	c5ef2a2
🔍 Latest deploy log	https://app.netlify.com/projects/fakerjs/deploys/6a42cbbad42c5b00087bc936
😎 Deploy Preview	https://deploy-preview-3926.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.84%. Comparing base (acd5fda) to head (c5ef2a2).

Additional details and impacted files

@@           Coverage Diff           @@
##             next    #3926   +/-   ##
=======================================
  Coverage   98.84%   98.84%           
=======================================
  Files         923      923           
  Lines        3216     3216           
  Branches      583      583           
=======================================
  Hits         3179     3179           
  Misses         33       33           
  Partials        4        4           

Files with missing lines	Coverage Δ
src/modules/helpers/module.ts	94.84% <ø> (ø)
src/modules/string/uuid.ts	100.00% <ø> (ø)
src/utils/merge-locales.ts	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Shinigami92]

Would it be possible to use a lint rule for this?

[ST-DDT]

Would it be possible to use a lint rule for this?

Maybe, though I'm not sure what to search for.

[Shinigami92]

Would it be possible to use a lint rule for this?

Maybe, though I'm not sure what to search for.

Literally paste the url of this PR and tell your AI to make a WebFetch. It is 2026.

[Shinigami92]

@ST-DDT I gave claude this request:

Is there a lint rule to prevent further cases like #3926 ?

Claude Response

I've read the PR. The maintainer (Shinigami92) asked exactly this, and ST-DDT wasn't sure what to search for. Let me check what's already in faker's ESLint setup so I can give you something that drops in cleanly.Let me check faker's current ESLint config directly to tailor this.Yes — and import/no-restricted-paths is the rule that actually fits, because unlike the plain no-restricted-imports it resolves the import to a file before checking. That matters here: the offending imports were relative (from '.' / from '../..'), and a string-based rule can't reliably catch "this relative path happens to resolve to the root barrel." no-restricted-paths can, via its zones config (target = files that are restricted, from = what they may not import, plus except).

Tailored to what the PR describes — everything under src should import from the concrete source file, never from the root barrel src/index.ts, with the src/locales carve-out ST-DDT mentioned:

// eslint.config.ts (flat config)
{
  files: ['src/**/*.ts'],
  rules: {
    'import/no-restricted-paths': ['error', {
      zones: [
        {
          target: './src',
          from: './src/index.ts',
          // locales still import definitions from the root index until
          // the generate:locales script is reworked (the follow-up PR)
          except: ['./src/locales'],
          message:
            'Import from the specific source file (e.g. ./faker or the concrete definitions/types file), not the root barrel.',
        },
      ],
    }],
  },
}

The index file re-exporting from its own modules is fine — it's the source of the barrel, not an importer of it. And no-restricted-paths deliberately doesn't autofix, so it'll flag rather than rewrite.

A few caveats worth flagging to the maintainers:

eslint-plugin-import's flat-config support has historically been finicky, and faker is ESM-only on flat config now. If it isn't already a dependency, eslint-plugin-import-x is the actively maintained, flat-config-native fork with the same no-restricted-paths rule and identical config shape — usually the smoother choice for a setup like theirs.

If the real intent is broader than "the root barrel" — i.e. ST-DDT's search regex import (type )?\{ .*(\.|/)' was catching any import that resolves to a directory/index rather than an explicit file — then no-restricted-paths only covers the specific barrel you name. For the general "no barrel/directory imports anywhere" rule, either eslint-plugin-barrel-files (rule avoid-importing-barrel-files, purpose-built for this) or import/extensions: ['error', 'always'] (which forces explicit file paths and so inherently rejects from '.') generalizes it, at the cost of more noise.

One thing the plain core no-restricted-imports / @typescript-eslint/no-restricted-imports can do that this can't is allowTypeImports — but that's the opposite of what this PR wants, since here the goal is to forbid the type imports from the barrel too, so it's the wrong tool for this particular case.

If you want, I can sketch the matching except/zone setup for the locales follow-up, or draft a short reply you could drop straight into the PR thread.

So maybe we could investigate further with https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md