Pre-Checks

• Follow our Code of Conduct.
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Faker issue and not related to a combination with another package.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.
• I am willing to provide a PR.

Describe the bug

faker.helpers.fromRegExp() can return a string that does not match its own input pattern when the pattern contains unsupported tokens like non-capturing groups (?:...) or alternation | — and it does so without throwing or warning.

I'm not asking for full regex support. I understand the docs say grouping, anchors, and character classes are unsupported. The issue is the silent failure: the function returns a value that violates the input-pattern contract, with no signal to the caller.

• What I do: call fromRegExp with a pattern containing (?:...) or |.
• What I expect: a string matching the pattern — or, if that's impossible, a clear signal (throw/warn).
• What actually happens: a string with raw regex source left in is returned silently, and regex.test(output) === false.

Would you consider adding an explicit signal for unsupported constructs — e.g. a dev-time warning, or an opt-in strict mode that throws? I'd be happy to send a PR in whatever direction fits the project best.

Minimal reproduction code

const { faker } = require('@faker-js/faker'); // 10.4.0

const re = /^(?:cat|dog)$/;            // anchored, so test() reflects a full match
const out = faker.helpers.fromRegExp(re);

console.log(out);          // "^(?:cat|dog)$"
console.log(re.test(out)); // false   ← output doesn't match its own input

Also reproduces with OpenAPI-style numeric-string patterns like /^-?(?:0|[1-9]\d*)(?:\.\d+)?$/, which coerces to NaN downstream (how it surfaced for me, via codegen for mock data).

Additional Context

In the source, unsupported tokens are simply left in place and returned (return pattern) — there's no detection or signal path for input the engine can't handle (helpers/index.ts @ 5fb3b2d).

When the leftover lands in a string field it can still look like a plausible value (e.g. [A-Z]{4}-(?:foo|bar) → "IFFD-(?:foo|bar)") and pass ordinary validation, so the failure isn't always caught downstream.

Minor docs note while I was here: the description says "character classes are not supported", but the examples include bracket-range patterns like [0-9a-dmno]. If that wording is broader than intended, I'd be glad to help clarify it too.

Environment Info

System:
  OS: macOS 15.7.4
  CPU: (14) arm64 Apple M3 Max
  Shell: 5.9 - /bin/zsh
Binaries:
  Node: 24.15.0
  npm: 11.12.1
  pnpm: 10.0.0
npmPackages:
  @faker-js/faker: ^10.4.0 => 10.4.0

Which module system do you use?

• CJS
• ESM

Used Package Manager

pnpm