feat(isTaxID): add en-IN (PAN) support, rebase of #2032 by @ajinkyac03

[simonkundrik]

Picks up #2032 by @ajinkyac03, which was approved and labelled mc-to-land but has been sitting on merge conflicts since March 2025. Doing this per @rubiin's instructions in #2410 (fork, keep the original author's commits, resolve the conflicts). All three commits are still authored by @ajinkyac03, I only rebased them and fixed the conflicts. All credit for the regex and tests is theirs.

Adds en-IN (Indian PAN) support to isTaxID.

What the conflict actually was

Nothing to do with the code. #2032 patched test/validators.js, which has since been renamed to test/validators.test.js, so the whole PR showed as conflicting. Once rebased, src/lib/isTaxID.js and the test file both merged cleanly. The only manual resolution was the README row, which had drifted over the years, so I took master's current row and added 'en-IN' to the locale list in alphabetical position.

Net change is unchanged from what was approved: one regex, one README locale, one test block.

The regex

'en-IN': /^[A-Z]{3}[ABCFGHLJPT][A-Z](?!0000)[0-9]{4}[A-Z]$/,

PAN is 10 characters, AAAAA9999A. The 4th character is a holder-type code, and only ten letters are valid there (A, B, C, F, G, H, J, L, P, T for Association of Persons, Body of Individuals, Company, Firm, Government, HUF, Artificial Juridical Person, Local Authority, Individual, Trust). The (?!0000) guards the serial, which runs 0001-9999.

Reference: https://incometaxindia.gov.in/Pages/tax-services/permanent-account-number.aspx

en-IN isn't in taxIdCheck, so it takes the existing "not all locales have algorithmic checks" fallthrough. That's deliberate, since PAN's check character has no published algorithm.

Verification

All 10 of the original test vectors pass, and en-US/en-IE are unaffected. Full suite 290 passing, eslint clean.

Worth flagging one vector, since it looks wrong at a glance: ABCDE1234F is in the invalid list even though it's the example string on the income tax site. It's correctly rejected, because D isn't a valid 4th-character holder code. That string is a format illustration rather than a real PAN.

Note on #2703

There's an open #2703 adding a separate isPAN validator for the same data. Not my call which approach you prefer, but for what it's worth this one is the already-approved route, and #2703's [A-Z]{5}[0-9]{4}[A-Z] accepts ABCDE1234F and other invalid holder-type codes.

Happy to rebase again if #2698 lands first and moves the tests.

Closes #2032

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)
• References provided in PR (where applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (3576b41) to head (f1571dc).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2835   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2598      2598           
  Branches       658       658           
=========================================
  Hits          2598      2598           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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.

[tux-tn]

LGTM! Thank you for taking the time to rebase and improve the existing PR

[rubiin]

also other mc-to-land are for take