Across 235 functions analyzed in lovell/sharp at commit e000d0b, 31 reach the critical band and every single high-complexity function sits in the fire quadrant — actively changing, not dormant. I would start with _createInputDescriptor in lib/input.mjs, which has a cyclomatic complexity of 183 against a next-highest of 35: a gap of 148 points that signals a categorically different level of structural risk, not just a ranking difference. With 3 commits touching it in the last 30 days and an activity-weighted risk score of 20.24, this is a live regression surface, not a backlog item.
The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).
Top 5 Hotspots
| Function | File | Risk | CC | ND | FO |
|---|---|---|---|---|---|
_createInputDescriptor | lib/input.mjs | 20.2 | 183 | 9 | 18 |
tile | lib/output.mjs | 15.4 | 35 | 4 | 8 |
affine | lib/operation.mjs | 15.1 | 22 | 4 | 10 |
heif | lib/output.mjs | 14.9 | 25 | 4 | 8 |
resize | lib/resize.mjs | 14.7 | 35 | 3 | 8 |
Large Repo Analysis
sharp is a large repository. To stay within memory constraints, this analysis used hybrid touch mode: structural complexity — CC, ND, FO — is measured precisely for every function. Git activity is tracked at the function level (via git log -L) only for files with 5 or more commits in the last 30 days; other files use a file-level approximation. Rankings therefore surface functions that are both structurally complex and in the most actively-changing parts of the codebase. Dormant code with high structural complexity will rank lower than it would under a full per-function analysis — to surface it, run hotspots analyze . --per-function-touches on a machine with sufficient memory.
Quadrant and pattern overview
235 functions analyzed
Every function in the critical and high bands sits in the fire quadrant — high complexity combined with recent commit activity. There are no dormant debt functions in this repo at all, which means structural complexity and active development are coexisting across the board. The pattern distribution across the top five reinforces this: the dominant antipatterns are exit-heavy validation chains and complex branching, with one function earning the god_function label outright.
Multiple return or throw paths dispersed through the body — each exit needs separate test coverage.Complex Branching×4Complex Branching
High cyclomatic complexity — many independent execution paths, each a potential bug surface and required test case.Long Function×3Long Function
Function body is too long to review in a single pass; likely contains multiple distinct responsibilities.Deeply Nested×1Deeply Nested
Control structures nested 4+ levels deep, making it hard to reason about the full execution state at inner branches.God Function×1God Function
Calls an unusually large number of distinct functions (high fan-out), making it the structural centre of gravity for a subsystem.
_createInputDescriptor — input.mjs
A cyclomatic complexity of 183 is not just a high number — it represents 183 independent execution paths through a single function, each of which is a required test case and a potential bug surface. The fifth-ranked function in this list has a CC of 35, which itself warrants attention. The gap of 148 points means _createInputDescriptor is a different category of problem entirely.
From the source excerpt, the function accepts three argument forms — filesystem path, Buffer, ArrayBuffer, TypedArray, plain object, undefined stream input, and Array — and then applies a second large validation pass over a rich inputOptions object covering parameters like failOn, autoOrient, density, and more. The nesting depth of 9 reflects this two-phase structure: outer branches discriminate input type, inner branches validate each option field, and the deepest paths combine both. Fan-out of 18 means the function reaches into nearly a fifth of the callable surface the module exposes, and in JavaScript’s dynamic dispatch model, some of those calls — particularly through is.* helpers and recursive this._createInputDescriptor() calls for array joins — may not be fully captured by static analysis.
The god_function and long_function pattern tags confirm what the metrics imply: this function is doing the work of several. It normalizes every supported input format, applies all input-level options, handles the recursive join case, and throws typed errors for every invalid branch. The exit_heavy tag is equally telling — with this many exit paths, test coverage that actually exercises all branches is extremely difficult to achieve or verify.
Three commits have touched this file in the last 30 days and it was last modified today. That makes this a live regression risk, not technical debt to schedule for later.
Recommendation: Extract the input-type discrimination block into a dedicated _resolveInputSource function and the options validation block into _applyInputOptions. That single decomposition would cut the CC by roughly half and bring nesting depth down from 9 to a more tractable level. The recursive join path — this.options.join = input.map(i => this._createInputDescriptor(i)) — is a strong candidate for its own named function as well.
tile — output.mjs
The tile function configures deep-zoom tiling output — tile size, overlap, container format (fs or zip), layout (dz, google, iiif, iiif3, zoomify), rotation angle, depth, blank-tile skipping, centering, and IIIF ID. The source excerpt shows each parameter handled by a sequential if (is.defined(...)) guard followed by a type-and-range check, with an immediate throw on failure. That pattern, repeated ten-plus times, is exactly what drives CC to 35 and earns the complex_branching and exit_heavy tags.
Nesting depth of 4 is not alarming on its own, but it combines with the branching count to produce a function that is hard to reason about holistically — the skipBlanks parameter, for instance, has a secondary default path specifically for google layout that is easy to miss in the surrounding noise. Two commits touched lib/output.mjs in the last 30 days; tile was last changed 5 days ago.
Recommendation: Introduce a parameter-object validation helper — something like _validateTileOptions(options) — that centralizes the guard-and-throw logic. Each validated field then becomes a single line in tile itself. This reduces CC, makes the function scannable, and makes the google-layout special case for skipBlanks explicit rather than buried.
affine — operation.mjs
The affine function applies an affine transformation matrix to an image and accepts a companion options object for translation offsets (idx, idy, odx, ody) and an interpolator. The source excerpt shows the matrix validated first — accepting either a flat 1×4 array or a 2×2 nested array, flattened and re-checked — before the options block opens a second nested validation layer for each offset parameter.
At CC 22 and fan-out 10, affine is not in the same structural tier as _createInputDescriptor, but it is the most actively touched function in this list: 4 commits in the last 30 days, last changed just 1 day ago, with 3 distinct authors contributing over the last 90 days. That author spread combined with high recent activity is worth noting — when multiple contributors are making frequent changes to a function with 22 branching paths, the probability of a missed interaction between the matrix validation and the options validation rises.
The complex_branching and exit_heavy tags both apply, and the Object.values(this.constructor.interpolators) lookup in the interpolator validation introduces dynamic dispatch that static fan-out metrics will undercount.
Recommendation: Extract matrix validation into a standalone _validateAffineMatrix(matrix) function and options validation into _validateAffineOptions(options). Given the 3-author, 4-commit recent history, reducing the shared mutable surface area here will lower the chance of concurrent changes producing inconsistent validation behavior.
heif — output.mjs
The heif function sets encoding options for HEIF output — compression codec (av1 or hevc), quality, lossless mode, encoding effort, chroma subsampling, bit depth, and tuning mode. Each parameter follows the same guard-and-throw pattern seen in tile, with one notable interaction: the tune parameter silently overrides iq to ssim when lossless is also set. That conditional cross-parameter dependency — buried inside the options block — is the kind of behavior that is easy to break when someone adds a new codec or tuning mode.
CC 25 across 4 nesting levels with fan-out 8 puts heif below tile in raw complexity, but the complex_branching and exit_heavy tags apply here too. Two commits touched lib/output.mjs in the last 30 days; heif was last modified 5 days ago, the same day as tile — suggesting a coordinated output-layer change that touched both functions.
Recommendation: The lossless/tune interaction deserves an explicit named check — something like _resolveHeifTune(lossless, tune) — so the override logic is testable in isolation. The remaining parameter guards are candidates for the same parameter-object validation helper recommended for tile, which would bring both lib/output.mjs functions into alignment structurally.
resize — resize.mjs
The resize function is sharp’s most user-facing API entry point — it accepts width, height, and a full options object covering fit mode, position, background color, resampling kernel, enlargement and reduction constraints, and more. At CC 35 — matching tile — it is structurally complex, but its nesting depth of 3 is the shallowest in the top five, which is a meaningful distinction: the branching is wide rather than deep, making individual paths somewhat easier to follow in isolation.
The exit_heavy and long_function tags reflect the sheer surface area. The source excerpt shows resize accepting widthOrOptions as either a number or an options object — a polymorphic signature that immediately adds branching before the main options block even begins. The position lookup — strategy[options.position] || position[options.position] || gravity[options.position] — chains three separate lookups through different maps, any one of which could silently return undefined if a caller passes an unrecognized value, before the integer range check catches it.
Four commits have touched lib/resize.mjs in the last 30 days and resize was last changed 3 days ago. With 2 authors contributing recently, this is a function under active development.
Recommendation: The polymorphic widthOrOptions argument is the most immediate refactoring target — normalizing it into a canonical options object at the top of the function before any branching reduces CC by several paths and makes the rest of the function’s logic uniform. The position lookup chain is a second, smaller candidate: a single resolvePosition(value) helper that encapsulates the three-map fallback makes the silent-undefined risk explicit and testable.
Contextual signals from the watch quadrant
Several functions in lib/output.mjs and lib/libvips.mjs — including toFormat, globalLibvipsVersion, isUnsupportedNodeRuntime, and yarnLocator — sit in the watch quadrant with low structural complexity and moderate recent activity. These do not need refactoring attention now, but toFormat in particular is worth monitoring: it sits in the same file as tile and heif, and output-layer changes that touch those functions may propagate to it.
Summary takeaways
- Start with
_createInputDescriptorbefore the next development push. Its CC of 183 and nesting depth of 9 mean any change — however small — navigates 183 possible execution paths. The extract-method decomposition I described above is the highest-leverage single action available in this codebase right now. - Standardize output-layer validation across
tileandheif. Both functions live inlib/output.mjs, were both changed 5 days ago, and share the same guard-and-throw structure. A shared_validateOutputParamhelper would reduce duplication and make future codec additions cheaper to add correctly. - Treat
affine’s author spread as a risk multiplier. Three authors, 4 commits, 1 day since last change — that combination on a CC-22 function with dynamic interpolator dispatch deserves test coverage that explicitly exercises every matrix shape and every option combination. - The nesting depth of 9 in
_createInputDescriptoris the onlydeeply_nestedflag in the entire top five. That makes it structurally unique, not just highest-ranked. No other function in the top five has both agod_functiontag and adeeply_nestedtag — that combination is the clearest signal for immediate attention.
Patterns Found
Antipatterns detected across the top functions in this snapshot:
| Pattern | Occurrences |
|---|---|
exit_heavy | 5 |
complex_branching | 4 |
long_function | 3 |
deeply_nested | 1 |
god_function | 1 |
These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.
Reproduce This Analysis
git clone https://github.com/lovell/sharp
cd sharp
git checkout e000d0b5e128e05bb6c499600f37e2a6a4b74314
hotspots analyze . --mode snapshot --explain-patterns --force --hybrid-touches 5To run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.
I use Hotspots to highlight structural and activity risk — not “bad code.” I treat these findings as a prioritization aid, not a bug predictor. Editorial policy →