This function is supposed to take an array of numeric strings from a config file and convert them to integers. It works perfectly in the developer's manual tests. Ship it, and watch the metrics dashboard fill with mystery values.

// Parse a list of numeric strings into integers.
// Used to load rate limits from a config file.
function parseLimits(raw) {
    return raw.map(parseInt);
}

const config = ["1", "2", "3", "10", "11", "15", "20"];
const limits = parseLimits(config);

console.log(limits);
// Developer expects: [1, 2, 3, 10, 11, 15, 20]
// Actually prints:   [1, NaN, NaN, 3, 4, 1, NaN]

// Downstream: rate limiter now allows exactly 1 req/sec on
// endpoint #0, blocks endpoint #1 entirely (NaN comparisons
// are always false), and lets endpoint #5 through at 1/sec.

The Bug

Array.prototype.map invokes its callback with three arguments: (element, index, array). And parseInt accepts two arguments: (string, radix). So map(parseInt) silently becomes parseInt(element, index) — the array index is interpreted as the numeric base.

Walking through the example:

• parseInt("1", 0) → 1. Radix 0 is treated as "guess" (defaults to 10 for plain digits).
• parseInt("2", 1) → NaN. Base 1 isn't a valid radix.
• parseInt("3", 2) → NaN. Digit "3" isn't valid in binary.
• parseInt("10", 3) → 3. Base 3: 1×3 + 0 = 3.
• parseInt("11", 4) → 5. Base 4: 1×4 + 1 = 5.
• parseInt("15", 5) → 1. Base 5 parses "1", stops at "5" (invalid digit), returns 1.
• parseInt("20", 6) → NaN? No — 2×6 + 0 = 12. Wait, let me recount: index 6, "20" in base 6 → 12.

The failure is insidious because some values parse to plausible-looking numbers. If your test suite happens to use ["10", "20", "30"], they'll parse as [10, NaN, NaN] — you'll catch the NaN. But ["100", "50", "25"]? Those become [100, NaN, NaN] too. Try ["1", "10", "100"]: [1, NaN, 4]. The corruption pattern shifts with array content, so a "working" dev test tells you nothing.

parseInt's partial-parse behavior compounds the damage: it consumes as many valid digits as it can and returns silently, so "15" in base 5 becomes 1 with no error. Combined with JavaScript's rule that any comparison involving NaN is false (including NaN === NaN), the corrupted config flows downstream and quietly breaks conditionals you'd never think to audit.

The Fix

Never pass a variadic callback to map. Wrap it, or use Number(), which accepts exactly one argument:

// Option 1: explicit arrow, discard extra args
return raw.map(s => parseInt(s, 10));

// Option 2: Number() ignores extras and rejects partial parses
// ("15abc" → NaN, unlike parseInt("15abc", 10) → 15)
return raw.map(Number);

// Option 3: unary plus, same semantics as Number()
return raw.map(s => +s);

The same trap ambushes forEach, filter, and reduce whenever you pass a bare function reference that quietly accepts more arguments than you realized. A lint rule for unicorn/no-callback-reference (or ESLint's array-callback-return family) will catch it before code review does.