fix: validate numeric options strictly

[dumanoglu1]

Motivation

Number.parseInt and Number.parseFloat accept numeric prefixes while silently ignoring trailing input. As a result, malformed CLI option values such as 10foo, 1.9 (for integers), 0.5oops, and 0.01% were accepted. Non-finite values such as Infinity could also pass float parsing.

Solution

Validate the entire input before conversion and require the result to be finite:

• integers accept only signed decimal integer strings, rejecting decimals, exponents, hexadecimal input, and suffixes;
• floats retain valid forms such as .5, 1., and 1e-2, while rejecting suffixes and non-finite results;
• regression tests cover both the rejected inputs and the valid float forms.

Validation completed with Node 24.14.1:

• focused parse tests: 25 passed;
• full test suite: 438 passed, 2 skipped;
• type-check, lint, and build passed.

As this repository is a public read-only mirror, maintainers can recreate this change in the internal monorepo as described in CONTRIBUTING.md.

[ryanio]

Thanks for this, and for the clear write-up and tests. This repo is a read-only mirror, so we've recreated the change in our internal monorepo with you credited as co-author on the commit. It will ship in the next @opensea/cli release.

We made one small change: the integer helper checks Number.isSafeInteger instead of Number.isFinite. A string that already matches ^[+-]?\d+$ is finite unless it runs past 308 digits, and --before/--after take Unix timestamps, where silent rounding above 2^53 is the case worth catching. We also added a trailing-newline case to each rejection table.

Because inputs like 10foo used to be accepted, this goes out as a minor version bump rather than a patch.

Closing this PR since the change now lives in the monorepo. Appreciate you taking the time!