[youdie006]

fast-path.ts answers com, org, edu, gov, net and de directly and marks them isIcann: true, but it only checks allowPrivateDomains, not allowIcannDomains. So with { allowIcannDomains: false } and private domains left off, example.com reports isIcann: true while example.fr and example.co.uk report false. The trie lookups in tldts and tldts-experimental both skip ICANN rules when the option is off.

tldts.parse('example.com', { allowIcannDomains: false })
// before: { publicSuffix: 'com', isIcann: true, isPrivate: false, ... }
// after:  { publicSuffix: 'com', isIcann: false, isPrivate: false, ... }

The fast path now also requires allowIcannDomains, so only this option combination falls through to the regular lookup; publicSuffix, domain and subdomain don't change, and default options still take the fast path. In tldts-icann the two flags become null for these hosts, as they already are there for fr and co.uk. The new test sits next to the existing wildcard fallback test and runs for all three builds.

After yarn build, yarn test passes in every package (on master the new test fails in tldts, tldts-experimental and tldts-icann), and yarn lint and prettier are clean.

Written with AI assistance (Claude); I have reviewed the change.

[remusao]

Hi @youdie006, and thanks for your contribution. Out of curiosity, is there a use-case for disabling both private domains and ICANN domains?

[youdie006]

Not one I've seen in practice. I found this while reading fast-path.ts, not from a bug report.

With both off no rules apply, so every hostname falls back to its last label (example.co.uk gives uk). The fast path made com, org, edu, gov, net and de the only suffixes that still reported isIcann: true there. The change only affects that combination; default options still take the fast path. If you'd rather not cater to it, feel free to close.