The bloat of edge-case first libraries By James Garbutt | September 09, 2025 Many libraries in the JavaScript ecosystem are "edge-case-first," over-engineered to handle inputs and conditions rarely encountered, resulting in overly granular and bloated dependency trees. --- The Problem Libraries often over-handle inputs and edge cases unavailable or unlikely. Example: a simple clamp function designed to constrain a number between a min and max value can be overbuilt: Over-engineering might add validations for nonsensical ranges or convert string inputs to numbers, or even rely on an external is-number library for type checking. This leads to bloated dependencies such as the widely used is-number package. Key insight: Functions should accept and expect the data types they are designed for without trying to handle every possible edge case. Often, runtime type checking combined with value validation is redundant, especially with TypeScript. --- How It Should Be Keep implementations simple and assume correct input types. Possibly validate value correctness (e.g., min <= max), but avoid excessive input type guards. Example simplified clamp: Separate concerns: perform data validation at the application's boundary, not in every library consuming the data. --- What We Shouldn't Do Avoid building libraries that cater to unlikely edge cases by handling broad input types or odd scenarios when the common use case is simpler. Examples of over-engineered libraries: is-arrayish (76M downloads/week): Tests if a value is an array or "array-like" but often Array.isArray() suffices. is-number (90M downloads/week): Checks for positive, finite number or number-like strings, often more than needed when a simple typeof n === 'number' is enough. pascalcase (9.7M downloads/week): Converts text to PascalCase but supports many input types (strings, null, undefined, arrays, functions, arbitrary objects) while almost everyone passes strings. is-regexp (10M downloads/week): Checks if a value is a RegExp object including cross-realm cases (e.g., regexes from iframes). Useful but largely an edge case. --- What We Should Do Build libraries optimized for common use-cases with assumptions on input types. Examples of well-designed libraries: scule (1.8M downloads/week): Casing transformations only accept strings or arrays of strings, no dependencies, and assume valid inputs. dlv (14.9M downloads/week): Provides deep property access assuming path inputs as string or string arrays without validating input types. --- Validation Is Important Validation should happen where data originates (at data boundaries), not deep within dependency chains. Excessive validation in libraries pushes the burden downwards and is often invisible to library consumers. For example, is-number rejects negative numbers and Infinity, which may cause unexpected failures. Libraries should be strict about expected input types but allow applications to perform deeper validation. --- Notes on Overly-Granular Libraries Some libraries are extremely small and atomic but widely downloaded, e.g.: shebang-regex (2 LOC), only tests for #! prefix, 86M downloads/week. is-whitespace (7 LOC), checks if string is whitespace, 1M downloads/week. is-npm (8 LOC), checks for npm environment variables, 7M downloads/week. Such atomic libraries increase dependency count and package size unnecessarily. --- What Can Be Done About This? The e18e community works on improving performance by replacing bloated dependencies with smaller, modern