[jonathan-kosgei]

Summary

Follow-up to #55 that fixes the issues noticed during that review: the cache key ignored the requested fields, LookupResponse lagged the API, two cache tests checked the wrong instance, the README badge named a workflow that does not exist, bulkLookup() validated fields inside an empty if, npm run lint rewrote files in CI, requests carried no library User-Agent, and the development dependencies had open audit advisories. No version change; every public API change is additive, and every behavioural change comes with tests (58 become 74).

Changes

• Cache keys include the selection. lookup(ip, selectField) and lookup(ip, undefined, fields) results were cached under the bare IP address and served to a later full lookup of the same address, and the other way round; bulkLookup(ips, fields) did the same. Full lookups keep the address as their key (ipdata.cache.get('1.1.1.1') still works), a single field is keyed address/field and a field list address?fields=a,b with the fields sorted, so the same selection in another order shares one entry. Bulk entries whose response has no ip (a fields list that leaves it out) are returned but no longer cached. Parameters are validated before the cache is consulted, so an invalid field now throws even when the address is cached. The README's Caching section describes the keying.
• LookupResponse follows the API. New threat.is_vpn?: boolean, threat.scores?: { vpn_score, proxy_score, threat_score, trust_score } and region_type?: string | null; city, region, region_code, postal and every time_zone value are typed nullable, as the API sends them for addresses without a known location; count is typed string, which is what the API has always returned. Documented under Response Fields in the README.
• Cache tests with a custom ttl test their own instance. The two "should not cache the information" tests read the shared instance's cache, which was empty regardless; they now check the instance they used, wait for the entry to expire and verify that the next lookup is sent to the API again.
• README badge. Points at .github/workflows/default.yml (the Lint and Test workflow) instead of a workflow named CI, so it renders again.
• bulkLookup() fields validation. The empty if around the validation call is replaced by a plain call; the validators are now validateSelectField / validateFields and return nothing instead of true.
• Check-only lint. npm run lint is eslint "src/**" without --fix, so the lint job in both workflows no longer rewrites files; npm run lint:fix applies the automatic fixes locally. The workflow files are unchanged.
• User-Agent header. Every request sends User-Agent: ipdata-node/<version>, with the version read from package.json at runtime; the file ships with every install, so this needs no build step and no new dependency. Tests match the header on the GET of lookup() and the POST of bulkLookup().
• Development dependency advisories. npm audit fix (without --force; package.json unchanged) updates the transitive tooling dependencies that have fixed releases: @babel/core and helpers, baseline-browser-mapping, brace-expansion, browserslist, flatted, handlebars, js-yaml, minimatch 3.1.5 / 9.0.9, picomatch, ts-jest. Every high and critical advisory is cleared; the two that remain are listed below.
• README: HTTP/2 through a proxy dispatcher. undici's ProxyAgent and EnvHttpProxyAgent take the ALPN protocols of the TLS connection tunnelled through the proxy from requestTls, so negotiating HTTP/2 with the API needs requestTls: { allowH2: true } next to allowH2: true; the dispatcher section says so and the proxy example shows it.

Not changed

• Two audit advisories remain because neither has a fix compatible with jest 29 and eslint 8: deepmerge >=4.2.0 (through jest-config; the only fix is a downgrade to jest 25) and minimatch <11.0.1 (fixed only in minimatch 11, which eslint 8 and jest 29 do not use). npm lists every package that depends on them, so npm audit now shows 38 low/moderate entries where it showed 16 before, with 0 high and 0 critical.
• region_type is not added to the selectField / fields allow-list: the type change reflects the field in full responses, and the sample responses do not show whether the API accepts it as a filter.
• undici marks a kept-alive HTTP/1.1 connection reusable only on the event-loop turn after its response completed, so two lookups awaited strictly back-to-back may alternate between two pooled connections; this is undici behaviour, irrelevant over HTTP/2, and the existing loopback test documents it.
• tsconfig.base.json still targets ES2015 with lib: ["es2015"]; changing the compile target is unrelated to these fixes and deserves its own change.
• The pre-existing import/no-named-as-default lint warning on the test file's import line is untouched.

Verification

Node v22.23.4, npm 10.9.9, run on the final tree before pushing:

Command	Result
rm -rf node_modules && npm ci	exit 0
npm run build	exit 0
npm run lint	0 errors, 1 warning (pre-existing import/no-named-as-default)
npm test	Tests: 74 passed, 74 total (58 before)
npm audit	0 critical, 0 high; only the two roots listed above remain (before: 1 critical, 6 high, 1 moderate, 8 low)
npm pack --dry-run	6 files: lib/*, LICENSE, README.md, package.json, so the runtime require('../package.json') resolves in the published layout

CI: Lint and Test (default.yml) for head e9d7766, both runs green at the first attempt with the jobs lint, test (20), test (22) and test (24): push run #34 https://github.com/ipdata/node/actions/runs/41640659264 and pull_request run #35 https://github.com/ipdata/node/actions/runs/41640843022. No follow-up commits were needed.

🤖 Generated with Claude Code