Public report of denoland/deno, published 26 October 2026. It has the same score, grades and number of
findings as the full report. The details of security findings (where they are in the code, which known
vulnerabilities and which passwords or keys were found) are left out, so nobody can use them against the project.
Public
Executive reportMeasured under the Code Assurance Index, an open standard for code quality, using its published scoring rules (rubric version 2026.10.5). Watchdog signed this survey and filed it in the standard's public register, where anyone can look it up by its survey ID. Check this survey →
Signed and filed in the standard's public register, 26 October 2026, 03:37 UTC · Survey ID cd_84d6461cd6684d8dba400ddb1bc25010
denoland/deno
Measured 26 October 2026, 03:10 UTC, at code version 6e9f66f
No regression since the last survey
A regression is a drop of 0.5 points or more in the score, or of 2.5 or more out of 10 in a dimension, since the last survey.
CAI scoreWeak
CriticalWeakAdequateStrongExemplary
Down 2 since the last survey
The score is built from these lenses. Each lens grades one area of the code, such as how easy it is to change or how well it is protected. The weakest lens counts most, so one weak area pulls the score down instead of being averaged away.
A very large codebase: 628,261 lines of product code in 72 projects, tests not counted · Estimated rebuild effort: about 5.9 person-years · Weakest lens: Code Health, 33
Findings by how serious they are
49 critical4310 serious182 minor
14 dimensions are left out of the score. For each one, Watchdog either couldn't measure it in this code, or found no evidence of the safeguard it looks for, such as a tested backup restore. They count neither for nor against the score, and Limitations lists each one with its reason.
This survey was produced by
Watchdog
Producer
Canine Development
Analyzer
Watchdog engine 1.0.0
Measured
26 October 2026, 03:10 UTC
A measurement, not a certificate. The Code Assurance Index records a number
together with the evidence it was worked out from, so anyone can recalculate it, but it doesn't certify or guarantee
the code. The standard was written by Canine Development, which also builds Watchdog. It is open to any tool that
implements it, and today Watchdog is the only one that does.
The score is deterministic, which means the same code always gets the same score. Watchdog works it out with tools that follow published rules, and an AI model never decides it, so anyone who applies the same rules to the same code gets the same number. How it is done is explained under Methodology ▸
79of 79 dimensions measured by tools.
4421of 4541 findings point to an exact file and line, so you can open each one in the code. The other 120 concern the repository as a whole, such as missing documentation.
79dimensions across 8 lenses, read from 628,261 lines of product code in 72 projects.
denoland/deno falls short of our standard for production, held back most by its Code Health lens, the quality of the code itself. It scores 46 out of 100 and is rated Weak, and 26 of its 49 critical findings are security problems.
Code Health, at 33, is the weakest lens and counts most in the score. The best first step is splitting the oversized files, worth about 6 points. Turning on missing-value checks comes next, worth about 4 points. Raising Code Health to 70 would lift the score to about 56.
Ten pipeline steps put outside input straight into a shell command, so an attacker can run commands in the build pipeline. Nine pipeline steps run downloads nobody checks, and nine parts of the code are no longer understood by anyone working on it. Passing outside input through environment variables, checking each download against a checksum and having someone learn the forgotten files would close these risks. Correcting the flagged pipeline settings would fix the three weaknesses in the build pipeline's configuration, and updating the vulnerable packages would deal with the two packages with a known security hole. The five sets of files in separate parts that keep changing together need that dependency made explicit.
The product code is 628,261 lines, about €860,000 to rebuild.
A lens is capped at Adequate while one of its dimensions scores below 4 out of 10, however well the rest of the lens does. That way a serious problem in one place always shows in the lens's rating.
How the score is built: what each lens counts forThe lenses don't count equally. The weakest lens counts most, the next weakest a little less, and so on, so a weak area pulls the score down instead of being averaged away. In the bar below, each part's width shows how much that lens counts and its colour shows its rating. Improving the widest part moves the score most, and as that lens improves, it counts for less, because another lens becomes the weakest.
Watchdog compares every finding with the previous survey's. A finding that has only moved to another line in the same file counts as the same finding, so only new findings appear here. Advisory notes from the AI model are left out, because the model words them afresh in every survey.
Fixed since the last survey: 1123 findings
These 1123 critical or serious findings were in the previous survey, on 12 October 2026, and are gone from this one. The first 100 are listed here.
€290,000 to €1,400,000, for 4,757 to 15,092 hours of work, about 5.9 person-years for 3 to 12 engineers
Difficulty of the problem
Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write.
Quality factor
×0.7 at a score of 46. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it.
Size
Very large: 628,261 lines of product code
What it is not
Not a quotation: nobody has offered to build it for that. Not a valuation: it says nothing about what the business is worth. Not a certified figure: no professional has signed it as one.
How the estimate is made: Watchdog prices the hours a team would need to write this code again, at €60 to €95 an hour. Declarations and boilerplate are priced at a fast rate and logic at a slower one, and the logic is then multiplied by the difficulty of the problem and by the quality factor. The estimate can be about 30% off either way, and it moves most with the hourly rate and the difficulty. For this code, every line is priced as straight logic, which keeps the estimate on the low side.
Top priorities
The three actions that raise the score most for the work they take. The full ranked list is in the Roadmap.
1
Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package.
Raises the score by about 6 points · Medium effort · Large Files
2
Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.
Each conclusion below combines several dimensions into one point that no single dimension shows, and lists the measurements it rests on.
Where the investment is most exposed · Value at risk
This code would cost about €860,000 to build again, about 5.9 person-years of work. Its weakest lens is Code Health, at 33 (Weak). Code Health is about how easy the code is to read and change safely, and code that is hard to read is slow and risky to change, so every future change costs more than it should. Because the weakest lens counts most in the score, work on Code Health also moves the score most.
Based on: the rebuild estimate · the Code Health grade · how much each lens counts
What to do: Start with the Code Health actions in Top priorities.
If you do one thing first · First action
Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package. Of all the actions in this report, it raises the score most for the work it takes: about 6 points for medium effort. The next survey will show the change in the score.
Based on: the ranked actions in Top priorities, by score gain and effort
What hard-to-read code costs each year · Cost
Four dimensions measure how easy the code is to work in: two measure how tangled its logic is, one how much of it is copied, and one how well each part sticks to a single job. In this codebase they average 6.6 out of 10. Code at that level is slower to change than clean code, and Watchdog estimates the extra work at 3% to 8% on every change. The history of the code shows how much it changes: about 70,456 lines over the last 90 days, which is about 285,738 lines a year. At that pace, the extra work comes to an estimated 24.2 to 145.2 engineer-days a year, and it grows as more code changes.
How this is estimated: The number of changed lines is measured from the history of the code. The rest rests on two assumptions of Watchdog's own: code scoring 8 out of 10 or more adds no extra work, and each point below 8 adds 2.5% to 5.6% to every change, never less than 2% to 5% and never more than 40% to 60% in all; and an engineer changes 150 to 400 lines in a day. The result is a range for planning, not a measurement.
Based on: Cyclomatic Complexity · Cognitive Complexity · Code Duplication · Cohesion (LCOM4) · the code's change history
What to do: Start with the files listed under Churn × Complexity Hotspots, which change often and are hard to read, because that is where the extra work is paid most often.
Architecture — module dependency graph
Project dependencies, layered top-to-bottom; arrows show direction. Any dashed red edge points upward or sideways, which only happens where the projects form a dependency cycle. A graph without cycles has none.
Architecture: which parts of the code depend on which
The code is divided into modules, groups of code that each handle one part of the product, and a module depends on another when it uses code from it. The table lists the modules both down the side and across the top, in an order where each module should only use modules listed above it. A number in a cell means the module on that row uses the module in that column, and it counts the pairs of building blocks (types) that connect them. The one thing to look for is a mark above the diagonal line. It means two or more modules use each other in a loop (a dependency cycle), so none of them can be changed, tested or released on its own.
1032 modules, with 2369 dependencies between them. 9 loops run through 209 of the modules, marked above the diagonal.
The table shows the 40 modules with the most connections; 992 more are left out to keep it readable.
Which modules use which. The module on each row uses the module in each column, and the number counts the pairs of types that connect them. A cell above the diagonal is part of a loop.
deno.tools.fmt uses deno_config.deno_json, so a change to deno_config.deno_json can break deno.tools.fmt, while a change to deno.tools.fmt can't break deno_config.deno_json.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
5→37 deno.tools.fmt uses deno_cli_parser.flagspart of a loop✕
Connections
2 pairs of types, where a type in deno.tools.fmt uses a type in deno_cli_parser.flags.
deno.tools.fmt uses deno_cli_parser.flags, so a change to deno_cli_parser.flags can break deno.tools.fmt, while a change to deno.tools.fmt can't break deno_cli_parser.flags.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_config.deno_json uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno_config.deno_json, while a change to deno_config.deno_json can't break deno_npmrc.ini.
Position
Below the diagonal: deno_config.deno_json uses a module listed above it, which is the healthy direction.
deno_config.deno_json uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_config.deno_json, while a change to deno_config.deno_json can't break deno.tools.fmt.
Position
Below the diagonal: deno_config.deno_json uses a module listed above it, which is the healthy direction.
deno_core.modules uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_core.modules, while a change to deno_core.modules can't break deno.tools.fmt.
Position
Below the diagonal: deno_core.modules uses a module listed above it, which is the healthy direction.
deno_npm.resolution.snapshot uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_npm.resolution.snapshot, while a change to deno_npm.resolution.snapshot can't break deno.tools.fmt.
Position
Below the diagonal: deno_npm.resolution.snapshot uses a module listed above it, which is the healthy direction.
8→12 deno_npm.resolution.snapshot uses deno_npmpart of a loop✕
Connections
11 pairs of types, where a type in deno_npm.resolution.snapshot uses a type in deno_npm.
deno_npm.resolution.snapshot uses deno_npm, so a change to deno_npm can break deno_npm.resolution.snapshot, while a change to deno_npm.resolution.snapshot can't break deno_npm.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_permissions uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_permissions, while a change to deno_permissions can't break deno.tools.fmt.
Position
Below the diagonal: deno_permissions uses a module listed above it, which is the healthy direction.
9→11 deno_permissions uses deno_fetch.proxypart of a loop✕
Connections
4 pairs of types, where a type in deno_permissions uses a type in deno_fetch.proxy.
deno_permissions uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_permissions, while a change to deno_permissions can't break deno_fetch.proxy.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno.http_util uses deno.tools.fmt, so a change to deno.tools.fmt can break deno.http_util, while a change to deno.http_util can't break deno.tools.fmt.
Position
Below the diagonal: deno.http_util uses a module listed above it, which is the healthy direction.
deno.http_util uses deno_permissions, so a change to deno_permissions can break deno.http_util, while a change to deno.http_util can't break deno_permissions.
Position
Below the diagonal: deno.http_util uses a module listed above it, which is the healthy direction.
deno_fetch.proxy uses deno.lsp.trace.stub_tracing, so a change to deno.lsp.trace.stub_tracing can break deno_fetch.proxy, while a change to deno_fetch.proxy can't break deno.lsp.trace.stub_tracing.
Position
Below the diagonal: deno_fetch.proxy uses a module listed above it, which is the healthy direction.
deno_fetch.proxy uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_fetch.proxy, while a change to deno_fetch.proxy can't break deno.tools.fmt.
Position
Below the diagonal: deno_fetch.proxy uses a module listed above it, which is the healthy direction.
deno_fetch.proxy uses deno_permissions, so a change to deno_permissions can break deno_fetch.proxy, while a change to deno_fetch.proxy can't break deno_permissions.
Position
Below the diagonal: deno_fetch.proxy uses a module listed above it, which is the healthy direction.
deno_npm uses deno_npm.resolution.snapshot, so a change to deno_npm.resolution.snapshot can break deno_npm, while a change to deno_npm can't break deno_npm.resolution.snapshot.
Position
Below the diagonal: deno_npm uses a module listed above it, which is the healthy direction.
node_resolver.resolution uses deno_npmrc.ini, so a change to deno_npmrc.ini can break node_resolver.resolution, while a change to node_resolver.resolution can't break deno_npmrc.ini.
Position
Below the diagonal: node_resolver.resolution uses a module listed above it, which is the healthy direction.
node_resolver.resolution uses deno_core.modules, so a change to deno_core.modules can break node_resolver.resolution, while a change to node_resolver.resolution can't break deno_core.modules.
Position
Below the diagonal: node_resolver.resolution uses a module listed above it, which is the healthy direction.
13→30 node_resolver.resolution uses deno_http_h1.parsepart of a loop✕
Connections
3 pairs of types, where a type in node_resolver.resolution uses a type in deno_http_h1.parse.
node_resolver.resolution uses deno_http_h1.parse, so a change to deno_http_h1.parse can break node_resolver.resolution, while a change to node_resolver.resolution can't break deno_http_h1.parse.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_core.async_cell uses deno.lsp.trace.stub_tracing, so a change to deno.lsp.trace.stub_tracing can break deno_core.async_cell, while a change to deno_core.async_cell can't break deno.lsp.trace.stub_tracing.
Position
Below the diagonal: deno_core.async_cell uses a module listed above it, which is the healthy direction.
deno_core.async_cell uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_core.async_cell, while a change to deno_core.async_cell can't break deno.tools.fmt.
Position
Below the diagonal: deno_core.async_cell uses a module listed above it, which is the healthy direction.
deno_core.async_cell uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_core.async_cell, while a change to deno_core.async_cell can't break deno_fetch.proxy.
Position
Below the diagonal: deno_core.async_cell uses a module listed above it, which is the healthy direction.
1 pair of types, where a type in deno_core.convert uses a type in deno_npmrc.ini.
The types involved
deno_core.convert.Numeric → deno_npmrc.ini.Value
Direction
deno_core.convert uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno_core.convert, while a change to deno_core.convert can't break deno_npmrc.ini.
Position
Below the diagonal: deno_core.convert uses a module listed above it, which is the healthy direction.
deno_core.convert uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_core.convert, while a change to deno_core.convert can't break deno_fetch.proxy.
Position
Below the diagonal: deno_core.convert uses a module listed above it, which is the healthy direction.
1 pair of types, where a type in deno_core.ops uses a type in deno_fetch.proxy.
The types involved
deno_core.ops.OpState → deno_fetch.proxy.Target
Direction
deno_core.ops uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_core.ops, while a change to deno_core.ops can't break deno_fetch.proxy.
Position
Below the diagonal: deno_core.ops uses a module listed above it, which is the healthy direction.
16→22 deno_core.ops uses deno_core.runtime.jsruntimepart of a loop✕
Connections
1 pair of types, where a type in deno_core.ops uses a type in deno_core.runtime.jsruntime.
deno_core.ops uses deno_core.runtime.jsruntime, so a change to deno_core.runtime.jsruntime can break deno_core.ops, while a change to deno_core.ops can't break deno_core.runtime.jsruntime.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_core.webidl uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_core.webidl, while a change to deno_core.webidl can't break deno.tools.fmt.
Position
Below the diagonal: deno_core.webidl uses a module listed above it, which is the healthy direction.
deno_core.webidl uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_core.webidl, while a change to deno_core.webidl can't break deno_fetch.proxy.
Position
Below the diagonal: deno_core.webidl uses a module listed above it, which is the healthy direction.
deno_core.async_cancel uses deno.lsp.trace.stub_tracing, so a change to deno.lsp.trace.stub_tracing can break deno_core.async_cancel, while a change to deno_core.async_cancel can't break deno.lsp.trace.stub_tracing.
Position
Below the diagonal: deno_core.async_cancel uses a module listed above it, which is the healthy direction.
deno_core.async_cancel uses deno_core.io.resource, so a change to deno_core.io.resource can break deno_core.async_cancel, while a change to deno_core.async_cancel can't break deno_core.io.resource.
Position
Below the diagonal: deno_core.async_cancel uses a module listed above it, which is the healthy direction.
deno_core.async_cancel uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_core.async_cancel, while a change to deno_core.async_cancel can't break deno.tools.fmt.
Position
Below the diagonal: deno_core.async_cancel uses a module listed above it, which is the healthy direction.
deno_core.async_cancel uses deno_core.async_cell, so a change to deno_core.async_cell can break deno_core.async_cancel, while a change to deno_core.async_cancel can't break deno_core.async_cell.
Position
Below the diagonal: deno_core.async_cancel uses a module listed above it, which is the healthy direction.
deno_core.cppgc uses deno_core.webidl, so a change to deno_core.webidl can break deno_core.cppgc, while a change to deno_core.cppgc can't break deno_core.webidl.
Position
Below the diagonal: deno_core.cppgc uses a module listed above it, which is the healthy direction.
deno_crypto uses deno_core.convert, so a change to deno_core.convert can break deno_crypto, while a change to deno_crypto can't break deno_core.convert.
Position
Below the diagonal: deno_crypto uses a module listed above it, which is the healthy direction.
serde_v8.magic.buffer uses deno.tools.fmt, so a change to deno.tools.fmt can break serde_v8.magic.buffer, while a change to serde_v8.magic.buffer can't break deno.tools.fmt.
Position
Below the diagonal: serde_v8.magic.buffer uses a module listed above it, which is the healthy direction.
serde_v8.magic.buffer uses deno_core.convert, so a change to deno_core.convert can break serde_v8.magic.buffer, while a change to serde_v8.magic.buffer can't break deno_core.convert.
Position
Below the diagonal: serde_v8.magic.buffer uses a module listed above it, which is the healthy direction.
deno_core.runtime.jsruntime uses deno.lsp.trace.stub_tracing, so a change to deno.lsp.trace.stub_tracing can break deno_core.runtime.jsruntime, while a change to deno_core.runtime.jsruntime can't break deno.lsp.trace.stub_tracing.
Position
Below the diagonal: deno_core.runtime.jsruntime uses a module listed above it, which is the healthy direction.
deno_core.runtime.jsruntime uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno_core.runtime.jsruntime, while a change to deno_core.runtime.jsruntime can't break deno_fetch.proxy.
Position
Below the diagonal: deno_core.runtime.jsruntime uses a module listed above it, which is the healthy direction.
deno_core.runtime.jsruntime uses deno_core.ops, so a change to deno_core.ops can break deno_core.runtime.jsruntime, while a change to deno_core.runtime.jsruntime can't break deno_core.ops.
Position
Below the diagonal: deno_core.runtime.jsruntime uses a module listed above it, which is the healthy direction.
deno_core.runtime.jsruntime uses deno_core.cppgc, so a change to deno_core.cppgc can break deno_core.runtime.jsruntime, while a change to deno_core.runtime.jsruntime can't break deno_core.cppgc.
Position
Below the diagonal: deno_core.runtime.jsruntime uses a module listed above it, which is the healthy direction.
deno_io.fs uses deno_core.io.resource, so a change to deno_core.io.resource can break deno_io.fs, while a change to deno_io.fs can't break deno_core.io.resource.
Position
Below the diagonal: deno_io.fs uses a module listed above it, which is the healthy direction.
deno_io.fs uses deno_core.async_cancel, so a change to deno_core.async_cancel can break deno_io.fs, while a change to deno_io.fs can't break deno_core.async_cancel.
Position
Below the diagonal: deno_io.fs uses a module listed above it, which is the healthy direction.
deno_maybe_sync.inner uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_maybe_sync.inner, while a change to deno_maybe_sync.inner can't break deno.tools.fmt.
Position
Below the diagonal: deno_maybe_sync.inner uses a module listed above it, which is the healthy direction.
deno_maybe_sync.inner uses deno_core.cppgc, so a change to deno_core.cppgc can break deno_maybe_sync.inner, while a change to deno_maybe_sync.inner can't break deno_core.cppgc.
Position
Below the diagonal: deno_maybe_sync.inner uses a module listed above it, which is the healthy direction.
deno_lib.worker uses deno_permissions, so a change to deno_permissions can break deno_lib.worker, while a change to deno_lib.worker can't break deno_permissions.
Position
Below the diagonal: deno_lib.worker uses a module listed above it, which is the healthy direction.
deno_lib.worker uses node_resolver.resolution, so a change to node_resolver.resolution can break deno_lib.worker, while a change to deno_lib.worker can't break node_resolver.resolution.
Position
Below the diagonal: deno_lib.worker uses a module listed above it, which is the healthy direction.
deno_lib.worker uses deno_core.runtime.jsruntime, so a change to deno_core.runtime.jsruntime can break deno_lib.worker, while a change to deno_lib.worker can't break deno_core.runtime.jsruntime.
Position
Below the diagonal: deno_lib.worker uses a module listed above it, which is the healthy direction.
deno.factory uses deno_resolver.factory, so a change to deno_resolver.factory can break deno.factory, while a change to deno.factory can't break deno_resolver.factory.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
26→31 deno.factory uses deno_config.workspacepart of a loop✕
Connections
2 pairs of types, where a type in deno.factory uses a type in deno_config.workspace.
deno.factory uses deno_config.workspace, so a change to deno_config.workspace can break deno.factory, while a change to deno.factory can't break deno_config.workspace.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
26→37 deno.factory uses deno_cli_parser.flagspart of a loop✕
Connections
2 pairs of types, where a type in deno.factory uses a type in deno_cli_parser.flags.
deno.factory uses deno_cli_parser.flags, so a change to deno_cli_parser.flags can break deno.factory, while a change to deno.factory can't break deno_cli_parser.flags.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_resolver.factory uses deno_config.deno_json, so a change to deno_config.deno_json can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_config.deno_json.
Position
Below the diagonal: deno_resolver.factory uses a module listed above it, which is the healthy direction.
deno_resolver.factory uses deno_npm, so a change to deno_npm can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_npm.
Position
Below the diagonal: deno_resolver.factory uses a module listed above it, which is the healthy direction.
deno_resolver.factory uses node_resolver.resolution, so a change to node_resolver.resolution can break deno_resolver.factory, while a change to deno_resolver.factory can't break node_resolver.resolution.
Position
Below the diagonal: deno_resolver.factory uses a module listed above it, which is the healthy direction.
deno_resolver.factory uses deno_maybe_sync.inner, so a change to deno_maybe_sync.inner can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_maybe_sync.inner.
Position
Below the diagonal: deno_resolver.factory uses a module listed above it, which is the healthy direction.
deno_resolver.factory uses deno.factory, so a change to deno.factory can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno.factory.
Position
Below the diagonal: deno_resolver.factory uses a module listed above it, which is the healthy direction.
27→28 deno_resolver.factory uses deno_resolver.deno_jsonpart of a loop✕
Connections
1 pair of types, where a type in deno_resolver.factory uses a type in deno_resolver.deno_json.
deno_resolver.factory uses deno_resolver.deno_json, so a change to deno_resolver.deno_json can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_resolver.deno_json.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
27→31 deno_resolver.factory uses deno_config.workspacepart of a loop✕
Connections
1 pair of types, where a type in deno_resolver.factory uses a type in deno_config.workspace.
deno_resolver.factory uses deno_config.workspace, so a change to deno_config.workspace can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_config.workspace.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
27→32 deno_resolver.factory uses deno_resolver.workspacepart of a loop✕
Connections
1 pair of types, where a type in deno_resolver.factory uses a type in deno_resolver.workspace.
deno_resolver.factory uses deno_resolver.workspace, so a change to deno_resolver.workspace can break deno_resolver.factory, while a change to deno_resolver.factory can't break deno_resolver.workspace.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_resolver.deno_json uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_resolver.deno_json, while a change to deno_resolver.deno_json can't break deno.tools.fmt.
Position
Below the diagonal: deno_resolver.deno_json uses a module listed above it, which is the healthy direction.
deno_resolver.deno_json uses deno_maybe_sync.inner, so a change to deno_maybe_sync.inner can break deno_resolver.deno_json, while a change to deno_resolver.deno_json can't break deno_maybe_sync.inner.
Position
Below the diagonal: deno_resolver.deno_json uses a module listed above it, which is the healthy direction.
deno_resolver.deno_json uses deno_resolver.factory, so a change to deno_resolver.factory can break deno_resolver.deno_json, while a change to deno_resolver.deno_json can't break deno_resolver.factory.
Position
Below the diagonal: deno_resolver.deno_json uses a module listed above it, which is the healthy direction.
28→31 deno_resolver.deno_json uses deno_config.workspacepart of a loop✕
Connections
2 pairs of types, where a type in deno_resolver.deno_json uses a type in deno_config.workspace.
deno_resolver.deno_json uses deno_config.workspace, so a change to deno_config.workspace can break deno_resolver.deno_json, while a change to deno_resolver.deno_json can't break deno_config.workspace.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno.tsc uses node_resolver.resolution, so a change to node_resolver.resolution can break deno.tsc, while a change to deno.tsc can't break node_resolver.resolution.
Position
Below the diagonal: deno.tsc uses a module listed above it, which is the healthy direction.
deno.tsc uses deno_resolver.deno_json, so a change to deno_resolver.deno_json can break deno.tsc, while a change to deno.tsc can't break deno_resolver.deno_json.
Position
Below the diagonal: deno.tsc uses a module listed above it, which is the healthy direction.
29→37 deno.tsc uses deno_cli_parser.flagspart of a loop✕
Connections
1 pair of types, where a type in deno.tsc uses a type in deno_cli_parser.flags.
deno.tsc uses deno_cli_parser.flags, so a change to deno_cli_parser.flags can break deno.tsc, while a change to deno.tsc can't break deno_cli_parser.flags.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_config.workspace uses deno_config.deno_json, so a change to deno_config.deno_json can break deno_config.workspace, while a change to deno_config.workspace can't break deno_config.deno_json.
Position
Below the diagonal: deno_config.workspace uses a module listed above it, which is the healthy direction.
deno_config.workspace uses deno_maybe_sync.inner, so a change to deno_maybe_sync.inner can break deno_config.workspace, while a change to deno_config.workspace can't break deno_maybe_sync.inner.
Position
Below the diagonal: deno_config.workspace uses a module listed above it, which is the healthy direction.
deno_config.workspace uses deno_http_h1.parse, so a change to deno_http_h1.parse can break deno_config.workspace, while a change to deno_config.workspace can't break deno_http_h1.parse.
Position
Below the diagonal: deno_config.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno_npmrc.ini.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno.tools.fmt, so a change to deno.tools.fmt can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno.tools.fmt.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno_core.modules, so a change to deno_core.modules can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno_core.modules.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses node_resolver.resolution, so a change to node_resolver.resolution can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break node_resolver.resolution.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno_maybe_sync.inner, so a change to deno_maybe_sync.inner can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno_maybe_sync.inner.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno_resolver.deno_json, so a change to deno_resolver.deno_json can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno_resolver.deno_json.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno_resolver.workspace uses deno_config.workspace, so a change to deno_config.workspace can break deno_resolver.workspace, while a change to deno_resolver.workspace can't break deno_config.workspace.
Position
Below the diagonal: deno_resolver.workspace uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno.lsp.config, while a change to deno.lsp.config can't break deno_npmrc.ini.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno_config.deno_json, so a change to deno_config.deno_json can break deno.lsp.config, while a change to deno.lsp.config can't break deno_config.deno_json.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno.http_util, so a change to deno.http_util can break deno.lsp.config, while a change to deno.lsp.config can't break deno.http_util.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno_fetch.proxy, so a change to deno_fetch.proxy can break deno.lsp.config, while a change to deno.lsp.config can't break deno_fetch.proxy.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno_config.workspace, so a change to deno_config.workspace can break deno.lsp.config, while a change to deno.lsp.config can't break deno_config.workspace.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno.lsp.config uses deno_resolver.workspace, so a change to deno_resolver.workspace can break deno.lsp.config, while a change to deno.lsp.config can't break deno_resolver.workspace.
Position
Below the diagonal: deno.lsp.config uses a module listed above it, which is the healthy direction.
deno_npm_installer uses deno_config.deno_json, so a change to deno_config.deno_json can break deno_npm_installer, while a change to deno_npm_installer can't break deno_config.deno_json.
Position
Below the diagonal: deno_npm_installer uses a module listed above it, which is the healthy direction.
deno_npm_installer uses deno_npm.resolution.snapshot, so a change to deno_npm.resolution.snapshot can break deno_npm_installer, while a change to deno_npm_installer can't break deno_npm.resolution.snapshot.
Position
Below the diagonal: deno_npm_installer uses a module listed above it, which is the healthy direction.
deno_npm_installer uses deno_resolver.workspace, so a change to deno_resolver.workspace can break deno_npm_installer, while a change to deno_npm_installer can't break deno_resolver.workspace.
Position
Below the diagonal: deno_npm_installer uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno.tools.fmt, so a change to deno.tools.fmt can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno.tools.fmt.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno_core.modules, so a change to deno_core.modules can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno_core.modules.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno.http_util, so a change to deno.http_util can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno.http_util.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses node_resolver.resolution, so a change to node_resolver.resolution can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break node_resolver.resolution.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno.factory, so a change to deno.factory can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno.factory.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno_resolver.deno_json, so a change to deno_resolver.deno_json can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno_resolver.deno_json.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno_resolver.workspace, so a change to deno_resolver.workspace can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno_resolver.workspace.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.resolver uses deno.lsp.config, so a change to deno.lsp.config can break deno.lsp.resolver, while a change to deno.lsp.resolver can't break deno.lsp.config.
Position
Below the diagonal: deno.lsp.resolver uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno.lsp.trace.stub_tracing, so a change to deno.lsp.trace.stub_tracing can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno.lsp.trace.stub_tracing.
Position
Below the diagonal: deno.lsp.tsc uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno_config.deno_json, so a change to deno_config.deno_json can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno_config.deno_json.
Position
Below the diagonal: deno.lsp.tsc uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno_core.convert, so a change to deno_core.convert can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno_core.convert.
Position
Below the diagonal: deno.lsp.tsc uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno_core.runtime.jsruntime, so a change to deno_core.runtime.jsruntime can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno_core.runtime.jsruntime.
Position
Below the diagonal: deno.lsp.tsc uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno_resolver.deno_json, so a change to deno_resolver.deno_json can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno_resolver.deno_json.
Position
Below the diagonal: deno.lsp.tsc uses a module listed above it, which is the healthy direction.
deno.lsp.tsc uses deno.lsp.language_server, so a change to deno.lsp.language_server can break deno.lsp.tsc, while a change to deno.lsp.tsc can't break deno.lsp.language_server.
Position
Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
deno_cli_parser.flags uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno_cli_parser.flags, while a change to deno_cli_parser.flags can't break deno_npmrc.ini.
Position
Below the diagonal: deno_cli_parser.flags uses a module listed above it, which is the healthy direction.
deno_cli_parser.flags uses deno_config.deno_json, so a change to deno_config.deno_json can break deno_cli_parser.flags, while a change to deno_cli_parser.flags can't break deno_config.deno_json.
Position
Below the diagonal: deno_cli_parser.flags uses a module listed above it, which is the healthy direction.
deno_cli_parser.flags uses deno_npm_installer, so a change to deno_npm_installer can break deno_cli_parser.flags, while a change to deno_cli_parser.flags can't break deno_npm_installer.
Position
Below the diagonal: deno_cli_parser.flags uses a module listed above it, which is the healthy direction.
deno.args uses deno_config.deno_json, so a change to deno_config.deno_json can break deno.args, while a change to deno.args can't break deno_config.deno_json.
Position
Below the diagonal: deno.args uses a module listed above it, which is the healthy direction.
deno.args uses deno_config.workspace, so a change to deno_config.workspace can break deno.args, while a change to deno.args can't break deno_config.workspace.
Position
Below the diagonal: deno.args uses a module listed above it, which is the healthy direction.
deno.args uses deno_resolver.workspace, so a change to deno_resolver.workspace can break deno.args, while a change to deno.args can't break deno_resolver.workspace.
Position
Below the diagonal: deno.args uses a module listed above it, which is the healthy direction.
deno.args uses deno_cli_parser.flags, so a change to deno_cli_parser.flags can break deno.args, while a change to deno.args can't break deno_cli_parser.flags.
Position
Below the diagonal: deno.args uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno_npmrc.ini, so a change to deno_npmrc.ini can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno_npmrc.ini.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.tools.fmt, so a change to deno.tools.fmt can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.tools.fmt.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.http_util, so a change to deno.http_util can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.http_util.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.factory, so a change to deno.factory can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.factory.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.lsp.config, so a change to deno.lsp.config can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.lsp.config.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.lsp.resolver, so a change to deno.lsp.resolver can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.lsp.resolver.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.lsp.language_server uses deno.lsp.tsc, so a change to deno.lsp.tsc can break deno.lsp.language_server, while a change to deno.lsp.language_server can't break deno.lsp.tsc.
Position
Below the diagonal: deno.lsp.language_server uses a module listed above it, which is the healthy direction.
deno.module_loader uses deno_core.modules, so a change to deno_core.modules can break deno.module_loader, while a change to deno.module_loader can't break deno_core.modules.
Position
Below the diagonal: deno.module_loader uses a module listed above it, which is the healthy direction.
deno.module_loader uses deno_permissions, so a change to deno_permissions can break deno.module_loader, while a change to deno.module_loader can't break deno_permissions.
Position
Below the diagonal: deno.module_loader uses a module listed above it, which is the healthy direction.
deno.module_loader uses deno_lib.worker, so a change to deno_lib.worker can break deno.module_loader, while a change to deno.module_loader can't break deno_lib.worker.
Position
Below the diagonal: deno.module_loader uses a module listed above it, which is the healthy direction.
deno.module_loader uses deno_config.workspace, so a change to deno_config.workspace can break deno.module_loader, while a change to deno.module_loader can't break deno_config.workspace.
Position
Below the diagonal: deno.module_loader uses a module listed above it, which is the healthy direction.
Findings mapped to OWASP categories; the specific CVEs/secrets are in the Security dimension cards below and findings.md (redacted only on the public version of this report).
OWASP category
Findings
Severity
A05:2025 — Injection
44
High / Critical
A03:2025 — Software Supply Chain Failures
38
High / Critical
A02:2025 — Security Misconfiguration
4
Medium
Roadmap
Begin by splitting large files into smaller, focused modules and enabling nullable reference types across all projects to resolve warnings directly. Next, clean up dependencies by removing unused packages and explicitly declaring imports, while simultaneously adding tests for unreached production modules. Finally, reduce cyclomatic complexity by breaking down branch-heavy functions to improve maintainability.
Ranked by impact ÷ effort. "Helps" is the estimated gain on the 0–100 health score.
Do this
Helps
Effort
Dimension
Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package.
TypeScript/JavaScript: use the promise APIs (fs/promises, a promisified child_process.execFile, the async zlib/crypto functions) and await them instead of the *Sync variants.
Your ecosystem's static analyzer is declared as a dependency but is not wired into CI — run it as a required step on push/PR (e.g. `composer phpstan` / `mix sobelow` / `bundle exec brakeman` / the spotbugs Gradle task / `sbt scalafixAll --check` / `golangci-lint run` / `rebar3 lint`) so a regression fails the build instead of relying on someone running it locally.
Every finding carries one of four grades. Three say how serious it is. The fourth says this
survey could not settle it — and it is a grade, not a gap.
Critical — 49
A definite problem that already costs you something and drags the score down: a
missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here
tends to cause failures elsewhere.
Serious — 4310
Likely wrong, but not failing yet. It degrades
the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to
carry for two years either.
Minor — 182
Recorded, with no effect on how the codebase functions.
Present so the survey is complete, not because it needs doing.
Could not be resolved — 14
Something this survey could not settle
from the outside, and which could be critical or serious. Either a control was required and no
positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves
nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean
result. These are excluded from the score rather than awarded a pass, so the number on the cover neither
rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each
one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 79 of 79 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); none rely on LLM judgement. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
Every figure here is one of three kinds, and we label which: ✓ Measured — a deterministic fact (LoC, complexity, coverage); ~ Modeled — an estimate from a stated model (cost, effort, value-at-risk), always a range with its assumptions, never a precise fact; ◐ Advisory — an LLM prose judgement. We never present a modelled estimate as if it were measured. Perfect or absent scores carry their provenance too (ADR-0011): ✓ Tool-verified means the property itself was measured across the surface; ○ Nothing flagged means the probes came back clean — a claim bounded by what a repository can show; ⊘ Not evidenced means a working control (a tested restore, an automated rollback) showed no positive evidence — absence of evidence is not evidence of a control, so it's excluded from the score rather than awarded a spurious 10; ◐ Sampled · advisory marks an LLM verdict over a bounded sample — advisory, never a deterministic measurement.
What we checked — 79 dimensions across the health lenses
Each chip is a dimension scored from real signals across architecture, testing, dependencies, security & compliance, documentation, git-history and code quality — in one coherent pass. A surface report typically covers a handful.
How to trust any code-health report — three questions
Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 4421 of 4541 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line. (Every path in this report is repo-relative by construction: paths are normalized at the producer and the report is rejected if any rooted path leaks through.)
Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
This report answers yes to all three. That's the bar to hold any assessment to.
Tools & methods
The actual versions used this run (captured at analysis time) — re-run on the same commit for the identical score.
Method
Backs
Version
Evaluator
Roslyn static analysis
Complexity, cohesion, coupling, dead code, API surface, layering
What ran differently this time — a tool absent, degraded, or that fell back to an estimate. Named openly, not folded silently into the scores. A degraded run also records its exact cause in diagnostics.md.
D10 Test Quality — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. The 2 test(s) behind this row are the ones the JavaScript/TypeScript census could read, and this repository also carries at least 177 test source file(s) (.rs) that it cannot: it reads JavaScript/TypeScript test declarations off disk, so a JUnit/pytest-style suite is invisible to it. Skipped tests, zero-assertion tests and the other quality signals on this row are UNMEASURED in that suite — their absence from the counts above is a gap in this analyzer's language coverage, not a finding that those tests are sound.
D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test source is present (.ts, .rs, .tsx, .mts, .cts, .js, .mjs) and this repository declares a Cargo test suite (repository root, 354 test files), but it was not re-run: no test result was produced. Not scored — this is a gap in the analyzer's language coverage, not a finding about this repository.
D19 Documentation Quality — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. Each ecosystem's manifests (what makes a folder runnable or a published package) need their own proof before D19 judges its units. Until then those folders' READMEs are judged only as documents (boilerplate, structure), never counted as complete.
D21 Naming Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D21's deterministic naming rules are gated on C# first (docs/plans/deterministic-engine.md, P5): each other language is switched on only after its own concept suite and A/B gate pass. Until then its declarations carry no naming verdict this run — this says nothing about whether its names are consistent.
D22 Internal API Consistency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. D22's deterministic call-shape rules are gated on C# first (docs/plans/deterministic-engine.md, P5): each other language is switched on only after its own concept suite and A/B gate pass. This says nothing about whether that surface is consistent.
D24 Comment Value — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check's reader does not cover the language this repository's product is written in, so it had nothing of the product to read. That is a gap in this analyzer's language reach — not a finding about this repository.
D27 Navigability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Navigability is taken over call sites whose callee resolved. For C# that population includes calls into referenced assemblies; for this language only calls declared inside the repository count, so the abstention threshold reads the repository's use of its standard library as a resolution failure. That is a limit of this analyzer, not a build problem in this repository.
D28 Secrets (history) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `gitleaks` TIMED OUT after 393.2s against a 393.2s budget, so we killed its process tree. The budget is ours; the work may simply be larger than it allows. Nothing about this repository is asserted by the absence of a result; the budget is ours to raise, and raising it is our backlog item, not an action for this repository's owner.
D31 IaC & Container Security — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. Checkov ran but its report could not be read (checkov produced no output — not a clean result). Every misconfiguration only checkov reports — most of its Terraform, CloudFormation, Bicep and Ansible policies — is absent from this card, so its absence here is not evidence those resources are configured correctly.
D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `cli/tsc/dts/lib.deno.ns.d.ts`, `cli/tsc/dts/lib.deno.unstable.d.ts`, `cli/tsc/dts/lib.es2015.iterable.d.ts`, `cli/tsc/dts/lib.es2015.symbol.wellknown.d.ts`, `cli/tsc/dts/lib.es2018.asynciterable.d.ts`, … (+18 more) produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via DevServer (dev). the dev server did not expose a crawlable HTTP endpoint in time — no runtime evidence.
IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
M4 Documentation accuracy — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. M4 checks only the claim kinds adjudicated at or above 95 % precision: links and versions (PREREGISTRATION version 9). Paths, command arguments, installs, environment variables, settings, projects, packages, routes, cd targets, infrastructure products and removed modules are read but not checked, and none of them is reported or counted.
P5 DR & Backup — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. No backup/snapshot/replication config, RTO/RPO or restore-procedure documentation was found — and no production persistence was detected either (no data-access packages, no data-store services, no database resources), so there is nothing in this repository whose loss a DR control would recover. If this system's data lives in a platform or ops repo we can't see, that's where the DR evidence belongs.
PF3 Async & latency hygiene — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 16 further occurrence(s) are not listed individually; the score already reflects all 56.
R10 Code Duplication — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 427 further occurrence(s) are not listed individually; the score already reflects all 467.
R3 Large Files — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 93 further occurrence(s) are not listed individually; the score already reflects all 133.
R4 Test Coverage — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 483 further occurrence(s) are not listed individually; the score already reflects all 523.
R7 Dead Code — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 85 further occurrence(s) are not listed individually; the score already reflects all 125.
X1 Async correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
X27 Collection changed while being enumerated — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This repository's C# was parsed (it ships no .sln or .csproj, so it was read as syntax-only projects), but this check proves its findings from resolved symbols and a reference-free parse resolves none. It abstained rather than report a clean bill it could not earn. That is a gap in this analyzer's reach into build-less repositories — not a finding that the repository is free of what this check looks for.
X3 Exception handling — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
X4 Structured logging — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
Repo exclusion declarations: 2 pattern(s) declared (.gitattributes linguist-generated/vendored, .editorconfig generated_code) excluded 0 source file(s) from code-quality scoring. Declarations are the repo's own visible statement that a tree is machine-written or vendored — auditable in any diff, honored by GitHub the same way.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
For each dimension that was measured, what a static, repo-only scan structurally cannot see — the honest edge of the measurement, not a failure of it.
D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
D8 Code Coverage: Coverage is measured by building and running the test suite inside Watchdog's isolated image — the target repo is never modified, and nothing on your systems runs. So coverage exists only when the suite builds and runs within the inline time budget; one that needs external services, can't build, or exceeds the budget yields no coverage (D8 then degrades to not-measured, not a low score). Line coverage also says nothing about assertion quality.
D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
D19 Documentation Quality: Documentation quality publishes two things only: a runnable or packaged unit with no example, and a multi-project root README that maps none of its parts. It does not judge clarity, and its other checks (overview, licence, boilerplate, structure, empty sections, XML-doc coverage) are withheld after adjudication: their candidates are counted in the card's gaps, not shown as rows. A false statement in a document is M4's; units are .NET projects only.
D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
D31 IaC & Container Security: IaC scanning checks Dockerfiles/Terraform/Kubernetes against best-practice rules — it cannot see the live cloud account, runtime configuration, or drift between the committed config and what is actually deployed.
D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
D43 Malicious Dependencies: Only packages some vulnerability database has already NAMED as malicious are seen — a compromise published in the last hours, or never reported at all, is invisible here, and this dimension reading 10 is not evidence that a dependency is trustworthy. There is no typosquat or dependency-confusion analysis: a package nobody has reported is simply absent from the feeds. Coverage is the dependency scan's: an ecosystem that could not be scanned is disclosed as unmeasured, never as clean.
D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a REDACTED (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
DM4 Rich vs anemic domain model: Behaviour is detected as state mutation inside a method body — a method that enforces an invariant by validating-and-throwing without mutating reads as a query, and mutation delegated through an interface the scan can't resolve isn't credited; entities with zero public properties still drop out of the population. It detects that state changes, not whether the rule is correct.
M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
What it measures: How tangled the control flow is — methods with many branches are hard to test and change.
Method: Cyclomatic complexity per method (1 + decision points), computed exhaustively across production source; test projects separated by convention. Deterministic.
731 method(s) exceeded the cyclomatic complexity threshold of 15; the worst was Url.resolveObject at 117. A further 60 method(s) were over the threshold but excluded as flat dispatchers (a long switch/match over independent cases: many branches, almost no nesting), the largest being deno_core::uv_compat::tty::get_vt100_fn_key at 137 — they are counted neither in the figure above nor in this dimension's score. 21 files carry no cyclomatic complexity row at all for this reason — every one of their over-threshold methods was excluded, so the exclusion is disclosed nowhere in the file itself: cli/tools/lint/ast_buffer/ts_estree.rs (AstProp::fmt at 119), ext/node/ops/winerror.rs (deno_node::ops::winerror::op_node_sys_to_uv_error at 99), runtime/subprocess_windows/src/uv_error.rs (deno_subprocess_windows::uv_error::uv_translate_sys_error at 74), ext/web/console/quote.rs (deno_web::console::quote::meta_escape at 68), ext/node_crypto/digest.rs (Hash::get_size at 57), and 16 more not listed here. They are named here because the per-file figures other dimensions report are taken BEFORE this exclusion, so such a file can show a high maximum complexity elsewhere in this report and nothing here, with nothing to reconcile the two.
+ 377 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Bring the 28 bodies over 60 down to 60 or less in Cyclomatic Complexity — start with Url.resolveObject (cyclomatic 117), utils.emitKeys (cyclomatic 112), emitKeys (cyclomatic 112). — This score is capped by its worst body, so a finding fixed alone moves it by almost nothing — the next one down takes its place. Refactoring these 28 together lifts Cyclomatic Complexity from 5.5 to about 6.3/10, projected with the scoring formula itself and assuming each lands exactly at 60; a cleaner split scores higher.
Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Detailed fixes: d1_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: How hard the code is for a person to follow, beyond raw branching.
Method: Cognitive complexity per method (Sonar-style nesting-penalized score), computed exhaustively over production code, excluding test projects. Deterministic.
+ 590 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Bring the 1 body over 240 down to 240 or less in Cognitive Complexity — start with Glob.#iterateSubpatterns (cognitive 275). — Refactoring it lifts Cognitive Complexity from 2.1 to about 2.3/10.
Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Detailed fixes: d2_recommendation.md · top locations in Appendix A, every location in findings.md.
Do you agree with this assessment?
D3 · God Classes7.3 / 10Strong✓ Tool-verified
What it measures: Over-large classes that try to do too much ("god classes").
Method: God-class detection by line and method-count thresholds per logical type (partial classes unified), filtered for generated code and registration/contract false positives. Deterministic.
+ 1 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 246 FileTooLong finding(s) in God Classes — start with lib.rs (22), mod.rs (16), desktop.rs (2). — One of this dimension's main actionable groups (246 warning-level).
Resolve the 191 FunctionTooLong finding(s) in God Classes — start with lib.rs (10), mod.rs (8), desktop.rs (6). — One of this dimension's main actionable groups (191 warning-level).
Resolve the 118 MethodTooLong finding(s) in God Classes — start with lib.rs (8), mod.rs (7), graph.rs (4). — One of this dimension's main actionable groups (118 warning-level).
Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Detailed fixes: d3_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Copy-pasted code that should be shared instead.
Method: Code duplication via token-stream sliding windows with type-aware normalization (locals masked, type names preserved), density-scored per KLoC of production code. Deterministic.
946 duplicated block group(s) detected. A further 39 rows report members as variants of one another; they aggregate block groups already counted above and are not themselves counted. 1 of the 985 are in trees this repository does not ship — vendored, example/demo, project-template, fixture and benchmark code — and are ranked below the shipped groups rather than excluded from them: the duplication there is real and is still counted in this dimension's score. The dimensions that publish a production-file census leave those trees out of theirs, so this count is deliberately drawn over the wider population.
+ 215 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 58 Duplicated block (8 lines × 2) finding(s) in Code Duplication — start with ops.rs (4), lib.rs (3), css_value.rs (3). — One of this dimension's main actionable groups (58 warning-level).
Resolve the 57 Duplicated block (10 lines × 2) finding(s) in Code Duplication — start with mod.rs (4), lib.rs (4), node_interop.rs (3). — One of this dimension's main actionable groups (57 warning-level).
Resolve the 56 Duplicated block (6 lines × 2) finding(s) in Code Duplication — start with lib.rs (7), tls_wrap.rs (3), inspect.rs (3). — One of this dimension's main actionable groups (56 warning-level).
Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Detailed fixes: d4_recommendation.md · top locations in Appendix A, every location in findings.md.
Do you agree with this assessment?
D5 · Coupling7.1 / 10Adequategated by 1 critical finding✓ Tool-verified
What it measures: Whether volatile projects sit underneath others that depend on them (so their churn ripples upward), and whether project dependencies form cycles. A widely-depended-on but stable shared/kernel project is healthy, not penalised.
Method: Dependency cycles via elementary-DFS over real .csproj references, plus Martin instability (afferent/efferent) per project. Exhaustive over the reference graph, deterministic.
Coverage: Exhaustive · type-level: afferent/efferent coupling + cycles computed over every production type — the population is all types, not a name convention.
72 production modules (Cargo+Deno), 1 dependency cycle(s), 6 unstable depended-on module(s). Read from the build's own module declarations; 14 module(s) off the main sequence, with abstractness counted on 60 of the 72 (the rest declare no modelled class or interface, export only macros, declare types in source no model reads, or have no source directory of their own).
+ 3 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 1 Circular dependency finding(s) in Coupling — start with package.json. — One of this dimension's main actionable groups (1 issue-level).
Resolve the 14 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (14 warning-level).
Resolve the 1 Unstable project deno_cli_parser finding(s) in Coupling. — One of this dimension's main actionable groups (1 warning-level).
Enforce Coupling in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Detailed fixes: d5_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether a class's methods are focused on a single responsibility.
Method: LCOM4 cohesion per production class with at least two methods: connected components of methods sharing state or calls, computed syntactically. Deterministic, not a proxy.
Coverage: Exhaustive · type-level: LCOM4 cohesion computed over every production class — the population is all types, not a name convention.
Resolve the 17 Low cohesion finding(s) in Cohesion (LCOM4) — start with geometry.rs (2), lib.rs (2), ops_tls.rs. — One of this dimension's main actionable groups (17 warning-level).
Enforce Cohesion (LCOM4) in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Detailed fixes: d6_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: How much of the code is actually exercised by tests.
Method: Coverage from coverlet runs or committed reports (Cobertura/OpenCover/lcov), computed per-file with structured exclusions for generated, trivial, and glue code. When the suite can't be built/run in-image AND no report is committed, coverage is reported NOT-MEASURED (excluded from the score) with the precondition to make it measurable — never a LoC-ratio proxy folded in as if measured. Deterministic.
Line coverage 62.9% — read from a committed lcov report (tests/testdata/coverage/complex_expected.lcov); the in-image collector couldn't run the suite (commonly external-service dependencies). A real measurement, but from a committed artifact rather than a fresh in-image run.
Coverage read from a committed report
✓ On the Gold path — maintain.
Detailed fixes: d8_recommendation.md · top locations in Appendix A, every location in findings.md.
Do you agree with this assessment?
D9 · Test Distribution10.0 / 10Exemplary✓ Tool-verified
What it measures: Whether the test suite has a healthy mix of unit / integration / end-to-end tests.
Method: Test projects classified (Unit/Integration/BDD/E2E) from compiled metadata; test methods counted exhaustively across projects with placement-agnostic disk fallback. Deterministic.
4227 test methods: 3359 unit, 867 integration, 1 BDD, 0 e2e. The JavaScript/TypeScript suite contributes 2 `it`/`test` case(s) across 2 test file(s) declaring at least one; its tier split is read from package names and paths only. The Rust suite contributes 4225 `#[test]` function(s) across 354 file(s) declaring at least one; its unit/integration split is Cargo's own — 40 of those file(s) are integration-test targets under a crate's tests/ directory, and the rest are #[test] functions compiled into the crate they test.
✓ On the Gold path — maintain.
Detailed fixes: d9_recommendation.md.
Do you agree with this assessment?
D10 · Test Quality10.0 / 10Exemplary✓ Tool-verified
What it measures: Whether the tests truly assert behaviour rather than just running the code.
Method: Per-test assertions, skips, and mock references analyzed via Roslyn; structured skip-reason tags (BUG:/ENV:) separate documented deferrals from debt. Deterministic.
2 skipped (2 with a documented reason), 0 zero-assertion, no mocking-framework packages referenced (hand-written doubles or no mocking) across 2 tests. Measured on the JavaScript/TypeScript suite only — at least 177 test source file(s) (.rs) went unread, so its test quality is unmeasured and is not in these counts.
What it measures: Whether dependencies are current, secure, and not bloated.
Method: Manifest scan via dotnet list package across all projects; worst-signal-per-package deduction (saturating for vulnerabilities, capped-linear for deprecation/outdated) per KLoC. Exhaustive, deterministic.
78 outdated, 0 yanked direct Cargo dependencies. 281 of 287 direct crates were graded against crates.io (0 not published there, 6 not resolved by a committed REDACTED). Only DIRECT edges are graded: a transitive crate cannot be moved past what its parent's requirement admits, so reporting one would be advice its owner cannot take. A newer release is reported only where this repository's OWN requirement already admits it, so the remedy is `cargo update` and never a manifest edit — which means a release outside the declared range is deliberately NOT charged, because a written-down constraint is a decision rather than a defect. Note that a bare requirement is a CARET, and for a 0.x crate its ceiling is the minor. Whether any crate is UNMAINTAINED is not graded — crates.io publishes no maintenance status, and release age does not stand in for one. Known CVEs in this dependency graph are D30's question, read from REDACTED there.
Outdated: aead-gcm-stream · ×78
What to do
Enforce Dependency Hygiene in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
Detailed fixes: d12_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether any secrets (keys, tokens, passwords) have leaked into the code.
Method: In-process native secret scanner (entropy plus signature patterns) across all tracked files; no external tool. A clean result is a measured 10, not no-data zero. Deterministic.
What it measures: Whether the licenses of third-party packages are compatible with your policy.
Method: Third-party package licenses resolved from declared package metadata and checked against the configured policy (allow/deny/copyleft). Deterministic; clean = no incompatible license found at metadata depth.
0 of 1030 shipped crate(s) use a banned license. Licences were resolved from crates.io over the crates a consumer compiles — this repository's REDACTED closed over its manifests' `[dependencies]` and `[build-dependencies]`. Crates it asks for ONLY under `[dev-dependencies]` are excluded: they are not compiled by anything that depends on this repository. This repository publishes itself under MIT, which is its own choice and is not judged here.
What it measures: Files that change often and are also complex — the riskiest hotspots.
Method: Per production file churn times cyclomatic complexity over a rolling window, computed from git and Roslyn/JS/Razor analysis. Exhaustive, deterministic per commit date.
Top hotspots: libs/cli_parser/src/convert.rs (10×56=560); REDACTED (10×49=490); cli/lib.rs (4×71=284) Repeated repair below the complexity floor: ext/net/ops.rs (5 of 5 changes were fixes); tests/unit/fetch_test.ts (5 of 5 changes were fixes); ext/napi/lib.rs (4 of 5 changes were fixes)
Resolve the 16 Hotspot finding(s) in Churn × Complexity Hotspots — start with lib.rs (2), convert.rs, REDACTED. — One of this dimension's main actionable groups (16 warning-level).
Resolve the 9 Repeated repair finding(s) in Churn × Complexity Hotspots — start with lib.rs (2), ops.rs, fetch_test.ts. — One of this dimension's main actionable groups (9 warning-level).
Detailed fixes: d15_recommendation.md · top locations in Appendix A, every location in findings.md.
Do you agree with this assessment?
D16 · Bus Factor9.4 / 10Exemplary✓ Tool-verified
What it measures: Whether knowledge is concentrated in too few people (the "bus factor").
Method: Living knowledge per author via time-decayed commit attribution (6-month half-life, focus weighting) across largest source files. Deterministic, avoids blame's mechanical-refactor false positives.
50 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is ext/node/ops/wasi.rs. Counted over 796 of the 1141 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
Off-boarding risk: anonymized user #1 · ×4
Further sole-owners (lower concentration)
✓ On the Gold path — maintain.
Detailed fixes: d16_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Acknowledged debt left in the code — TODOs, dead code, suppressed warnings.
Method: Roslyn syntactic debt markers (suppressions/TODO/FIXME/HACK/empty-catch/commented-code/Obsolete) plus SymbolFinder dead-code analysis; weighted-debt-per-KLoC density deducted 2.0x per unit. Deterministic, exhaustive.
651 deducted task-comment markers across 628261 LoC (0.1/KLoC) → score 9.8. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
TodoComment repeated across 17 filesext/webgpu/bind_group.rs:66
What to do
Resolve the 606 TodoComment finding(s) in Explicit Debt — start with mod.rs (30), lib.rs (19), fs_test.ts (17). — One of this dimension's main actionable groups (606 warning-level).
Resolve the 23 FixmeComment finding(s) in Explicit Debt — start with serve_test.ts (5), http_test.ts (4), crypto_sign_test.ts (2). — One of this dimension's main actionable groups (23 warning-level).
Resolve the 2 XxxComment finding(s) in Explicit Debt — start with net.ts (2). — One of this dimension's main actionable groups (2 warning-level).
Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
Detailed fixes: d17_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether the project's documentation is clear, complete, and useful.
Method: Every README, docs/ document and root guide parsed by its markup and measured in Unicode letters. Published: a runnable or packaged .NET project whose README (or a document it links, or a root guide) shows no example, and a root README naming none of three or more projects. Overview, licence, boilerplate, wall-of-text, empty-section and XML-doc rows are measured and withheld (counted in gaps) after adjudication. Deterministic, exhaustive, advisory.
1 of 1 documentation facets pass in full. 87 document(s) read across 1 unit(s).
✓ On the Gold path — maintain.
Detailed fixes: d19_recommendation.md.
Do you agree with this assessment?
D20 · ADR Quality0.0 / 10Critical✓ Tool-verified
What it measures: Whether architecture decisions are recorded well (context, decision, consequences).
Method: Per-ADR judgment by language model at low temperature with two-pass stability; confidence is share of ADRs evaluated; enforcement-field presence detected deterministically. Advisory.
8 of 71 build units (Cargo, Deno) flagged as possibly oversized/incoherent.
Projects may be oversized for their cohesion
What to do
Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
Detailed fixes: d26_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Real static-analysis (SAST) findings — likely security bugs in the code, any language.
Method: Polyglot static analysis via semgrep across the repo using the pinned, image-baked p/security-audit + p/owasp-top-ten rulesets (no scan-time registry fetch); severity rules (ERROR/WARNING/INFO) map to a full-band severity-weighted score. Exhaustive, deterministic; degrades on parse failure.
Coverage: semgrep pattern rules over all files — exhaustive for the rule set, blind to classes of bug without a rule (clean = no rule matched).
44 finding(s): 0 critical, 24 high, 20 medium, 0 low. semgrep hit a parse error in 73 file(s) — `REDACTED`, `REDACTED`, `cli/lsp/diagnostics.rs` (line 1883), `cli/lsp/language_server.rs` (line 1426, line 3184), `cli/rt_desktop/lib.rs` (line 1047, line 1087, line 1099, …), … (+68 more) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. Separately, one or more rules could not re-parse an embedded snippet in 9 file(s) (e.g. a workflow `run:` block read as shell). Those files WERE scanned and their other rows are unaffected; only those rules' view of those snippets is missing.
REDACTED
REDACTED
REDACTED
REDACTED
REDACTED
+ 5 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 10 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (6), REDACTED (2), REDACTED. — One of this dimension's main actionable groups (10 issue-level).
Resolve the 9 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (8), REDACTED. — One of this dimension's main actionable groups (9 issue-level).
Resolve the 3 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (3 issue-level).
Detailed fixes: d29_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether any dependency has a known published vulnerability (CVE), direct or transitive, in ANY ecosystem the repository declares — Dart pub, Elixir and Erlang via Hex, Go modules, Java and Kotlin via Maven/Gradle, JavaScript/npm, .NET/NuGet, PHP/Composer, Python/PyPI, RubyGems, Rust/Cargo and Swift.
Method: Dependency-CVE scan across every ecosystem the repository declares, scored ONCE. Three sources are unioned and deduplicated by advisory identity (rule id + alias closure, CVE<->GHSA) scoped to package+version, keeping the worst severity: `osv-scanner --recursive` over osv.dev for Dart pub, Elixir/Hex (and Erlang, whose `rebar.lock` syft first converts to a CycloneDX SBOM the scanner reads, with rows attributed back to the lock), Go, Java and Kotlin via Maven/Gradle (and Scala, whose sbt build's pinned direct declarations are written into a CycloneDX SBOM the scanner reads, with rows attributed back to the build file), npm, PHP/Composer, Python/PyPI, RubyGems, Rust/Cargo and Swift; `trivy fs --scanners vuln` for npm lockfiles; and `dotnet list package --vulnerable --include-transitive` for NuGet (with per-advisory collapse of the project x target-framework fan-out), plus a DECLARED-dependency arm that resolves a published gem's gemspec against rubygems.org where no Gemfile.lock is committed. `SeverityScore(c,h,m,l, normalizer 8.0)`. NotApplicable only when NO ecosystem is readable; if any applicable ecosystem could not be scanned the findings are REPORTED and the score is withheld. Supersedes the npm and OSV arms, retired 2026-09-05.
+ 1 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 1 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
Resolve the 1 High vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
Resolve the 7 Medium vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED (7). — One of this dimension's main actionable groups (7 warning-level).
Detailed fixes: d30_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether anyone still has living knowledge of each file, or it has been orphaned — last understood long ago by someone now gone quiet. The sibling of the bus factor: D16 asks who owns it, D34 asks whether anyone still knows it.
Method: File orphaning as total living-knowledge decay below one focused-commit's worth within a year, computed per-file from the D16 decay model. Exhaustive, deterministic over fixed history.
35 of 796 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is ext/crypto/subtle_import_key.rs. Counted over 796 of the 1141 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
Resolve the 9 Orphaned knowledge finding(s) in Knowledge Freshness — start with subtle_import_key.rs, ts_server.rs, subtle_crypto.rs. — One of this dimension's main actionable groups (9 issue-level).
Resolve the 26 Orphaned file finding(s) in Knowledge Freshness — start with subtle_sign.rs, node_interop.rs, subtle_decrypt.rs. — One of this dimension's main actionable groups (26 recommendation-level).
Resolve the 1 Further orphaned files (smaller) finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
Detailed fixes: d34_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether files that change together actually belong together — pairs that repeatedly co-change in git history despite having no explicit code dependency, surfacing the hidden/logical coupling (and boundaries in the wrong place) a static scan can't see.
Method: Pairwise co-occurrence over the per-commit file sets in git history (production source only — tests and generated dropped): Degree-of-Coupling = shared ÷ min individual revisions, reported above noise floors (each file ≥10 revisions, ≥5 shared commits, ≥50% strength); sweeping commits excluded. Deterministic over fixed history.
Coverage: Population: PRODUCTION source files only — test and generated files are dropped before pairing, so a class co-changing with its own test (trivially ~100%) can't drown the real production↔production coupling. Pairs ranked by Degree-of-Coupling. A non-source file is never a coupling PARTICIPANT either: documentation, schemas, config and data files are dropped with the rest, so a code↔docs pair — a command and the reference page that restates it — is not reported however strongly the two co-change; nor is coupling that runs THROUGH a build step or config file.
Resolve the 5 Boundary-crossing change coupling finding(s) in Change Coupling — start with lib.rs (3), REDACTED, flags.rs. — One of this dimension's main actionable groups (5 issue-level).
Resolve the 25 Change coupling finding(s) in Change Coupling — start with fs.ts (2), lib.rs (2), module_info.rs (2). — One of this dimension's main actionable groups (25 warning-level).
Resolve the 2 Change-coupling hub finding(s) in Change Coupling — start with lib.rs, worker.rs. — One of this dimension's main actionable groups (2 warning-level).
Detailed fixes: d35_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether the build pipeline provides supply-chain integrity — generated provenance/attestation, signed artifacts (cosign/sigstore), an SBOM, and pinned build actions. Presence of the configuration, not a runtime guarantee.
Method: Supply-chain provenance/signing read deterministically from CI/build config (.github/workflows, .gitlab-ci.yml, azure-pipelines, Jenkinsfile, .circleci) + the release surface: four signals — generated provenance/attestation (SLSA/in-toto/actions-attest), artifact signing (cosign/sigstore/gitsign), an SBOM (syft/sbom-action/*.spdx.json/*.cdx.json), and SHA-pinned build actions — scored 10·present/denom. NotApplicable without a build pipeline. Detects configuration presence, not runtime enforcement.
+ 5 more group(s) — more in Appendix A; the complete list is findings.md.
What to do
Resolve the 8 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (8 warning-level).
Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
Detailed fixes: d36_recommendation.md · top locations in Appendix A, every location in findings.md.
What it measures: Whether the repository publishes a coordinated-vulnerability-disclosure policy (SECURITY.md or security.txt) with a reporting contact, so finders know how to report a vulnerability. Presence of a policy file with a contact, not whether the policy is adequate or honoured.
Method: Vulnerability-disclosure policy read deterministically from the repo: a SECURITY.md (root/.github/docs) or .well-known/security.txt / security.txt, regex-checked for a reporting contact (email / URL / mailto). Present + contact → 10; present without a contact → 4; NotApplicable when no policy file exists (it may live off-repo). Detects the policy file's presence + contact, not its adequacy.
What it measures: Whether any dependency the repository declares is published as MALICIOUS rather than merely vulnerable — a package that is an attacker's work, in any ecosystem osv-scanner reads. Scored apart from D30 because the answer is binary: there is no safe version to upgrade to, and the fix is to remove the package and rotate every credential it could have read.
Method: The same dependency scan D30 reads, partitioned on the scanner's own classification rather than rescanned: a row is MALICIOUS when its id is in the `MAL-` space (the ossf/malicious-packages feed) OR its `database_specific.cwe_ids` carries `CWE-506` ("Embedded Malicious Code"). Both channels are structural; the summary text is deliberately NOT read, because a malicious-package record whose summary says only "Critical severity vulnerability" is a real shape ([GHSA redacted]) and a text matcher misses it. Scored BINARY: any surviving row is 0, whatever its severity and however many CVEs sit beside it — a hostile dependency is not a quantity. Applicability and degradation are D30's: NotApplicable only when no ecosystem is readable, and an unscannable ecosystem degrades rather than reading clean. SCORED, not informational.
What it measures: Whether anyone still ships security patches for the platform this repository RUNS ON — the runtime it pins and the framework majors its own constraints hold it to. Separate from D12 because the question differs: a current Django on an end-of-life Python is perfectly up to date and completely unsupported, and the fix is a migration rather than a version bump. What the repository says it merely SUPPORTS is never charged.
Method: End-of-life PLATFORM read from the repository's own declarations and graded against a FROZEN, dated table of vendor support dates — no network, no feed, no API, so this dimension answers identically inside a closed scan fence. Two subjects: a RUNTIME the project pins (a single or all-end-of-life TargetFramework, a .nvmrc or .python-version, a requires-python CAP) and a FRAMEWORK major a dependency constraint cannot move off (a caret, tilde or exact version; `vue@^2.7.16` pins Vue 2). A FLOOR is deliberately never charged — `requires-python = ">=3.8"` states what a package SUPPORTS, not what it runs on — and a multi-target project is charged only when EVERY target is out of support. Runtime 4.0/product capped 8.0, framework 1.5 capped 4.5. The table is safe to freeze because a statement about support that ended in the past cannot become false: it loses recall as it ages, never precision, and a test asserts every entry predates the freeze date. Disjoint from D31 (a container image's OS layer) and D29 (the toolchain a CI workflow installs). Abstains when the repository declares no platform this pass reads — never scores it clean.
1 end-of-life runtime(s) and 0 end-of-life framework(s), read from 1 platform declaration(s) and 0 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Resolve the 1 End-of-life runtime finding(s) in Platform End-of-Life — start with rust-toolchain.toml. — One of this dimension's main actionable groups (1 warning-level).
Detailed fixes: d44_recommendation.md · top locations in Appendix A, every location in findings.md.
Other · Architecture — How the codebase splits by code ROLE — domain, application, infrastructure, test, generated. The significance map behind the knowledge/coupling weighting, and a DDD signal in its own right: a thin domain core under fat infrastructure is the anemic-domain smell, quantified. How each file's role is decided, because the split is only as good as that: a generated name or a build-output tree makes it Generated, a test project makes it Test, and otherwise the file's NAMESPACE and PATH words are matched against fixed vocabularies in a fixed ORDER — domain, then infrastructure, then application — so a file whose words hit two layers is counted under the earlier one. A production file matching none of them counts as application, so that share reads 'application or unclassified' rather than a measured application layer. Roles come from naming convention, never from what the code does. On this repository the split was taken from the source tree on disk rather than from a loaded .NET workspace, so a file's role is decided by its PATH segments alone — no declared namespace was available to add to the evidence — and generated output is excluded from the census entirely rather than counted as a generated share.
Method: Roslyn line-count by code ROLE: every source file classified Domain/Application/Infrastructure/Test/Generated by namespace + path convention (the shared CodeRoleClassifier), then significant lines summed per role. Deterministic; the advisory score is the business-logic (domain+application) share of production code.
Coverage: Population: ALL source files, each bucketed into ONE of five roles (Domain/Application/Infrastructure/Test/Generated) by namespace + path convention — a file whose layer isn't named in the convention falls to Application (the neutral default), and the split is line-count, not semantic depth or business value.
What to do
The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
Other · Architecture — Whether the project-reference graph is acyclic (cycles block independent build/deploy and signal eroding boundaries).
Method: Project reference cycles via elementary-DFS over real .csproj references, using the engine shared with D5/D7; cyclic versus acyclic. Exhaustive, deterministic.
The projects pkg-a → pkg-b → pkg-a form a reference cycle. Cyclic dependencies prevent independent build/test/deploy, blur ownership, and tend to grow into a big ball of mud. Break the cycle by extracting the shared types into a separate project both can reference. — tests/specs/npm/workspace_symlink_cyclic/packages/pkg-a/package.json:5
What to do
Break project reference cycles by extracting shared abstractions into a separate project; keep the graph a DAG.
Other · Architecture — Whether dependencies point inward (Domain ← Application ← Infrastructure/Web) — the clean-architecture dependency rule, checked across the project graph.
Method: Layer violations by name-segment inference (Domain/Core to Application to Infrastructure/Web) over the project-reference graph. Exhaustive over all projects, deterministic.
Other · Architecture — Whether interfaces stay focused rather than fat — the Interface-Segregation principle (SOLID 'I').
Method: Roslyn scan: public interface declared-member counts (accessors fold into their property/event); fat-interface threshold (over 15 declared members) flagged per type. Each finding also reports the distinct-OPERATION count — members counted by name, so an overload group counts once — which decides whether it states the caller-side ISP harm or the implementer-side burden of an overload set. TypeScript: exported interfaces that declare behaviour, counted over their REQUIRED operations (method signatures and function-typed properties with no `?`, once per signature) — data-shape interfaces and ambient .d.ts declarations are outside the population; JavaScript declares no interfaces and is not applicable. Deterministic, type-level.
Do you agree with this assessment?
AX8 · Test isolation10.0 / 10Exemplary✓ Tool-verified
Other · Architecture — Whether production projects stay free of references to test projects — tests may depend on production, never the reverse.
Method: Csproj graph: each production project checked for references to test projects (identified by test-framework presence, not name). Zero violations is clean. Deterministic.
Other · Architecture — Whether read (query) handlers stay side-effect-free — a query that writes persistent state or raises events breaks CQS and makes reads unsafe to retry, cache, or route to a read replica.
Method: Roslyn scan: CQRS handlers classified query-vs-command by interface (IQueryHandler/ICommandHandler/IRequestHandler<TQuery,TResult>) and name convention (*Query/Get*/Find* vs *Command); each query handler's body checked for persistent-state writes (SaveChanges/repository Add-Update) or event publishes by resolved invocation. Deterministic, type-level, exhaustive over the detected handlers.
Coverage: Population: CQRS handlers identified by IQueryHandler/ICommandHandler/IRequestHandler interface + *Query/Get*/Find*/*Command NAME convention; query purity then checked exhaustively within that set — a query handler using neither convention is invisible, and mutation is a resolved persistence/publish CALL, not full dataflow.
`SerializeDeserialize.get_shared_array_buffer_id` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — libs/core/ops_builtin_v8.rs:663
`SerializeDeserialize.get_wasm_module_transfer_id` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command. — libs/core/ops_builtin_v8.rs:691
What to do
Keep query handlers read-only — move the writes/event-publishes into a command handler so reads stay safe to retry, cache, and route to a read replica.
Do you agree with this assessment?
DM4 · Rich vs anemic domain model10.0 / 10Exemplary✓ Tool-verified
Other · Domain Modelling — Whether domain entities own their behaviour (invariant-enforcing commands) rather than being data-only structs driven by a foreign service.
Method: Roslyn (DDD-gated): entity method BODIES classified mutator-vs-query — only methods that mutate the entity's own declared state count as invariant-protecting behaviour, so a getter/passthrough doesn't rescue an anemic class. Deterministic, exhaustive over domain-layer entities.
Coverage: Population: entities by name/base convention; rich-vs-anemic judged by classifying each method body mutator-vs-query — logic-bearing domain types outside the convention are invisible.
Other · Domain Modelling — Whether a domain type's identity-bearing field stays immutable — a `pub` mutable field under a hand-rolled Hash/PartialEq breaks the value-identity invariant.
Method: Roslyn (DDD-gated): entities scanned for publicly writable state — public setters, and (C#/VB) own mutable collections handed out through an auto-property, a public field or a bare-field expression getter, where a computed/copying getter is never charged. One finding per entity; score softened when Marten/EF rehydration frameworks present. Deterministic, framework-aware.
Coverage: Population: entities by convention; encapsulation (setter shape) checked exhaustively within the set.
Other · Event Sourcing — Whether the recovery-replay fold is deterministic — state derived purely from each event's own fields, no clock/random/IO on the replay path.
Method: Roslyn syntax scan (event-sourcing gated): Apply/When folds checked for forbidden tokens (DateTime.Now, Guid.NewGuid, Random, IO), stripped of comments/strings. Deterministic, hard fact per fold.
Other · Event Sourcing — Whether domain events stay immutable (private fields, set once) rather than carrying mutable state.
Method: Roslyn scan (event-sourcing gated): persisted events checked for public setters; immutability verified per property/field. Deterministic, hard fact.
Other · Code Health — Unreviewed-generation residue: shipped members still throwing NotImplementedException, and placeholder string literals left in non-test, non-generated code. Scored as a quality signature, never as a claim about authorship.
Method: Roslyn syntax scan: NotImplementedException throws and placeholder string literals in non-test, non-generated shipped code. Deterministic, code-shape signature.
Maturity · Maturity — Whether the repo and its projects have a README, and whether it's substantive and current.
Method: Filesystem scan: README presence, word count, and headings for depth; git history for staleness. Exhaustive across root and project dirs, deterministic.
What to do
Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
Add a README to the 21 of 72 project(s) that lack one — worth up to 0.6 pts.
Maturity · Maturity — Whether key decisions (ADRs) and the high-level shape (C4/diagrams) are written down.
Method: Filesystem scan: ADR folder/naming conventions or content, plus Mermaid/PlantUML/C4/architecture.md discovery. Exhaustive, deterministic.
No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
What to do
Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
Maturity · Maturity — Whether the README actually describes the code that exists (LLM-judged, advisory).
Method: Judged by language model at low temperature: README accuracy versus actual projects, within a disclosed tolerance. Advisory, not a measured number.
Readiness · Readiness — Whether an automated pipeline builds and tests every change.
Method: Filesystem scan: CI workflow files (.github/workflows, .gitlab-ci.yml, etc.) for build and test stages. Exhaustive, deterministic.
Do you agree with this assessment?
P10 · Library API & versioning10.0 / 10Exemplary○ Nothing flagged
Readiness · Readiness — For a library: a deliberate (small) public API surface and explicit semantic versioning so consumers can depend on it safely.
Method: Roslyn scan: public API surface area and semantic-versioning markers (SemVer attributes, changelog entries) for libraries; off .NET, a library is the ecosystem's publication act (an npm package that is not private and names an entry point, a PyPI distribution with a build system, a Rust library crate, a Maven/Gradle module that publishes, a Go module with no package main, a gemspec, a Composer library, a SwiftPM library product, a pub.dev or Hex package), its surface is the share of types the language model records as public (Rust, Swift, Java, Kotlin, Go, Dart; not measured where the model records no type visibility or, as in TypeScript, only module-level export), and its version is read from the manifest, a semver CHANGELOG, release tooling or semver git tags. Exhaustive, deterministic.
Do you agree with this assessment?
P2 · Observability8.5 / 10Strong✓ Tool-verified
Readiness · Readiness — Whether the code is diagnosable in production — structured logging, tracing/metrics, health checks.
Only 28/33 runnable modules use logging (modules with no entry point or server are excluded — they are libraries a runnable module hosts). Silent: `.`, `ext/fetch`, `libs/dcore`, `libs/node_shim`, `libs/ops/compile_test_runner`.
What to do
Extend structured logging to the remaining runnable modules so everything you run is diagnosable in production.
Add a health-check endpoint (a /health route on your axum/actix router) so orchestrators and load balancers can probe liveness/readiness.
Readiness · Readiness — Whether SAST, secret/dependency scanning and performance benchmarking are wired in (presence, not runtime).
Method: Filesystem scan: SAST configuration, dependency-update automation, secret scanning, and a benchmark harness or benchmark step — in this repository's own ecosystem. Exhaustive, deterministic.
What to do
Your ecosystem's static analyzer is declared as a dependency but is not wired into CI — run it as a required step on push/PR (e.g. `composer phpstan` / `mix sobelow` / `bundle exec brakeman` / the spotbugs Gradle task / `sbt scalafixAll --check` / `golangci-lint run` / `rebar3 lint`) so a regression fails the build instead of relying on someone running it locally.
Enable Dependabot/Renovate or a dependency-review gate.
Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
Readiness · Readiness — Whether releases are automated and safely reversible (probes, rolling updates, approval gates) — from manifests/pipeline files, not the live environment.
Method: Filesystem scan: deployment manifests/IaC (K8s YAML, Helm, Terraform) for rolling updates, probes, approval gates, migration hooks. Exhaustive, deterministic.
Readiness · Performance — Whether asynchronous code stays responsive — it avoids sync-over-async blocking (a .NET .Wait()/.GetAwaiter().GetResult(), a time.sleep or blocking HTTP call inside a Python coroutine, a *Sync call inside an async JavaScript function, block_on inside a Rust async fn, runBlocking inside a Kotlin suspend function, block() inside a Reactor publisher) that stalls a thread or event loop and risks deadlock, and, where the code is a reusable library on .NET, awaits with ConfigureAwait(false) so it never captures and stalls its caller's context.
Method: Production-source scan: sync-over-async blocking counted everywhere — .Wait()/.GetAwaiter().GetResult() in .NET; off .NET, read from the language model, a blocking call inside an async function (Python, TS/JS, Rust, Kotlin, Swift, Dart) or inside a Java method returning a Reactor Mono/Flux or a Scala method returning a Future or effect — and, for a .NET library with ≥5 awaits, the share of awaits using ConfigureAwait(false). Deterministic, syntax/text detection.
`#cache.statSync` in `#iterateSubpatterns` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — ext/node/polyfills/_fs/_fs_glob.ts:1085, ext/node/polyfills/_fs/_fs_glob.ts:1101
`Deno.mkdirSync` in `removeDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:12
`Deno.statSync` in `removeDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:13
`Deno.statSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×8) — tests/unit/remove_test.ts:18, tests/unit/remove_test.ts:38, tests/unit/remove_test.ts:63, …
`Deno.writeFileSync` in `removeFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:32
`Deno.statSync` in `removeFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:33
`Deno.writeFileSync` in `removeFileByUrl` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:57
`Deno.statSync` in `removeFileByUrl` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:58
`Deno.mkdirSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — tests/unit/remove_test.ts:76, tests/unit/remove_test.ts:77
`Deno.statSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — tests/unit/remove_test.ts:78, tests/unit/remove_test.ts:80
`Deno.symlinkSync` in `removeDanglingSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — tests/unit/remove_test.ts:110, tests/unit/remove_test.ts:114
`Deno.lstatSync` in `removeDanglingSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:116
`Deno.lstatSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:120
`Deno.writeFileSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:135
`Deno.symlinkSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×2) — tests/unit/remove_test.ts:137, tests/unit/remove_test.ts:139
`Deno.statSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:141
`Deno.mkdirSync` in `removeAllDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×3) — tests/unit/remove_test.ts:166, tests/unit/remove_test.ts:181, tests/unit/remove_test.ts:182
`Deno.statSync` in `removeAllDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. (×3) — tests/unit/remove_test.ts:167, tests/unit/remove_test.ts:183, tests/unit/remove_test.ts:185
`Deno.writeFileSync` in `removeAllFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:205
`Deno.statSync` in `removeAllFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:206
`Deno.statSync` in `removeUnixSocketSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit/remove_test.ts:250
`existsSync` in `fn` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit_node/_fs/_fs_copy_test.ts:19
`cpSync` in `Deno.test("[std/node/fs] cp creates destination directory")` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit_node/_fs/_fs_copy_test.ts:61
`existsSync` in `Deno.test("[std/node/fs] cp creates destination directory")` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs. — tests/unit_node/_fs/_fs_copy_test.ts:62
What to do
TypeScript/JavaScript: use the promise APIs (fs/promises, a promisified child_process.execFile, the async zlib/crypto functions) and await them instead of the *Sync variants.
Do you agree with this assessment?
R1 · Type Safety4.4 / 10Weak✓ Tool-verified
React / JS · Code Health — How much of the frontend is typed TypeScript vs untyped JavaScript.
Method: Frontend file inventory: the share of typed TypeScript vs untyped JavaScript across the source tree. Deterministic, exhaustive over frontend files.
392 typed · 500 plain JS — the untyped files are cli/js/40_jupyter.js, REDACTED, REDACTED, cli/js/40_test.js, cli/js/40_test_common.js, cli/js/40_test_snapshot.js (+494 more). 0 production file(s) opt out entirely with @ts-nocheck · 15 @ts-ignore suppression(s).
What to do
Migrate the remaining .js/.jsx files to TypeScript.
React / JS · Code Health — Near-exact copy-pasted blocks of substantial extent across the frontend (the D4 clone algorithm over JS/TS tokens, D-386): a block is reported only where its copies still agree on most of their own identifiers and literals, or were renamed as they were pasted but kept most of their constants, and where the copies carry enough code to stand on their own or the copied extent reaches 30 lines — so a re-implementation sharing neither names nor values, and a small pasted declaration, are both found and deliberately not reported, and a clean R10 is not a claim that nothing was copied.
Method: Near-exact copy-pasted blocks of substantial extent across the frontend (the D4 clone algorithm run over JS/TS tokens). Masking finds the candidates; a block is reported when its copies still agree on most of their own identifiers and literals, or when a renamed copy still agrees on most of its constants, AND the copies carry enough code to stand on their own — or when the copied extent reaches 30 lines. So a re-implementation sharing neither names nor values, and a small pasted declaration, are deliberately not counted. Deterministic.
48 duplicated blocks under ext/ have copies in at least two of the sibling directories cache, fetch, fs, http, image, io (+8 more sibling(s) not listed) — 17 of them are reported below, and 31 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 48 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 48 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 48 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on. — ext/fetch/26_fetch.js:194
13 duplicated blocks under the repository root have copies in at least two of the sibling directories ext, libs, runtime — 5 of them are reported below, and 8 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 13 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 13 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 13 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on. — ext/node/polyfills/worker_threads.ts:636
10 duplicated blocks under ext/node/polyfills/internal/ have copies in at least two of the sibling directories console, crypto, dns, fs, http2, readline (+2 more sibling(s) not listed) — 1 of them are reported below, and 9 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 10 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 10 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 10 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on. — ext/node/polyfills/internal/console/constructor.mjs:764
9 duplicated blocks under ext/node/polyfills/ have copies in at least two of the sibling directories _fs, _process, fs, inspector, internal, internal_binding (+2 more sibling(s) not listed) — 5 of them are reported below, and 4 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 9 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 9 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 9 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on. — ext/node/polyfills/internal/util/types.ts:136
ext/node/polyfills/path/_posix.ts:183 · ext/node/polyfills/path/_win32.ts:655 — the two spans are one implementation copied and then locally edited — 1307 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/path/_posix.ts:183
ext/node/polyfills/internal/crypto/cipher.ts:182 · ext/node/polyfills/internal/crypto/cipher.ts:493 — the two spans are one implementation copied and then locally edited — 1065 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/crypto/cipher.ts:182
tools/startup_order/generate_linux_function_orderfile.ts:402 · tools/startup_order/generate_macos_function_orderfile.ts:282 — the two spans are one implementation copied and then locally edited — 808 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — tools/startup_order/generate_linux_function_orderfile.ts:402
ext/node/polyfills/internal/errors.ts:3361 · ext/node/polyfills/internal/errors.ts:3684 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/internal/errors.ts:3361
ext/web/12_location.js:22 · ext/web/12_location.js:228 — the two spans are one implementation copied and then locally edited — 393 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/web/12_location.js:22
ext/node/polyfills/worker_threads.ts:636 · runtime/js/11_workers.js:222 — the two spans are one implementation copied and then locally edited — 491 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/worker_threads.ts:636
ext/node/polyfills/internal/streams/readable.js:257 · ext/node/polyfills/internal/streams/writable.js:251 — the two spans are one implementation copied and then locally edited — 551 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/streams/readable.js:257
ext/node/polyfills/internal/crypto/sig.ts:350 · ext/node/polyfills/internal/crypto/sig.ts:470 — the two spans are one implementation copied and then locally edited — 464 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/crypto/sig.ts:350
tools/startup_order/generate_linux_function_orderfile.ts:154 · tools/startup_order/generate_macos_function_orderfile.ts:126 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — tools/startup_order/generate_linux_function_orderfile.ts:154
ext/node/polyfills/internal/errors.ts:3475 · ext/node/polyfills/internal/errors.ts:3796 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/internal/errors.ts:3475
ext/node/polyfills/internal/webstreams/adapters.js:129 · ext/node/polyfills/internal/webstreams/adapters.js:272 — the two spans are one implementation copied and then locally edited — 346 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/webstreams/adapters.js:129
ext/node/polyfills/internal/streams/readable.js:136 · ext/node/polyfills/internal/streams/writable.js:146 — the two spans are one implementation copied and then locally edited — 453 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/streams/readable.js:136
ext/fetch/26_fetch.js:194 · REDACTED:146 — the two spans are one implementation copied and then locally edited — 435 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/fetch/26_fetch.js:194
ext/node/polyfills/internal/streams/compose.js:94 · ext/node/polyfills/internal/streams/duplexify.js:290 — the two spans are one implementation copied and then locally edited — 318 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/internal/streams/compose.js:94
ext/node/polyfills/crypto.ts:495 · ext/node/polyfills/crypto_esm.ts:6 — the 2 copies are spread across 2 files, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/crypto.ts:495
ext/node/polyfills/timers.ts:53 · ext/node/polyfills/timers.ts:160 — the two spans are one implementation copied and then locally edited — 358 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/node/polyfills/timers.ts:53
ext/node/polyfills/_fs/_fs_constants.ts:9 · ext/node/polyfills/_fs/_fs_constants.ts:69 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/_fs/_fs_constants.ts:9
ext/node/polyfills/internal_binding/udp_wrap.ts:169 · ext/node/polyfills/internal_binding/udp_wrap.ts:300 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/internal_binding/udp_wrap.ts:169
ext/fetch/20_headers.js:549 · ext/fetch/21_formdata.js:188 — the two spans are one implementation copied and then locally edited — 323 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — ext/fetch/20_headers.js:549
ext/node/polyfills/internal/buffer.mjs:1060 · ext/node/polyfills/internal/buffer.mjs:1125 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/internal/buffer.mjs:1060
runtime/js/98_global_scope_window.js:9 · runtime/js/98_global_scope_worker.js:9 — the two spans are one implementation copied and then locally edited — 221 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — runtime/js/98_global_scope_window.js:9
REDACTED:948 · REDACTED:1005 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — REDACTED:948
ext/node/polyfills/_http_agent.js:78 · ext/node/polyfills/net.ts:337 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/_http_agent.js:78
ext/web/14_compression.js:59 · ext/web/14_compression.js:121 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/web/14_compression.js:59
tools/lint.js:100 · tools/lint.js:179 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — tools/lint.js:100
ext/node/polyfills/dns.ts:1061 · ext/node/polyfills/dns.ts:1114 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/dns.ts:1061
runtime/js/98_global_scope_window.js:165 · runtime/js/98_global_scope_worker.js:147 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — runtime/js/98_global_scope_window.js:165
ext/node/polyfills/internal/constants.ts:58 · ext/node/polyfills/internal/constants.ts:107 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/internal/constants.ts:58
ext/web/06_streams.js:5904 · ext/web/06_streams.js:5961 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — ext/web/06_streams.js:5904
ext/web/06_streams.js:1654 · ext/web/06_streams.js:2144 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — ext/web/06_streams.js:1654
ext/node/polyfills/internal/crypto/keygen.ts:221 · ext/node/polyfills/internal/crypto/keys.ts:535 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/internal/crypto/keygen.ts:221
ext/node/polyfills/internal/errors.ts:3612 · ext/node/polyfills/internal/errors.ts:3926 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/internal/errors.ts:3612
ext/node/polyfills/_fs/_fs_glob.ts:701 · ext/node/polyfills/_fs/_fs_glob.ts:973 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/_fs/_fs_glob.ts:701
ext/node/polyfills/internal/util/types.ts:136 · ext/node/polyfills/util/types.ts:6 — the 2 copies are spread across 2 files, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents. — ext/node/polyfills/internal/util/types.ts:136
ext/node/polyfills/_fs/_fs_glob.ts:758 · ext/node/polyfills/_fs/_fs_glob.ts:1034 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/_fs/_fs_glob.ts:758
ext/node/polyfills/inspector.js:59 · ext/node/polyfills/inspector_network_bridge.js:19 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — ext/node/polyfills/inspector.js:59
What to do
Act on each finding's own remediation rather than one rule: the move depends on what recurs. Where the copies are executable blocks, give the shared part one home and call it from each site; where they are declarations, a listing, a specialisation already delegating to its base, or one shape repeated per entity, there is no call site and the move is a shared type, a generated set or a factory — sometimes there is nothing to extract.
React / JS · Code Health — Per-function cyclomatic/cognitive complexity from the token-level function scanner (D-386) — real branching, not a regex heuristic.
Method: Per-function cyclomatic/cognitive complexity from a token-level function scanner (real branching, not a regex heuristic), computed over every frontend function. Deterministic.
resolveObject has cyclomatic complexity 117 and cognitive complexity 168; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/url.ts:262
emitKeys has cyclomatic complexity 112 and cognitive complexity 77; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/readline/utils.mjs:121
#iterateSubpatterns has cyclomatic complexity 106 and cognitive complexity 283; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/_fs/_fs_glob.ts:880
urlParse has cyclomatic complexity 106 and cognitive complexity 141; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/url.ts:666
objectComparisonStart has cyclomatic complexity 91 and cognitive complexity 109; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/util/comparisons.ts:302
matchKnownFields has cyclomatic complexity 90 and cognitive complexity 113; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/_http_incoming.js:259
ClientRequest has cyclomatic complexity 86 and cognitive complexity 125; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:505
#addSubpatterns has cyclomatic complexity 82 and cognitive complexity 151; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/_fs/_fs_glob.ts:618
(computed) has cyclomatic complexity 71 and cognitive complexity 61; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/readline/interface.mjs:1093
constructor has cyclomatic complexity 61 and cognitive complexity 111; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/worker_threads.ts:291
createJob has cyclomatic complexity 60 and cognitive complexity 102; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/crypto/keygen.ts:390
_load has cyclomatic complexity 59 and cognitive complexity 104; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/01_require.js:1412
mainFetch has cyclomatic complexity 59 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/fetch/26_fetch.js:386
#spawnInternal has cyclomatic complexity 59 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/child_process.ts:369
_resolveFilename has cyclomatic complexity 52 and cognitive complexity 87; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/01_require.js:1657
normalize has cyclomatic complexity 48 and cognitive complexity 92; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/path/_win32.ts:275
pipelineImpl has cyclomatic complexity 48 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/internal/streams/pipeline.js:210
resolve has cyclomatic complexity 47 and cognitive complexity 108; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — ext/node/polyfills/path/_win32.ts:91
What to do
Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.
Do you agree with this assessment?
R3 · Large Files0.0 / 10Critical✓ Tool-verified
React / JS · Code Health — How many source files exceed the large-file threshold.
Method: Components/modules exceeding the large-file threshold, counted exhaustively across the frontend source tree. Deterministic.
ext/web/06_streams.js has 8052 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/web/06_streams.js:1
ext/node/polyfills/http2.ts has 5055 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/http2.ts:1
ext/node/polyfills/internal/errors.ts has 3783 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/errors.ts:1
ext/node/polyfills/fs.ts has 3740 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/fs.ts:1
ext/node/polyfills/testing.ts has 3321 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/testing.ts:1
ext/node/polyfills/01_require.js has 3230 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/01_require.js:1
ext/node/polyfills/internal/buffer.mjs has 3114 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/buffer.mjs:1
ext/node/polyfills/net.ts has 2947 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/net.ts:1
ext/node/polyfills/internal/child_process.ts has 2799 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/child_process.ts:1
ext/node/polyfills/worker_threads.ts has 2201 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/worker_threads.ts:1
ext/node/polyfills/repl.ts has 1930 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/repl.ts:1
ext/node/polyfills/process.ts has 1896 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/process.ts:1
REDACTED has 1779 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
ext/node/polyfills/_tls_wrap.js has 1760 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/_tls_wrap.js:1
ext/node/polyfills/internal/streams/readable.js has 1666 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/streams/readable.js:1
REDACTED has 1627 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
ext/node/polyfills/_http_outgoing.ts has 1610 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/_http_outgoing.ts:1
ext/node/polyfills/url.ts has 1597 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/url.ts:1
ext/node/polyfills/internal/crypto/diffiehellman.ts has 1592 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/crypto/diffiehellman.ts:1
ext/webidl/00_webidl.js has 1553 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/webidl/00_webidl.js:1
ext/web/02_event.js has 1515 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/web/02_event.js:1
REDACTED has 1510 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
ext/node/polyfills/dgram.ts has 1460 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/dgram.ts:1
REDACTED has 1409 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
runtime/js/99_main.js has 1304 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — runtime/js/99_main.js:1
ext/node/polyfills/internal/readline/interface.mjs has 1282 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/readline/interface.mjs:1
ext/node/polyfills/internal/util/comparisons.ts has 1282 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/util/comparisons.ts:1
ext/node/polyfills/zlib.js has 1241 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/zlib.js:1
libs/core/01_core.js has 1230 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — libs/core/01_core.js:1
ext/node/polyfills/_fs/_fs_glob.ts has 1202 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/_fs/_fs_glob.ts:1
ext/node/polyfills/_events.mjs has 1198 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/_events.mjs:1
ext/web/00_url.js has 1169 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/web/00_url.js:1
ext/node/polyfills/internal/fs/utils.mjs has 1133 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/fs/utils.mjs:1
ext/node/polyfills/path/_win32.ts has 1132 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/path/_win32.ts:1
cli/js/jupyter_kernel.js has 1120 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — cli/js/jupyter_kernel.js:1
ext/node/polyfills/internal/streams/writable.js has 1118 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/internal/streams/writable.js:1
ext/web/13_message_port.js has 1108 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/web/13_message_port.js:1
ext/node/polyfills/dns.ts has 1080 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/node/polyfills/dns.ts:1
REDACTED has 1072 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
ext/fetch/26_fetch.js has 1059 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — ext/fetch/26_fetch.js:1
What to do
Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package.
Do you agree with this assessment?
R4 · Test Coverage0.4 / 10Critical✓ Tool-verified
React / JS · Readiness — Static test reachability (D-386): the share of production files reachable from any test via the import graph — measured without running anything.
Method: Static test reachability: the share of production files reachable from any test via the import graph — measured without running anything. Deterministic.
tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6 imports './index.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6
tests/registry/npm/@denotest/lifecycle-scripts-simple/1.0.0/main.js:2 imports './message.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/registry/npm/@denotest/lifecycle-scripts-simple/1.0.0/main.js:2
tests/registry/npm/@denotest/node-addon-implicit-node-gyp/1.0.0/index.js:1 imports './build/Release/node_addon', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/registry/npm/@denotest/node-addon-implicit-node-gyp/1.0.0/index.js:1
tests/registry/npm/@denotest/node-addon/1.0.0/index.js:1 imports './build/Release/node_addon', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/registry/npm/@denotest/node-addon/1.0.0/index.js:1
tests/specs/npm/node_modules_import/main.ts:2 imports './node_modules/@denotest/esm-basic/main.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/specs/npm/node_modules_import/main.ts:2
tests/specs/npm/node_modules_import_auto/main.ts:2 imports './node_modules/@denotest/esm-basic/main.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/specs/npm/node_modules_import_auto/main.ts:2
tests/specs/npm/workspace_sub_deno_json/member/main.ts:3 imports '../node_modules', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/specs/npm/workspace_sub_deno_json/member/main.ts:3
tests/specs/npm/workspace_sub_deno_json/member_with_deno_json/main.ts:3 imports '../node_modules', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/specs/npm/workspace_sub_deno_json/member_with_deno_json/main.ts:3
tests/specs/run/import_common_js/require_error.js:2 imports './a', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/specs/run/import_common_js/require_error.js:2
tests/testdata/check/import_non_existent.ts:1 imports './non-existent-module.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/check/import_non_existent.ts:1
tests/testdata/check/module_detection_force.ts:2 imports './module_detection_force/import.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/check/module_detection_force.ts:2
tests/testdata/dynamic_import/b.js:1 imports './bad.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/dynamic_import/b.js:1
tests/testdata/dynamic_import/c.js:1 imports './bad2.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/dynamic_import/c.js:1
tests/testdata/import_maps/test.ts:6 imports './scope/scoped.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/import_maps/test.ts:6
tests/testdata/info/error_009_missing_js_module.js:1 imports './bad-module.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/info/error_009_missing_js_module.js:1
tests/testdata/module_graph/file_tests-a.mjs:1 imports './b.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/module_graph/file_tests-a.mjs:1
tests/testdata/module_graph/file_tests-diag.ts:1 imports './c/mod.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/module_graph/file_tests-diag.ts:1
tests/testdata/module_graph/https_deno.land-x-a-mod.ts:1 imports '../b/mod.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/module_graph/https_deno.land-x-a-mod.ts:1
tests/testdata/module_graph/https_deno.land-x-lib-mod.d.ts:2 imports './b.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either (1 further unresolvable import(s) in the same file). The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/module_graph/https_deno.land-x-lib-mod.d.ts:2
tests/testdata/module_graph/https_deno.land-x-lib-mod.js:2 imports './b.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either (1 further unresolvable import(s) in the same file). The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/module_graph/https_deno.land-x-lib-mod.js:2
tests/testdata/run/permissions_prompt_allow_all_2.ts:8 imports '../', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/run/permissions_prompt_allow_all_2.ts:8
tests/testdata/run/top_level_await/tla3/b.js:2 imports '../circular.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/run/top_level_await/tla3/b.js:2
tests/testdata/tsc2/file_reexports.ts:1 imports './exportc.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/tsc2/file_reexports.ts:1
tests/testdata/tsc2/https_deno.land-x-a.ts:1 imports './b.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing. — tests/testdata/tsc2/https_deno.land-x-a.ts:1
No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one. (×16) — ext/web/06_streams.js:1, ext/node/polyfills/http2.ts:1, ext/node/polyfills/internal/errors.ts:1, …
What to do
Add tests that import the unreached modules (directly or through their public entry).
React / JS · Readiness — How outdated the npm dependencies are (a maturity signal). JS/npm CVEs are scored separately in D30 (JS/npm Dependency Vulnerabilities).
Method: npm dependency staleness from manifest/registry metadata (a maturity signal; JS/npm CVEs are scored separately in D30, which answers dependency vulnerabilities for every ecosystem). Deterministic.
Do you agree with this assessment?
R6 · Tooling10.0 / 10Exemplary✓ Tool-verified
React / JS · Readiness — Whether the project wires up test, lint and typecheck — detected from each package.json script's COMMAND (eslint / tsc / vitest / jest / playwright), not just its name, and corroborated against CI-workflow invocations so a tool run only in CI still counts.
Method: package.json scanned for test/lint/typecheck script wiring. Deterministic presence check.
This repository declares test tooling, and the ✓ above records that declaration — but tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js and 23 other test file(s) in this workspace cannot be loaded at all: it imports a module that names no file in this repository, so the runner throws while collecting it and none of its cases execute. The wiring is present and the suite it points at does not run as written, which is why the tooling tick must not be read as a statement that the tests pass. Fix the unloadable file(s) — each one is reported with its failing import under Test Coverage — then the declared script exercises what it claims to. — tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6
Do you agree with this assessment?
R7 · Dead Code8.2 / 10Strong✓ Tool-verified
React / JS · Code Health — Files unreachable from every application/tooling/test entry point, and exports nothing imports (module-graph reachability, D-386).
Method: Dead code: files unreachable from every application/tooling/test entry point plus exports nothing imports, via module-graph reachability. Deterministic, exhaustive over the import graph.
1 file(s) (~1 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package. — tests/registry/npm/@denotest/cjs-require-esm/1.0.0/esm
Unreachable from the 908 application, 329 tooling and 1242 test entry point(s) detected in this repo. Gate removals on `npm run build` — an undetected custom entry would make these reachable.
no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make (×35) — ext/node/polyfills/internal/streams/pipeline.js, ext/node/polyfills/internal/streams/operators.js, ext/node/polyfills/internal/streams/compose.js, …
no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), but 1 in-repo import(s) from 1 other file(s) do name it (libs/core_testing/integration/ts_types/ts_types.ts) — every one of those referrers is itself unreachable, so this file is dead only as a member of that cluster: if any referrer is in fact alive, this row falls with it (×2) — libs/core_testing/integration/ts_types/which.ts, libs/core_testing/integration/ts_types/decorator.ts
no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), but 2 in-repo import(s) from 1 other file(s) do name it (libs/core_testing/integration/wasm_imports/import_from_wasm.mjs) — every one of those referrers is itself unreachable, so this file is dead only as a member of that cluster: if any referrer is in fact alive, this row falls with it — libs/core_testing/integration/wasm_imports/lib.mjs
What to do
Delete the dead files and unused exports — every line is maintenance cost and rebuild-estimate inflation with zero runtime value.
React / JS · Readiness — npm dependency truthfulness (D-386): unused dependencies, imports not declared anywhere, and type-/test-only packages shipped as production deps.
Method: npm dependency truthfulness: unused dependencies, imports declared nowhere, and type-/test-only packages shipped as production deps — from the manifest + import graph. Deterministic.
Imported but not declared in any reachable package.json — installs work only by hoisting accident. (×3) — tests/wpt/wpt.ts:43, tests/registry/npm/@denotest/require-added-nm-folder/1.0.0/index.js:2, tests/registry/npm/@denotest/require-non-existent/1.0.0/index.cjs:2
Imported only as a TYPE and declared in no reachable package.json. The import is erased at compile time, so nothing is installed and no runtime resolution depends on it — but type-checking a clean clone will fail. Declare the typings it resolves through (or the package itself) in the owning package.json. — cli/tsc/dts/node/process.d.cts:112
Declared in tests/registry/npm/@denotest/file-dep/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
Declared in tests/registry/npm/@denotest/mjs-reexport-cjs/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
Declared in tests/registry/npm/@denotest/non-existent-dep/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
What to do
Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies.
React / JS · Architecture — Import cycles in the module graph (D-386) — files that can only be understood and changed together.
Method: Import cycles in the module graph, detected exhaustively over JS/TS imports (the same cycle detection as the .NET coupling dimension). Deterministic.
Other · Code Health — Whether any branch is dead by construction — a switch arm whose label can never equal a case-normalised subject, or an `else if` whose predicate the arm above has already swallowed.
Method: Roslyn syntax + semantics: switch labels compared against the subject's own case normaliser, and if/else-if chains checked for a literal an earlier arm's containment test already swallows. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X13 · Undrained process stream10.0 / 10Exemplary○ Nothing flagged
Other · Code Health — Whether a child process that has BOTH standard streams redirected drains both — reading one to the end while the other is never read deadlocks once the child fills the unread pipe.
Method: Roslyn syntax + semantics: ProcessStartInfo launches with both streams redirected, checked for a drain of each stream across the enclosing type. On a repository with no .NET source it reads JavaScript/TypeScript off the engine’s own token stream (test, vendored and minified paths not) with the same rule: a `spawn` imported from `child_process` whose stdout and stderr are both pipes (no options, no `stdio`, or `stdio` of `'pipe'`), bound to a local that never leaves its scope, where exactly one of the two streams is read, the other never, and the child’s `close`/`exit` (or the read stream’s end) is awaited; a shell redirect in the call’s arguments or a `kill` of the child suppresses it. The same rule reads Python’s `subprocess.Popen`, Dart’s `Process.start`, Ruby’s `Open3.popen3`, and Scala’s JDK process starts (`new ProcessBuilder(…).start()` with no `redirectErrorStream`/`redirectError`/`redirectOutput`/`inheritIO`, `Runtime.getRuntime.exec`) where one of `getInputStream`/`getErrorStream` is read and the other never while `waitFor()` is called or the read stream is read to its end. Deterministic, provable per finding. Advisory.
Other · Security — Whether a hand-rolled public/private IP check can be walked past — a method that unwraps IPv4-mapped IPv6 but returns the opposite verdict for the same host written as IPv4-compatible, 6to4 or NAT64.
Method: Roslyn syntax + semantics: methods that unwrap IPv4-mapped IPv6 and hand-roll IPv4 range carve-outs, checked for whether the IPv6 branch also accounts for the IPv4-compatible, 6to4 and NAT64 embeddings. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X15 · Unvalidated length from an untrusted reader10.0 / 10Exemplary○ Nothing flagged
Other · Security — Whether a length read out of the stream being parsed is bounded before it is allocated or read — an unchecked count taken from the input lets the input choose the allocation.
Method: Roslyn syntax + semantics: integer lengths read from a BinaryReader and spent on a bulk read or an array allocation, checked for any comparison or bounding call on the value anywhere in the method. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a loop that shortens a string until it fits a length budget has a floor — one with none grinds the value down to the empty string, or past it into a negative-length `Substring`.
Method: Roslyn syntax + semantics: while/do loops whose body's only effect on a string is to drop its last character, checked for whether anything — a direct comparison on the length, a body guard, a break — bounds that length below. On a repository with no .NET source it reads JavaScript/TypeScript off the engine’s own token stream (test, vendored and minified paths not) with the same rule: a `while`/`do` loop whose body’s one assignment to a value is `x = x.slice(0, -1)` or `x = x.slice|substring|substr(0, x.length - 1)`, driven by a condition that reads `x.length` only as a term of a larger expression — never compared directly, never tested for truthiness, and with no other read of `x` — and whose body has no `break`, `return`, `throw` or `if` naming `x`. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X17 · Uncapped recursion over a caller-supplied document10.0 / 10Exemplary○ Nothing flagged
Other · Security — Whether a walk that recurses through a JSON/XML tree handed in by its caller bounds how deep it will go — an uncapped walk lets the document's nesting choose the stack depth, and the resulting StackOverflowException cannot be caught.
Method: Roslyn syntax + semantics: methods that take a JSON/XML document node and call themselves with a child of it, reachable from an externally-callable member of the same type that accepts a document, checked for any depth parameter, descent counter or threaded arithmetic anywhere in the walk. On a repository with no .NET source it reads TypeScript off the engine’s own token stream (test, vendored, generated and minified paths and `.d.ts` not) with the same rule: a function or method with a parameter typed as a document value — `unknown`, `any`, `object`, `Record<string, unknown|any>`, a JSON alias (`JsonValue`, `JSONObject`, …) or a DOM node global the file does not rebind — that calls itself (bare, or through `this` for a method, or hands itself to a call over the value as in `value.map(walk)`) with something it took out of that value and never through an ancestor accessor such as `closest()` or `parentElement`, that is exported or reached from an exported function (a public method of the same exported class) taking such a value, and that names no depth, level, nesting, recursion, remaining or budget anywhere and threads no `+`/`-` arithmetic through a self-call. Plain JavaScript is not read: with no annotation nothing tells a parsed document from a tree the code built itself. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a type's disposal matches what it OWNS — releasing what it created, leaving alone what it was handed, and not declaring a finalizer for state that has nothing unmanaged to finalize.
Method: Roslyn syntax + semantics: every assignment to a disposable field is read to decide whether the type CREATED the value or was handed it, and the type's disposal is checked against that answer — an injected interface it disposes, a value it constructed and never releases, a finalizer on a type holding nothing unmanaged, and a disposable local whose every reference is a plain member read. A value handed to a container that disposes its contents (a parent control's `Controls` collection, a component `IContainer`) is released by that container and is not reported; generated code is out of population. On a repository with no .NET source the same ownership questions are read in JavaScript/TypeScript off the engine’s own token stream (test, vendored, generated and minified paths not): a class declaring `dispose()`, `[Symbol.dispose]()` or `[Symbol.asyncDispose]()` that disposes a field it was handed through a constructor parameter typed as a repository interface or resolved by a dependency-injection container; that assigns a field only ever from `new X(…)` of a disposable class and neither releases it anywhere in the class nor names it in its disposal member or a method that member calls, nor hands it to anything else; and a `const`/`let` local built from literals only whose every reference opens a statement operating on a non-release member of it. A class is disposable when every repository declaration of its name declares or inherits a disposal member, or when it is a documented library disposable (`vscode` EventEmitter, CancellationTokenSource and Disposable; three.js geometries, materials, textures, render targets, renderers, controls and composers). The finalizer arm has no JavaScript counterpart: a class cannot declare one. Dart is read for the owned-and-never-released arm: a Flutter `State` (or a class declaring `dispose()`/`close()`) whose library-private field is written only with direct creations of a framework controller, `FocusNode`, `StreamController` or periodic `Timer` (or a `.listen(…)` into a field declared `StreamSubscription`), which nothing in the class or its library releases (`dispose`/`close`/`cancel`) and which is never handed on except as a named argument. Ruby is read for the owned-and-never-released arm and the abandoned-local arm: a class declaring an instance `close`, `dispose`, `shutdown`, `stop`, `disconnect` or `terminate` whose instance variable is written only with a blockless core descriptor creation (`File.open`/`new`, `Tempfile`, `Dir.open`, `IO.popen`, the `socket` and `openssl` socket classes) that no method of the class closes and that is never handed on (passed, returned, stored, exposed by `attr_reader`, delegated) — a class whose superclass or mixin lies outside the repository is not judged — and a blockless creation read through and dropped (`File.open(path).read`) or held in a local that is never closed, returned, passed or stored (a `&:read` block-pass, an `autoclose: false` borrow and a `fileno` hand-over are not abandonment). PHP is read for the same two arms: a class (not a trait, and not one using a trait) declaring an instance `close`, `dispose`, `shutdown`, `stop`, `disconnect` or `terminate` whose `private` property (or a `final` class's `protected` one) is written only with a direct core `fopen`, `tmpfile`, `popen`, `proc_open`, `fsockopen`, `stream_socket_client`/`server` or `opendir` that nothing in the class closes (`fclose`, `pclose`, `closedir`, `unset`, a reset to `null`) and that is never handed on, and a handle held in a function's local, or read through as the argument of a reader, that is never closed, returned, passed, captured or stored; a `php://` stream, `curl_init`, `SplFileObject`, `PDO` and a function the repository declares under the core name are not read. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a method that temporarily changes state belonging to the whole process — the working directory, an environment variable — puts it back on EVERY path: a restore reached only when nothing throws leaks the change to the rest of the process.
Method: Roslyn syntax + semantics: method bodies that write the process working directory or an environment variable and write it back in the same body, checked for whether that restore sits in a `finally`/`catch` or only on the straight-line path. On a repository with no .NET source the same rule reads production JavaScript/TypeScript off the engine’s own token stream (test, vendored and minified paths not): `process.chdir`, `process.env.NAME =`/`["NAME"] =` and `delete process.env.NAME`, and Deno’s `Deno.chdir`/`Deno.env.set`/`Deno.env.delete`, paired per function body (a nested function or arrow is its own body, and module top-level code is none), where the last write puts back a local the body captured from the same global or deletes a variable the first write set, with at least one statement between them; a write in a `catch`/`finally` of that body silences it. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether an argument guard throws the exception its own condition describes — a guard that rejects a value for being EMPTY and reports it as `ArgumentNullException` tells the caller a parameter was null when it provably was not.
Method: Roslyn syntax: `throw new ArgumentNullException(nameof(p))` statements controlled by an `if`, whose condition is read for a test that is true of a NON-null `p` — an emptiness test that dereferences it (`p.Count == 0`, `!p.Any()`) or a BCL predicate documented true of the empty value (`string.IsNullOrEmpty(p)`). Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a `when` guard is free of side effects — a guard that increments a counter or assigns while deciding whether its arm matches applies that change during PATTERN MATCHING, on an arm that may not be selected, and skips it entirely when a short-circuit to its left answers first.
Method: Roslyn syntax: `when` guards on case labels and switch-expression arms, read for a mutation (`++`/`--`/assignment) sitting in a position the guard's own `&&`/`||`/`??`/`?:`/`?.` can skip. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a method that TAKES a lock or semaphore and gives it back from a flag-guarded `finally` returns the value that flag implies — reporting success while the guard hands the primitive back admits a second caller the exclusion was there to keep out, and reporting failure while the guard keeps it leaves nothing to ever give it back.
Method: Roslyn syntax: `try` statements whose `finally` releases a synchronisation primitive under a bare local-bool guard, where the method also TOOK that same primitive before the `try`, checked for a `return` of a bool literal whose value disagrees with the flag state the method's own straight-line assignments put it in. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether the work a diagnostic log line costs is paid only when that line is wanted — C# evaluates a call's arguments BEFORE the call, so a trace/debug message joined or projected out of a collection is built in full on every pass, and then discarded by a sink the shipped configuration leaves switched off.
Method: Roslyn syntax: log calls at a diagnostic level (a `Log`-prefixed method naming Trace/Debug/Verbose, or a bare `Debug`/`Trace`/`Verbose` on a receiver named for a logger), whose argument list is read for a call whose cost scales with a sequence — a LINQ operator, a materialisation, `string.Join`, a serializer — with no enclosing level check or conditional-compilation region. On a repository with no .NET source it reads JavaScript/TypeScript off the engine’s own token stream (test, vendored and minified paths not) with the same rule: a `debug`/`trace`/`verbose` call on a receiver named for a logger, or a `log`-prefixed method naming the level, whose argument calls an array operator (`map`/`filter`/`reduce`/`sort`/…), `Array.from`, `Object.keys/values/entries`, `JSON.stringify`/`util.inspect` over anything but a literal, or an array `join` — outside any arrow or function passed as an argument, which the logger calls only when the level is on — with no enclosing `if`, `&&` or `?:` whose condition names a level, a level string, or the `NODE_ENV`/`__DEV__`/`DEV` build switch. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X24 · Document value interpolated into markup unescaped10.0 / 10Exemplary○ Nothing flagged
Other · Security — Whether text read out of the document being converted is escaped before it is written into generated markup — a value the document's author chose, interpolated into an attribute the surrounding literal delimits, can close that attribute and open another.
Method: Roslyn semantic model over the whole compilation: a string-typed `Value`/`InnerText`/`InnerXml`/`Text` member declared inside `DocumentFormat.OpenXml` or `System.Xml` is a taint SOURCE, propagated through assignments, returns, arguments, tuple elements and string composition to its transitive closure, then read at interpolated-string holes that sit in a markup position the surrounding literal itself delimits. Escaper/encoder calls and enclosing validator conditions cut the flow. Flow- and container-insensitive by construction. A second arm needs no provenance at all and reports a type that CONTRADICTS ITSELF — the same expression escaped at one delimited markup hole and interpolated raw at another hole in the same markup position of the same type, which the type's own escaping proves is a defect without knowing where the value came from. On a repository with no .NET source it reads JavaScript/TypeScript off the token stream with the same rule: a DOM read of raw document text (`getAttribute`, `textContent`, `innerText`, `nodeValue`) is the source, propagated through local bindings and string composition, and judged at template-literal and concatenation holes in the same two delimited markup positions; escapers and validating conditions cut it, and documentation-site, test, vendored and minified scripts are not read. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a value the caller is invited to supply is the value the type actually uses — a constructor parameter stored in a private field that nothing ever reads while the default it was given is spelled out a second time at the site that should have read it, a keyed lookup that falls back to a different setting than the one its key names while the same type falls back to the matching one for that same key, or a culture-sensitive parse given no format provider by a type that feeds its own settable culture to the same kind of parse elsewhere, or a number an entry point writes to standard output under the host's culture while the same entry point formats with the invariant culture elsewhere. Either way, every caller who supplies a value silently gets something else.
Method: Roslyn syntax: private instance fields of a non-partial type assigned in a constructor from one of its own parameters with a `??` fallback, checked for whether anything in the type body reads the field and whether that same fallback expression is spelled out again outside the constructor; and `??` fallbacks onto a member access from a lookup call carrying exactly one string literal, grouped by that key across the type and checked for a fallback member whose folded name disagrees with the key while a sibling site for the same key agrees with it. On a repository with no .NET source the first two arms read JavaScript/TypeScript off the engine’s own token stream (tests included, bundles and vendored paths not): a `#x`, `private` or `private` parameter-property instance field filled in the constructor from a parameter (or one member of one) through `??`/`||` or a parameter default, never read anywhere in the file by name, whose constructed default is spelled again in the class body; and `lookup("key") ?? s.member` grouped by key per class, or per module outside every class. The culture arm has no JavaScript counterpart: its parses take no locale. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether a value handed from a callback to the body that waits on it crosses on something built to be crossed — a `Queue<T>`/`List<T>`/`Dictionary<K,V>` written inside an event handler and read back outside it is mutated by two flows at once, and the semaphore or completion source beside it orders how MANY items exist while leaving the collection's own head, tail and backing array unprotected.
Method: Roslyn syntax: method, accessor, local-function and lambda bodies that declare BOTH a non-thread-safe generic collection (`Queue`/`Stack`/`List`/`Dictionary`/`HashSet`/`Sorted*`/`LinkedList`) and a synchronisation primitive (`SemaphoreSlim`/`TaskCompletionSource`/`ManualResetEvent(Slim)`/`AutoResetEvent`/`CountdownEvent`) as locals, then read for a `+=`-registered lambda that raises that primitive while the body outside every lambda waits on it — and, in that scope, a mutating call on the collection inside the lambda paired with a mention of it outside. Any `lock` in the scope abstains it. On a repository with no .NET source the same handoff is read in Java off the engine’s own token stream (test source sets, vendored and demonstration paths not): an `ArrayList`/`LinkedList`/`ArrayDeque`/`PriorityQueue`/`Hash*`/`LinkedHash*`/`Tree*` local and a `CountDownLatch`/`Semaphore`/`CompletableFuture` local, a lambda or anonymous class that raises the primitive and mutates the collection, and a wait outside it; any `synchronized` or `lock()` abstains the body. Because each of those primitives orders what the callback wrote before raising it, only a touch that provably overlaps the callback is convicted: one after the registration and before the next wait, or one in a loop registered-before, waiting on every pass and not declaring the collection. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X28 · Index access outside its own emptiness guard10.0 / 10Exemplary○ Nothing flagged
Other · Code Health — Whether a condition that tests a value for emptiness indexes that same value only where the test holds — an `||` written one parenthesis too far to the left leaves an index access outside the guard beside it, so the empty case the guard exists to anticipate reaches the index and throws.
Method: Roslyn syntax only, no semantic model: the OUTERMOST `&&`/`||` of every boolean condition, read for a symbol the condition tests for emptiness (`string.IsNullOrEmpty`/`IsNullOrWhiteSpace`, a `Length`/`Count` comparison against a literal, `Any()`, a `Length`/`Count` pattern, or a comparison against `""`) and ALSO indexes. Each `symbol[...]` access is placed by a boolean-reachability walk from the access up to the outermost connective: an access is COVERED when some enclosing step has it in the right operand and the left operand, under the truth value that step forces, proves the symbol non-empty — a recursion over `&&`/`||` whose true- and false-directions are asymmetric. A finding needs BOTH an uncovered access and a covered one on the same symbol in the same condition, which is the agreeing twin that separates a misplaced parenthesis from an unrelated length test. Bare index accesses with no emptiness test in the condition are neither counted nor reported; a non-identifier receiver and a lambda nested inside the condition are outside the population. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X29 · Per-element action decided by a fixed element10.0 / 10Exemplary○ Nothing flagged
Other · Code Health — Whether a decision taken once per element is taken ABOUT that element — a test inside a counted loop that reads a fixed subscript of the very collection its guarded statement indexes by the loop variable applies element zero's answer to all of them, so the elements that differ from it are all handled wrongly, and in the same direction.
Method: Roslyn syntax only, no semantic model: every `for` statement declaring exactly ONE loop variable, and every `if` inside its body that is not under a nested loop or a lambda. A site enters the population when the `if`’s condition never mentions the loop variable while the statement it guards indexes some collection by that variable ALONE (`c[i]`; `c[i + 1]` and `c[i, j]` are outside it). A finding additionally needs the AGREEING TWIN at the same-collection grain: the condition must read THAT SAME collection at a subscript that does not move — written into the condition, or reached through a local declared BEFORE the loop, so an alias bound inside the body is not followed. Both collection expressions must be simple identifiers. On a repository with no .NET source the same rule reads JavaScript/TypeScript off the engine’s own token stream (tests included, bundles and vendored paths not): a `for (let|var|const x = …; …; …)` with one declarator and a braced body, an alias followed only when it is declared before the loop in a block that encloses it and never assigned inside the loop. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X30 · Support guard that admits what it rejects10.0 / 10Exemplary○ Nothing flagged
Other · Code Health — Whether a guard written as a NEGATED `||` says what its author meant — `!(a || b || x != k)` is `!a && !b && x == k` by De Morgan, so a bail-out that mixes capabilities the code needs with a fault it refuses turns inside out: it fires only where the capabilities are ABSENT, and lets every value the fault term names walk straight into the body that cannot handle it.
Method: Roslyn syntax only, no semantic model: every logical-not whose operand is a parenthesised `||` chain of two or more disjuncts, flattened (a left-nested `a || b || c` read once would see `(a || b)` as one disjunct). A site enters the population on that shape alone. A finding additionally needs the disjuncts to DISAGREE in polarity: at least one bare boolean read — an identifier or member access, never an invocation, which is a predicate rather than a capability flag — and at least one `x != <constant>`, the only form that negates into an exact-value pin (`== null` negates into a looser requirement and is outside the fault set). Consistently-polarised disjunctions, all-fault or all-capability, are counted and never reported; a negated `&&` is outside the population entirely. No same-receiver gate: it was measured to cost a real defect and remove no false positive. Deterministic, provable per finding. Advisory.
Do you agree with this assessment?
X32 · Type resolved by simple name across every loaded assembly10.0 / 10Exemplary○ Nothing flagged
Other · Code Health — Whether a plugin lookup names the type it means — searching every assembly loaded into the process for a candidate whose SIMPLE name equals a string supplied at runtime, and taking the first one found, is decided by assembly LOAD ORDER rather than by this source, so the same name can resolve to a different type on the next run.
Method: Roslyn syntax only, no semantic model: every invocation of `First`/`FirstOrDefault`/`Single`/`SingleOrDefault` whose OWN expression subtree contains both a `GetAssemblies()` call and a `GetTypes()`/`GetExportedTypes()` call — a single-element pick out of every type loaded into the process. A nested selector in the same chain sees no `GetAssemblies()` in its own subtree and is outside the population, so one lookup counts once however many links its chain has. A finding additionally needs both remaining halves: the selector must be `First`/`FirstOrDefault` (`Single`/`SingleOrDefault` reports the ambiguity rather than resolving it, and is counted and never reported), and the chain must carry an `==` comparison of `<lambda parameter>.Name` against something that is not a literal. The receiver must be a plain identifier bound by one of the chain’s own lambdas, which places `assembly.GetName().Name == "X"` outside the rule by construction. One exemption: a `.Name` test joined by `&&` to a `FullName`/`AssemblyQualifiedName` test on the same identifier is spared; joined by `||` it is not. Deterministic, provable per finding. Advisory.
Other · Code Health — Whether nullable reference types are enabled and not undermined by heavy `!` suppression.
Method: Roslyn compiler-options scan: NullableContextOptions per project; null-forgiving (!) suppression density per 1k syntax nodes. Deterministic, adoption plus suppression penalty.
0/1 NRT-eligible project(s) enable <Nullable>enable</Nullable> (projects targeting a pre-C#-8 framework are excluded — NRTs aren't available there). NRTs catch a whole class of null-deref bugs at compile time.
What to do
Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.
Do you agree with this assessment?
Reference — by lens
The score is the rank-weighted fold of these lenses (worst-heaviest), each including its meta-dimensions; a lens with a Critical contributor is capped at Fair (its band reads "gated by …") and is never the strongest area however high its average.
Unscored — 3 check(s) recorded observations but carry no score
These checks ran and found something, but they do not carry a score — either by design (an advisory check reports evidence rather than grading it) or because they could not be scored here. They are excluded from the score for that reason, not because there was nothing to see.
X10 Duplicated predicate — 25 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
X7 Silent fallback defaults — 27 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
X9 Subsumed condition operand — 3 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 1 control(s) we could not find positive evidence for
These checks grade a working control, and the repository shows no evidence of one. That is deliberately not scored as a zero: a repository cannot show an ops runbook, a database TTL or an infrastructure-side audit log, so absence of evidence here is not evidence the control is missing. It is also not a statement that the check is irrelevant to this codebase — the thing it grades applies; we just could not see it. Excluded from the score either way.
P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
Not included — 56 check(s) not relevant to this codebase
These checks had nothing to measure here (no tests, no git history, the codebase is small, or the architecture style doesn't apply), so they're omitted above rather than scored low.
AC1 Text alternatives — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC2 Forms & labels — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC3 Page structure — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC4 Keyboard semantics — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC5 ARIA correctness — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC6 Visual & motion safety — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AC7 A11y enforcement — Frontend below the scale floor (1 DOM element(s) < 25) — too little surface to assess accessibility.
AX1 Captive dependencies — no DI registrations detected
AX2 Stateful singletons — no singleton implementations detected
AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
AX7 Slice cohesion — not applicable — not a vertical-slice architecture
AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
AXR1 Runtime accessibility — the dev server did not expose a crawlable HTTP endpoint in time — no runtime evidence This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
C1 Data Protection — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
C2 Access Controls — No access-control surface detected in the analyzed source — no web/app surface to authorize (no HTTP API or web-UI project) and no authorization code at all (no [Authorize]/policies, no imperative guard methods). Access control is therefore N/A here — this is a library/CLI, which is authorized by its CALLER, not by itself. If this codebase grows request handlers, the dimension reactivates and a default-deny posture is expected then.
C3 Audit Trail — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
C4 Data Retention — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
C5 Data-Subject Rights — No personal data detected in the analyzed source — no PII-typed entity/column names (Email, FirstName, DateOfBirth, …), no ASP.NET Identity / user-account model, and no stored user credentials. GDPR data-protection controls are therefore N/A here. If this is intentional, record the no-PII posture in an ADR; if the app does process personal data, name those fields conventionally so this dimension activates.
D11 Test Reliability — Test reliability not included — the .rs suite was found but not re-run
D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
D21 Naming Consistency — Naming consistency is measured on C# only; JavaScript, Rust, TypeScript not measured.
D22 Internal API Consistency — API consistency is measured on C# only; the exposed Rust surface was not measured.
D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
D24 Comment Value — D24 reads C# and Visual Basic comments only — this repository's production source is .rs, .ts, which was left unread. Not scored: this is a gap in the analyzer, not a verdict about this repository.
D25 ADR Conformance — no ADRs to check
D27 Navigability — D27 counts a call into the standard library or a dependency as unresolved for this repository's language (.rs), so too few call sites counted as resolved to assess navigability. Not scored: this is a gap in the analyzer, not a verdict about this repository.
D28 Secrets (history) — gitleaks killed before it finished — this repository's git history not scanned
D32 Data Compliance (PII/GDPR) — 23 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
D7 Architectural Integrity — no checkable ADRs, and no project-reference graph for the cycle pass to read — so this dimension makes no claim about dependency cycles in either direction (where this repository's language has an import-cycle lens, cycles are reported there). Architectural integrity not assessed
DM1 Aggregate boundaries — this Rust crate declares no domain aggregate (a struct with private state and its own command methods), so DM1's aggregate-boundary read has no population to be taken over
DM2 Strongly-typed ids — the crate defines newtype typed-ids but declares no domain aggregate that could carry an id — so DM2's adoption ratio has no population to be taken over
DM3 Integration-event coupling — no integration events detected — coupling check not applicable
DM6 Domain ↔ infrastructure boundary — this Rust crate maps no type to a persistence framework (diesel/sea-orm/sqlx), so DM6's domain↔infrastructure fusion read has no population to be taken over
DM7 Repository granularity — no repository abstraction detected (e.g. uses a document session)
ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, and a call made through an inferred or generic receiver has no resolvable owner in the source. Reported as guidance rather than measured
ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable (this repository commits no MSBuild project, so its C# was read as syntax-only projects — a handler marked ONLY by an interface from a package is not visible without a build)
IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
P7 Outbound HTTP resilience — not applicable — no HTTP server, API framework or worker entry point was found in the JavaScript/TypeScript, Rust source, so there is no service whose uptime a failing dependency could take down
P8 Schema migrations — no ORM, schema-migration tool or schema auto-create was found in this repository's dependency manifests or source, so there is no database schema for this check to judge
P9 Domain vs controller coverage — coverage data present for 9 file(s), but no domain-layer files were identified: no covered file's path contains any of the markers this check keys on (/domain/, /aggregates/, /valueobjects/, /domainmodel/, .domain/, /entities/), which are matched case-insensitively anywhere in the path. With no domain partition there is nothing to compare the web/controller layer against — if this repository keeps its business rules under a folder named none of those, that naming is what the check cannot see, not the domain logic.
PF1 Benchmark discipline — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
PF2 Allocation hygiene — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
R11 Import Boundaries — No recognizable feature-sliced/layered src layout — boundary rules not applicable.
S1 Web-Security Posture — No web surface detected in the analyzed source — no HTTP API or web-UI project (no controllers/minimal-API endpoints, no Razor/Blazor views) and no web middleware (HTTPS redirection, HSTS, security headers, cookies). Transport security, security headers, secure cookies, CSRF/input-validation and middleware-order controls are therefore N/A here — this is a library/CLI/worker, not a web app. Crypto hygiene was still checked and found nothing to flag. If this codebase becomes web-facing, the dimension reactivates automatically.
SC1 Supply-chain hygiene — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
X1 Async correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
X2 Cancellation propagation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
X27 Collection changed while being enumerated — This check needs a compiled C# program and this repository commits no project file to compile, so only its syntax could be read. That is a limit of the analyzer, not a finding about your code.
X3 Exception handling — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
X4 Structured logging — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
The findings behind the scores, grouped by severity, then by dimension and kind. The high-severity issues are enumerated in full below; items per group are capped at 25 with any overflow stated explicitly per group, never silently truncated. The complete machine-readable list of every finding (all severities) is the companion findings.md in this report's bundle.
Orphaned knowledge ext/crypto/subtle_import_key.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge cli/lsp/ts_server.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge ext/crypto/subtle_crypto.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge ext/crypto/subtle_export_key.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge ext/crypto/subtle_generate_key.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge cli/tools/fmt_editorconfig.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away, so if it breaks, no one currently understands it. It does carry its own tests, so the behaviour is pinned even though the understanding is gone: schedule a read-through, using those tests as the specification, before the next change lands here.
Orphaned knowledge ext/crypto/digest.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Orphaned knowledge ext/web/stream_resource.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away, so if it breaks, no one currently understands it. It does carry its own tests, so the behaviour is pinned even though the understanding is gone: schedule a read-through, using those tests as the specification, before the next change lands here.
Orphaned knowledge ext/crypto/subtle_encrypt.rs:1— No living knowledge remains for this large file — its last meaningful change has decayed away; if it breaks, no one currently understands it. Schedule a read-through / add characterisation tests before it bites.
Boundary-crossing change coupling: REDACTED ↔ fuzzingclient.js REDACTED:1— `REDACTED` (context .github) and `ext/websocket/autobahn/fuzzingclient.js` (context ext) sit in DIFFERENT parts of the tree yet change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) — the bounded-context boundary may be in the wrong place, or one context is leaking into the other. This is the behavioural boundary violation a static scan can't see. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `e945e5c7` ci: fix saving wpt cache (#32228) (at that commit the file was still `.github/workflows/ci.generate.ts`); `4af98fa8` build: remove --unstable flags from CI (#25548) (at that commit the file was still `.github/workflows/ci.generate.ts`); `89160e7c` chore(ext/websocket): readd autobahn|testsuite fuzzingclient (#18903) (at that commit the file was still `.github/workflows/ci.generate.ts`) — run `git show` on any of them.
Boundary-crossing change coupling: flags.rs ↔ permissions.rs cli/args/flags.rs:1— `cli/args/flags.rs` (context cli) and `runtime/ops/permissions.rs` (context runtime) sit in DIFFERENT parts of the tree yet change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) — the bounded-context boundary may be in the wrong place, or one context is leaking into the other. This is the behavioural boundary violation a static scan can't see. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `82eba477` feat: add `--ignore-env=...` (#31187); `c8f69205` refactor: bury descriptor parsing in PermissionsContainer (#25936); `74ac29ba` fix(permissions): handle ipv6 addresses correctly (#24397) — run `git show` on any of them.
Boundary-crossing change coupling: lib.rs ↔ mod.rs ext/process/lib.rs:1— `ext/process/lib.rs` (context ext) and `runtime/ops/mod.rs` (context runtime) sit in DIFFERENT parts of the tree yet change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) — the bounded-context boundary may be in the wrong place, or one context is leaking into the other. This is the behavioural boundary violation a static scan can't see. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `0050857f` refactor: add 'deno_process' crate (#27680); `974e2f44` refactor: add 'deno_os' crate (#27655) (at that commit the file was still `runtime/ops/process.rs`); `c464cd70` refactor: FeatureChecker integration in ext/ crates (#20797) (at that commit the file was still `runtime/ops/process.rs`) — run `git show` on any of them.
Boundary-crossing change coupling: lib.rs ↔ worker.rs ext/broadcast_channel/lib.rs:1— `ext/broadcast_channel/lib.rs` (context ext) and `runtime/worker.rs` (context runtime) sit in DIFFERENT parts of the tree yet change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) — the bounded-context boundary may be in the wrong place, or one context is leaking into the other. This is the behavioural boundary violation a static scan can't see. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `25b9abcd` feat: use new feature checker (#29091); `c464cd70` refactor: FeatureChecker integration in ext/ crates (#20797); `a5568066` refactor: use deno_core::FeatureChecker for unstable checks (#20765) — run `git show` on any of them.
Boundary-crossing change coupling: lib.rs ↔ web_worker.rs ext/broadcast_channel/lib.rs:1— `ext/broadcast_channel/lib.rs` (context ext) and `runtime/web_worker.rs` (context runtime) sit in DIFFERENT parts of the tree yet change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) — the bounded-context boundary may be in the wrong place, or one context is leaking into the other. This is the behavioural boundary violation a static scan can't see. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `25b9abcd` feat: use new feature checker (#29091); `c464cd70` refactor: FeatureChecker integration in ext/ crates (#20797); `a5568066` refactor: use deno_core::FeatureChecker for unstable checks (#20765) — run `git show` on any of them.
AX9 · CQS / query purity· Query writes persistent state on the read path · ×2
Query writes persistent state on the read path: SerializeDeserialize.get_shared_array_buffer_id libs/core/ops_builtin_v8.rs:663— `SerializeDeserialize.get_shared_array_buffer_id` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command.
Query writes persistent state on the read path: SerializeDeserialize.get_wasm_module_transfer_id libs/core/ops_builtin_v8.rs:691— `SerializeDeserialize.get_wasm_module_transfer_id` is a read-named query yet it performs a durable write on the read path (a persist to a store/repository). A query must stay side-effect-free so reads are safe to retry, cache, and route to a read replica; move the write into a command.
Project dependency cycle tests/specs/npm/workspace_symlink_cyclic/packages/pkg-a/package.json:5— The projects pkg-a → pkg-b → pkg-a form a reference cycle. Cyclic dependencies prevent independent build/test/deploy, blur ownership, and tend to grow into a big ball of mud. Break the cycle by extracting the shared types into a separate project both can reference.
Unlisted import '.other-package' tests/registry/npm/@denotest/require-added-nm-folder/1.0.0/index.js:2— Imported but not declared in any reachable package.json — installs work only by hoisting accident.
Unlisted import 'non-existent' tests/registry/npm/@denotest/require-non-existent/1.0.0/index.cjs:2— Imported but not declared in any reachable package.json — installs work only by hoisting accident.
TodoComment tools/lint_plugins/prefer_primordials.ts:992— // TODO(petamoriken): Support for deeply nested assignments — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/wpt/wpt.ts:137— // TODO(lucacsonato): use this when 1.7.1 is released. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/util/server/servers/jsr_registry.rs:119— // TODO(bartlomieju): add a proper router here — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/util/lib/builders.rs:1021— // todo(dsherret): use monch to extract out the vars — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/util/lib/lsp.rs:993— // TODO(nayeemrmn): Remove config-related methods from builder. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/buffer_test.ts:117— // todo(fbaltor): remove this 'any' when @types/node fixes https://github.com/DefinitelyTyped/DefinitelyTyped/discussions/65831
TodoComment tests/unit_node/buffer_test.ts:136— // todo(fbaltor): remove this 'any' when @types/node fixes https://github.com/DefinitelyTyped/DefinitelyTyped/discussions/65831
TodoComment tests/unit_node/child_process_test.ts:32— // TODO(uki00a): Once Node.js's `parallel/test-child-process-spawn-error.js` works, this test case should be removed. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:37— // TODO(@bartlomieju) Assert an error message. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:196— // TODO(uki00a): Remove this case once Node's `parallel/test-child-process-spawn-event.js` works. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:243— // TODO(uki00a): Remove this case once Node's `parallel/test-child-process-spawn-shell.js` works. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:271— // TODO(uki00a): Remove this case once Node's `parallel/test-child-process-spawn-shell.js` works. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:302— // TODO(uki00a): Remove this case once Node's `parallel/test-child-process-spawn-shell.js` works. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/child_process_test.ts:332— // TODO(uki00a): Remove this case once Node's `parallel/test-child-process-spawn-shell.js` works. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:290— // TODO(kt3k): Delete this test case, and instead enable the compat case — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:781— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:874— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1130— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1162— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1186— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1208— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1269— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1306— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1336— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TodoComment tests/unit_node/fs_test.ts:1373— // TODO(bartlomieju): this test is broken in Deno 2, because `file.rid` is undefined. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FileTooLong: lsp/tsc.rs cli/lsp/tsc.rs— FileTooLong — 5042 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 43 free functions. The bar is 500 significant lines; this is 4542 over it, 10.08× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: web/06_streams.js ext/web/06_streams.js— FileTooLong — 4965 significant lines (blank, comment-only and punctuation-only lines excluded; the length bar is tripled for a single-responsibility module of 4 or fewer top-level units). The bar is 500 significant lines; this is 4465 over it, 9.93× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: http/http_next.rs ext/http/http_next.rs— FileTooLong — 4032 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 116 free functions. The bar is 500 significant lines; this is 3532 over it, 8.06× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: permissions/lib.rs runtime/permissions/lib.rs— FileTooLong — 3795 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted). The bar is 500 significant lines; this is 3295 over it, 7.59× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: lsp/language_server.rs cli/lsp/language_server.rs— FileTooLong — 3701 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), about 78% of them inside a single declaration: Inner (5 blocks, 305-4813). The bar is 500 significant lines; this is 3201 over it, 7.40× the bar. Moving the declarations that sit BESIDE it into sibling files will not shorten this file. Extract from INSIDE that declaration instead: lift each cohesive group of its body — the parts that share the same inputs and are named together — into its own unit in a sibling file, and have the original call them.
FileTooLong: tools/desktop.rs cli/tools/desktop.rs— FileTooLong — 3589 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 94 free functions. The bar is 500 significant lines; this is 3089 over it, 7.18× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: node_crypto/keys.rs ext/node_crypto/keys.rs— FileTooLong — 3427 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 87 free functions. The bar is 500 significant lines; this is 2927 over it, 6.85× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: polyfills/http2.ts ext/node/polyfills/http2.ts— FileTooLong — 3298 significant lines (blank, comment-only and punctuation-only lines excluded). The bar is 500 significant lines; this is 2798 over it, 6.60× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: ops/tls_wrap.rs ext/node/ops/tls_wrap.rs— FileTooLong — 3180 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 49 free functions. The bar is 500 significant lines; this is 2680 over it, 6.36× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: napi/js_native_api.rs ext/napi/js_native_api.rs— FileTooLong — 2953 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 137 free functions. The bar is 500 significant lines; this is 2453 over it, 5.91× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: console/inspect.rs ext/web/console/inspect.rs— FileTooLong — 2860 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 92 free functions. The bar is 500 significant lines; this is 2360 over it, 5.72× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: polyfills/fs.ts ext/node/polyfills/fs.ts— FileTooLong — 2853 significant lines (blank, comment-only and punctuation-only lines excluded). The bar is 500 significant lines; this is 2353 over it, 5.71× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: node_shim/lib.rs libs/node_shim/lib.rs— FileTooLong — 2823 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), about 64% of them inside a single declaration: OptionsParser (3 blocks, 776-3074). The bar is 500 significant lines; this is 2323 over it, 5.65× the bar. Moving the declarations that sit BESIDE it into sibling files will not shorten this file. Extract from INSIDE that declaration instead: lift each cohesive group of its body — the parts that share the same inputs and are named together — into its own unit in a sibling file, and have the original call them.
FileTooLong: internal/errors.ts ext/node/polyfills/internal/errors.ts— FileTooLong — 2684 significant lines (blank, comment-only and punctuation-only lines excluded). The bar is 500 significant lines; this is 2184 over it, 5.37× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: ops/fs.rs ext/node/ops/fs.rs— FileTooLong — 2567 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 91 free functions. The bar is 500 significant lines; this is 2067 over it, 5.13× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: telemetry/lib.rs ext/telemetry/lib.rs— FileTooLong — 2478 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 45 free functions. The bar is 500 significant lines; this is 1978 over it, 4.96× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: src/convert.rs libs/cli_parser/src/convert.rs— FileTooLong — 2401 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), declaring 104 free functions. The bar is 500 significant lines; this is 1901 over it, 4.80× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: ast_buffer/ts_estree.rs cli/tools/lint/ast_buffer/ts_estree.rs— FileTooLong — 2347 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), about 80% of them inside a single declaration: TsEsTreeBuilder (3 blocks, 476-2898). The bar is 500 significant lines; this is 1847 over it, 4.69× the bar. Moving the declarations that sit BESIDE it into sibling files will not shorten this file. Extract from INSIDE that declaration instead: lift each cohesive group of its body — the parts that share the same inputs and are named together — into its own unit in a sibling file, and have the original call them.
FileTooLong: internal/buffer.mjs ext/node/polyfills/internal/buffer.mjs— FileTooLong — 2314 significant lines (blank, comment-only and punctuation-only lines excluded; the length bar is tripled for a single-responsibility module of 4 or fewer top-level units). The bar is 500 significant lines; this is 1814 over it, 4.63× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: web/geometry.rs ext/web/geometry.rs— FileTooLong — 2290 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted). The bar is 500 significant lines; this is 1790 over it, 4.58× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: polyfills/testing.ts ext/node/polyfills/testing.ts— FileTooLong — 2278 significant lines (blank, comment-only and punctuation-only lines excluded). The bar is 500 significant lines; this is 1778 over it, 4.56× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: workspace/mod.rs libs/config/workspace/mod.rs— FileTooLong — 2255 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted). The bar is 500 significant lines; this is 1755 over it, 4.51× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: resolution/graph.rs libs/npm/resolution/graph.rs— FileTooLong — 2222 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), about 66% of them inside a single declaration: GraphDependencyResolver (2 blocks, 1106-3418). The bar is 500 significant lines; this is 1722 over it, 4.44× the bar. Moving the declarations that sit BESIDE it into sibling files will not shorten this file. Extract from INSIDE that declaration instead: lift each cohesive group of its body — the parts that share the same inputs and are named together — into its own unit in a sibling file, and have the original call them.
FileTooLong: node_sqlite/database.rs ext/node_sqlite/database.rs— FileTooLong — 2215 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted). The bar is 500 significant lines; this is 1715 over it, 4.43× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FileTooLong: node_resolver/resolution.rs libs/node_resolver/resolution.rs— FileTooLong — 2204 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted). The bar is 500 significant lines; this is 1704 over it, 4.41× the bar. To reduce it, split the file along the responsibilities already in it: move each cohesive group of declarations into its own sibling file in the same module or package, so no one file has to be read whole to change one of them.
FunctionTooLong: jupyter_kernel.startJupyterKernel cli/js/jupyter_kernel.js:537— FunctionTooLong — startJupyterKernel runs 447 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 347 over it, 4.47× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: denort::run::run_with_options cli/rt/run.rs:1394— FunctionTooLong — denort::run::run_with_options runs 427 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 327 over it, 4.27× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::tools::desktop::create_windows_msi cli/tools/desktop.rs:4590— FunctionTooLong — deno::tools::desktop::create_windows_msi runs 425 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 325 over it, 4.25× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_http::http_next::serve_http11_raw ext/http/http_next.rs:4532— FunctionTooLong — deno_http::http_next::serve_http11_raw runs 417 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 317 over it, 4.17× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::tools::lint::ast_buffer::swc::serialize_expr cli/tools/lint/ast_buffer/swc.rs:660— FunctionTooLong — deno::tools::lint::ast_buffer::swc::serialize_expr runs 378 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 278 over it, 3.78× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: _win32.join ext/node/polyfills/path/_win32.ts:460— FunctionTooLong — join runs 378 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 278 over it, 3.78× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_ops::op2::dispatch_slow::from_arg libs/ops/op2/dispatch_slow.rs:425— FunctionTooLong — deno_ops::op2::dispatch_slow::from_arg runs 332 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 232 over it, 3.32× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: utils.emitKeys ext/node/polyfills/internal/readline/utils.mjs:121— FunctionTooLong — emitKeys runs 331 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 231 over it, 3.31× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::tools::desktop::compile_desktop cli/tools/desktop.rs:176— FunctionTooLong — deno::tools::desktop::compile_desktop runs 320 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 220 over it, 3.20× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::run_subcommand cli/lib.rs:124— FunctionTooLong — deno::run_subcommand runs 318 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 218 over it, 3.18× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_core::uv_compat::tty::poll_tty_handle libs/core/uv_compat/tty.rs:2188— FunctionTooLong — deno_core::uv_compat::tty::poll_tty_handle runs 281 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 181 over it, 2.81× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_core::uv_compat::pipe::poll_pipe_handle REDACTED:1759— FunctionTooLong — deno_core::uv_compat::pipe::poll_pipe_handle runs 261 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 161 over it, 2.61× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_ffi::callback::do_ffi_callback ext/ffi/callback.rs:212— FunctionTooLong — deno_ffi::callback::do_ffi_callback runs 254 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 154 over it, 2.54× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: x.buildCommands tools/x.ts:65— FunctionTooLong — buildCommands runs 254 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 154 over it, 2.54× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_runtime::cpu_profiler::cpuprof::generate_markdown_report runtime/cpu_profiler/cpuprof.rs:59— FunctionTooLong — deno_runtime::cpu_profiler::cpuprof::generate_markdown_report runs 248 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 148 over it, 2.48× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_canvas::bitmaprenderer::create ext/canvas/bitmaprenderer.rs:449— FunctionTooLong — deno_canvas::bitmaprenderer::create runs 241 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 141 over it, 2.41× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_process::create_command ext/process/lib.rs:685— FunctionTooLong — deno_process::create_command runs 238 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 138 over it, 2.38× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::tools::lint::ast_buffer::swc::serialize_module_decl cli/tools/lint/ast_buffer/swc.rs:153— FunctionTooLong — deno::tools::lint::ast_buffer::swc::serialize_module_decl runs 237 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 137 over it, 2.37× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: update_node_stream.transform ext/node/update_node_stream.ts:122— FunctionTooLong — transform runs 237 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 137 over it, 2.37× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_crypto::subtle_generate_key::run ext/crypto/subtle_generate_key.rs:311— FunctionTooLong — deno_crypto::subtle_generate_key::run runs 234 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 134 over it, 2.34× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: _http_client.ClientRequest REDACTED:505— FunctionTooLong — ClientRequest runs 230 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 130 over it, 2.30× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_core::uv_compat::tcp::poll_tcp_handle libs/core/uv_compat/tcp.rs:1271— FunctionTooLong — deno_core::uv_compat::tcp::poll_tcp_handle runs 230 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 130 over it, 2.30× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: primary.init ext/node/polyfills/internal/cluster/primary.ts:59— FunctionTooLong — init runs 227 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 127 over it, 2.27× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno::standalone::virtual_fs::vfs_as_display_tree cli/standalone/virtual_fs.rs:36— FunctionTooLong — deno::standalone::virtual_fs::vfs_as_display_tree runs 221 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 121 over it, 2.21× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
FunctionTooLong: deno_core::uv_compat::pipe::poll_pipe_handle REDACTED:1404— FunctionTooLong — deno_core::uv_compat::pipe::poll_pipe_handle runs 215 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 115 over it, 2.15× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
deno::tools::coverage::generate_coverage_report (cognitive 146) cli/tools/coverage/mod.rs:155— deno::tools::coverage::generate_coverage_report has cognitive complexity 146 (threshold 15). Drivers by points: if/else 38 (102 pts), loops 12 (28 pts), boolean chains 16 (nesting depth added 80). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::fmt_editorconfig::glob_to_regex_depth (cognitive 113) cli/tools/fmt_editorconfig.rs:427— deno::tools::fmt_editorconfig::glob_to_regex_depth has cognitive complexity 113 (threshold 15). Drivers by points: if/else 18 (61 pts), loops 8 (33 pts), match/switch 3 (11 pts), boolean chains 8 (nesting depth added 76). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno::tools::pm::cache_deps::cache_top_level_deps (cognitive 105) cli/tools/pm/cache_deps.rs:34— deno::tools::pm::cache_deps::cache_top_level_deps has cognitive complexity 105 (threshold 15). Drivers by points: if/else 27 (86 pts), loops 4 (12 pts), boolean chains 4, match/switch 1 (3 pts) (nesting depth added 69). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::lsp::testing::collectors::visit_call_expr (cognitive 102) cli/lsp/testing/collectors.rs:139— deno::lsp::testing::collectors::visit_call_expr has cognitive complexity 102 (threshold 15). Drivers by points: if/else 19 (71 pts), match/switch 7 (24 pts), loops 2 (6 pts), boolean chains 1 (nesting depth added 73). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::desktop::compile_desktop (cognitive 99) cli/tools/desktop.rs:176— deno::tools::desktop::compile_desktop has cognitive complexity 99 (threshold 15). Drivers by points: if/else 39 (68 pts), match/switch 9 (15 pts), boolean chains 8, loops 2 (8 pts) (nesting depth added 41). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::lsp::diagnostics::diagnose_resolution (cognitive 82) cli/lsp/diagnostics.rs:1152— deno::lsp::diagnostics::diagnose_resolution has cognitive complexity 82 (threshold 15). Drivers by points: if/else 15 (58 pts), match/switch 6 (20 pts), boolean chains 2, loops 1 (2 pts) (nesting depth added 58). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno::run_subcommand (cognitive 79) cli/lib.rs:124— deno::run_subcommand has cognitive complexity 79 (threshold 15). Drivers by points: if/else 25 (59 pts), match/switch 6 (17 pts), boolean chains 3 (nesting depth added 45). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno::lsp::tsc::display_parts_to_string (cognitive 67) cli/lsp/tsc.rs:2005— deno::lsp::tsc::display_parts_to_string has cognitive complexity 67 (threshold 15). Drivers by points: if/else 17 (58 pts), loops 2 (4 pts), boolean chains 3, match/switch 1 (2 pts) (nesting depth added 44). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno::tools::transpile::restore_block_comment_newlines (cognitive 65) cli/tools/transpile.rs:388— deno::tools::transpile::restore_block_comment_newlines has cognitive complexity 65 (threshold 15). Drivers by points: if/else 13 (36 pts), loops 4 (14 pts), boolean chains 10, match/switch 2 (5 pts) (nesting depth added 36). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tsc::tsconfig_gen::generate_npm_paths (cognitive 58) cli/tsc/tsconfig_gen.rs:1174— deno::tsc::tsconfig_gen::generate_npm_paths has cognitive complexity 58 (threshold 15). Drivers by points: if/else 14 (45 pts), loops 2 (6 pts), match/switch 2 (6 pts), boolean chains 1 (nesting depth added 39). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tsc::tsconfig_gen::generate_jsr_paths (cognitive 56) cli/tsc/tsconfig_gen.rs:1314— deno::tsc::tsconfig_gen::generate_jsr_paths has cognitive complexity 56 (threshold 15). Drivers by points: if/else 12 (42 pts), loops 2 (7 pts), match/switch 2 (7 pts) (nesting depth added 40). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno::lsp::path_to_regex::lexer (cognitive 54) cli/lsp/path_to_regex.rs:66— deno::lsp::path_to_regex::lexer has cognitive complexity 54 (threshold 15). Drivers by points: if/else 12 (40 pts), loops 3 (7 pts), boolean chains 5, match/switch 1 (2 pts) (nesting depth added 33). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::fmt::get_typescript_config_builder (cognitive 54) cli/tools/fmt.rs:1285— deno::tools::fmt::get_typescript_config_builder has cognitive complexity 54 (threshold 15). Drivers by points: match/switch 14 (28 pts), if/else 23 (25 pts), boolean chains 1 (nesting depth added 16). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno::lsp::path_to_regex::tokens_to_regex (cognitive 53) cli/lsp/path_to_regex.rs:638— deno::lsp::path_to_regex::tokens_to_regex has cognitive complexity 53 (threshold 15). Drivers by points: if/else 22 (41 pts), match/switch 3 (9 pts), boolean chains 2, loops 1 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::coverage::merge::merge_range_tree_children (cognitive 53) cli/tools/coverage/merge.rs:243— deno::tools::coverage::merge::merge_range_tree_children has cognitive complexity 53 (threshold 15). Drivers by points: if/else 14 (31 pts), loops 9 (20 pts), match/switch 1 (2 pts) (nesting depth added 29). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno::tools::pm::add (cognitive 53) cli/tools/pm/mod.rs:536— deno::tools::pm::add has cognitive complexity 53 (threshold 15). Drivers by points: if/else 21 (36 pts), match/switch 5 (11 pts), boolean chains 3, loops 3 (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::installer::npm_compat::install_http_modules (cognitive 50) cli/tools/installer/npm_compat.rs:1299— deno::tools::installer::npm_compat::install_http_modules has cognitive complexity 50 (threshold 15). Drivers by points: if/else 17 (30 pts), match/switch 4 (10 pts), boolean chains 6, loops 3 (4 pts) (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::compile::compile_inner (cognitive 49) cli/tools/compile.rs:70— deno::tools::compile::compile_inner has cognitive complexity 49 (threshold 15). Drivers by points: if/else 21 (38 pts), loops 4 (8 pts), boolean chains 3 (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::pm::interactive_picker::select_items (cognitive 47) cli/tools/pm/interactive_picker.rs:22— deno::tools::pm::interactive_picker::select_items has cognitive complexity 47 (threshold 15). Drivers by points: if/else 17 (34 pts), loops 3 (7 pts), match/switch 2 (5 pts), boolean chains 1 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::info::add_npm_packages_to_json (cognitive 46) cli/tools/info.rs:310— deno::tools::info::add_npm_packages_to_json has cognitive complexity 46 (threshold 15). Drivers by points: if/else 12 (33 pts), loops 4 (9 pts), boolean chains 4 (nesting depth added 26). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno::tsc::tsconfig_gen::build_tsconfig (cognitive 46) cli/tsc/tsconfig_gen.rs:758— deno::tsc::tsconfig_gen::build_tsconfig has cognitive complexity 46 (threshold 15). Drivers by points: if/else 16 (19 pts), match/switch 7 (18 pts), loops 4 (7 pts), boolean chains 2 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::lsp::tsc::op_script_names (cognitive 45) cli/lsp/tsc.rs:5589— deno::lsp::tsc::op_script_names has cognitive complexity 45 (threshold 15). Drivers by points: if/else 9 (30 pts), loops 8 (14 pts), boolean chains 1 (nesting depth added 27). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::clean::clean_except (cognitive 45) cli/tools/clean.rs:254— deno::tools::clean::clean_except has cognitive complexity 45 (threshold 15). Drivers by points: if/else 13 (24 pts), match/switch 4 (11 pts), loops 5 (6 pts), boolean chains 4 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::pm::outdated::update (cognitive 45) cli/tools/pm/outdated/mod.rs:441— deno::tools::pm::outdated::update has cognitive complexity 45 (threshold 15). Drivers by points: if/else 17 (31 pts), loops 4 (8 pts), boolean chains 4, match/switch 1 (2 pts) (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno::tools::pm::why::why (cognitive 44) cli/tools/pm/why.rs:59— deno::tools::pm::why::why has cognitive complexity 44 (threshold 15). Drivers by points: loops 13 (21 pts), if/else 14 (20 pts), boolean chains 3 (nesting depth added 14). To reduce it, break up the iteration: give each loop body a named function, and split a multi-phase loop into one function per phase so no single body carries the whole pipeline.
MethodTooLong: OptionsParser.setup_options libs/node_shim/lib.rs:830— MethodTooLong — setup_options runs 1221 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 1121 over it, 12.21× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: LocalNpmPackageInstaller.sync_resolution_with_fs libs/npm_installer/local.rs:199— MethodTooLong — sync_resolution_with_fs runs 645 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 545 over it, 6.45× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: DenoCompileBinaryWriter.write_standalone_binary cli/standalone/binary.rs:634— MethodTooLong — write_standalone_binary runs 464 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 364 over it, 4.64× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: NumericValue.parse_inner ext/web/css_value.rs:930— MethodTooLong — parse_inner runs 411 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 311 over it, 4.11× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: WASI.constructor ext/node/polyfills/wasi.ts:145— MethodTooLong — constructor runs 395 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 295 over it, 3.95× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: HoistedNpmPackageInstaller.sync_resolution_with_fs libs/npm_installer/hoisted.rs:349— MethodTooLong — sync_resolution_with_fs runs 305 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 205 over it, 3.05× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: GraphDependencyResolver.resolve_peers_of_node libs/npm/resolution/graph.rs:1864— MethodTooLong — resolve_peers_of_node runs 287 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 187 over it, 2.87× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: MainWorker.from_options runtime/worker.rs:460— MethodTooLong — from_options runs 280 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 180 over it, 2.80× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: ModuleRegistry.get_completions cli/lsp/registries.rs:662— MethodTooLong — get_completions runs 273 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 173 over it, 2.73× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: Console.table_impl ext/web/console/mod.rs:1421— MethodTooLong — table_impl runs 256 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 156 over it, 2.56× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: EszipV2.from_graph libs/eszip/v2.rs:1281— MethodTooLong — from_graph runs 256 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 156 over it, 2.56× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: Inner.code_action cli/lsp/language_server.rs:2151— MethodTooLong — code_action runs 231 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 131 over it, 2.31× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: WebWorker.from_options runtime/web_worker.rs:488— MethodTooLong — from_options runs 229 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 129 over it, 2.29× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: ImageBitmapRenderingContext.transfer_from_image_bitmap ext/canvas/bitmaprenderer.rs:82— MethodTooLong — transfer_from_image_bitmap runs 225 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 125 over it, 2.25× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: JsError.inner_from_v8_exception libs/core/error.rs:1016— MethodTooLong — inner_from_v8_exception runs 211 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 111 over it, 2.11× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: NpmInstallDepsProvider.from_workspace libs/npm_installer/package_json.rs:161— MethodTooLong — from_workspace runs 209 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 109 over it, 2.09× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: WebSocket.constructor ext/websocket/01_websocket.js:253— MethodTooLong — constructor runs 208 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 108 over it, 2.08× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: Url.urlParse ext/node/polyfills/url.ts:666— MethodTooLong — urlParse runs 205 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 105 over it, 2.05× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: SQLTagStore.iterate ext/node_sqlite/sql_tag_store.rs:471— MethodTooLong — iterate runs 205 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 105 over it, 2.05× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: EszipV2.parse_with_version libs/eszip/v2.rs:734— MethodTooLong — parse_with_version runs 196 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 96 over it, 1.96× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: WorkspaceResolver.from_workspace libs/resolver/workspace.rs:856— MethodTooLong — from_workspace runs 196 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 96 over it, 1.96× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: Url.resolveObject ext/node/polyfills/url.ts:262— MethodTooLong — resolveObject runs 195 significant lines (blank, comment-only and punctuation-only lines excluded) in one body. The bar is 100 significant lines; this is 95 over it, 1.95× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: Workspace.diagnostics libs/config/workspace/mod.rs:1203— MethodTooLong — diagnostics runs 194 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 94 over it, 1.94× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: GraphDependencyResolver.drain_pending_parallel libs/npm/resolution/graph.rs:2469— MethodTooLong — drain_pending_parallel runs 192 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 92 over it, 1.92× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
MethodTooLong: PackageJson.load_from_value libs/package_json/lib.rs:510— MethodTooLong — load_from_value runs 192 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted) in one body. The bar is 100 significant lines; this is 92 over it, 1.92× the bar. This is length, not branching: a long straight-line body scores low on complexity and is still read whole to change any part of it, so the complexity numbers beside this row neither confirm nor excuse it. To reduce it, extract each cohesive step of the body — the runs of statements that work on the same values and would earn the same name — into its own named unit, and have this one call them in order.
deno::tools::lint::ast_buffer::swc::serialize_expr (cyclomatic 106) cli/tools/lint/ast_buffer/swc.rs:660— deno::tools::lint::ast_buffer::swc::serialize_expr has cyclomatic complexity 106 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::run_subcommand (cyclomatic 71) cli/lib.rs:124— deno::run_subcommand has cyclomatic complexity 71 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::coverage::generate_coverage_report (cyclomatic 59) cli/tools/coverage/mod.rs:155— deno::tools::coverage::generate_coverage_report has cyclomatic complexity 59 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::desktop::compile_desktop (cyclomatic 53) cli/tools/desktop.rs:176— deno::tools::desktop::compile_desktop has cyclomatic complexity 53 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::fmt::get_typescript_config_builder (cyclomatic 53) cli/tools/fmt.rs:1285— deno::tools::fmt::get_typescript_config_builder has cyclomatic complexity 53 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::tools::lint::ast_buffer::swc::serialize_ts_type (cyclomatic 42) cli/tools/lint/ast_buffer/swc.rs:2498— deno::tools::lint::ast_buffer::swc::serialize_ts_type has cyclomatic complexity 42 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::lsp::testing::collectors::visit_call_expr (cyclomatic 39) cli/lsp/testing/collectors.rs:139— deno::lsp::testing::collectors::visit_call_expr has cyclomatic complexity 39 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::fmt_editorconfig::glob_to_regex_depth (cyclomatic 38) cli/tools/fmt_editorconfig.rs:427— deno::tools::fmt_editorconfig::glob_to_regex_depth has cyclomatic complexity 38 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::transpile::restore_block_comment_newlines (cyclomatic 36) cli/tools/transpile.rs:388— deno::tools::transpile::restore_block_comment_newlines has cyclomatic complexity 36 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::pm::cache_deps::cache_top_level_deps (cyclomatic 35) cli/tools/pm/cache_deps.rs:34— deno::tools::pm::cache_deps::cache_top_level_deps has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::standalone::virtual_fs::vfs_as_display_tree (cyclomatic 34) cli/standalone/virtual_fs.rs:36— deno::standalone::virtual_fs::vfs_as_display_tree has cyclomatic complexity 34 (threshold 15). Of this number, 18 points are the body's own statements and 16 belong to 8 function items inside it that branch. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::tools::clean::clean_except (cyclomatic 33) cli/tools/clean.rs:254— deno::tools::clean::clean_except has cyclomatic complexity 33 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::pm::add (cyclomatic 32) cli/tools/pm/mod.rs:536— deno::tools::pm::add has cyclomatic complexity 32 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tsc::tsconfig_gen::build_tsconfig (cyclomatic 29) cli/tsc/tsconfig_gen.rs:758— deno::tsc::tsconfig_gen::build_tsconfig has cyclomatic complexity 29 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno::tools::installer::npm_compat::install_http_modules (cyclomatic 28) cli/tools/installer/npm_compat.rs:1299— deno::tools::installer::npm_compat::install_http_modules has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::pm::why::why (cyclomatic 28) cli/tools/pm/why.rs:59— deno::tools::pm::why::why has cyclomatic complexity 28 (threshold 15). To reduce it, break up the iteration: give each loop body a named function, and split a multi-phase loop into one function per phase so no single body carries the whole pipeline.
deno::lsp::path_to_regex::lexer (cyclomatic 27) cli/lsp/path_to_regex.rs:66— deno::lsp::path_to_regex::lexer has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::fmt_editorconfig::parse (cyclomatic 26) cli/tools/fmt_editorconfig.rs:278— deno::tools::fmt_editorconfig::parse has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::lsp::diagnostics::diagnose_resolution (cyclomatic 25) cli/lsp/diagnostics.rs:1152— deno::lsp::diagnostics::diagnose_resolution has cyclomatic complexity 25 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::coverage::cover_files (cyclomatic 25) cli/tools/coverage/mod.rs:725— deno::tools::coverage::cover_files has cyclomatic complexity 25 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::tools::desktop_devtools::run_unified_session (cyclomatic 25) cli/tools/desktop_devtools.rs:980— deno::tools::desktop_devtools::run_unified_session has cyclomatic complexity 25 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::lint::ast_buffer::swc::serialize_module_decl (cyclomatic 25) cli/tools/lint/ast_buffer/swc.rs:153— deno::tools::lint::ast_buffer::swc::serialize_module_decl has cyclomatic complexity 25 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno::tools::pm::interactive_picker::select_items (cyclomatic 24) cli/tools/pm/interactive_picker.rs:22— deno::tools::pm::interactive_picker::select_items has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::transpile::transpile (cyclomatic 24) cli/tools/transpile.rs:26— deno::tools::transpile::transpile has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno::tools::x::run (cyclomatic 24) cli/tools/x.rs:536— deno::tools::x::run has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Duplicated block (8 lines × 2) cli/lsp/diagnostics.rs:1810— cli/lsp/diagnostics.rs:1810-1820 | cli/lsp/diagnostics.rs:1837-1844 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) cli/ops/bench.rs:111— cli/ops/bench.rs:111-118 | cli/ops/testing.rs:146-153 — before extracting anything, compare `cli/ops/bench.rs` and `cli/ops/testing.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 39 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 2) cli/standalone/binary.rs:496— cli/standalone/binary.rs:496-503 | cli/standalone/binary.rs:571-578 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) cli/standalone/native_addons.rs:267— cli/standalone/native_addons.rs:267-274 | cli/tools/compile.rs:452-459 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (8 lines × 2) cli/tools/compile.rs:642— cli/tools/compile.rs:642-649 | cli/tools/compile.rs:908-915 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) cli/tools/pm/list.rs:35— cli/tools/pm/list.rs:35-42 | cli/tools/pm/why.rs:29-37 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (8 lines × 2) cli/tsc/tsconfig_gen.rs:1024— cli/tsc/tsconfig_gen.rs:1024-1031 | cli/tsc/tsconfig_gen.rs:1047-1054 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/crypto/node_interop.rs:123— ext/crypto/node_interop.rs:123-130 | ext/crypto/subtle_get_public_key.rs:131-138 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (8 lines × 2) ext/crypto/subtle_decrypt.rs:497— ext/crypto/subtle_decrypt.rs:497-504 | ext/crypto/subtle_decrypt.rs:531-538 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/crypto/subtle_import_key.rs:748— ext/crypto/subtle_import_key.rs:748-755 | ext/crypto/subtle_import_key.rs:874-881 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/crypto/subtle_import_key.rs:1525— ext/crypto/subtle_import_key.rs:1525-1532 | ext/crypto/subtle_import_key.rs:1573-1580 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/fs/ops.rs:1494— ext/fs/ops.rs:1494-1501 | ext/fs/ops.rs:1637-1644 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/fs/ops.rs:1787— ext/fs/ops.rs:1787-1794 | ext/fs/ops.rs:1928-1935 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node/ops/http2/session.rs:879— ext/node/ops/http2/session.rs:879-886 | ext/node/ops/http2/session.rs:992-999 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node/ops/http2/stream.rs:425— ext/node/ops/http2/stream.rs:425-432 | ext/node/ops/tls_wrap.rs:2831-2838 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (8 lines × 2) ext/node/ops/stream_wrap.rs:424— ext/node/ops/stream_wrap.rs:424-431 | ext/node/ops/tls_wrap.rs:2491-2498 — before extracting anything, compare `ext/node/ops/stream_wrap.rs` and `ext/node/ops/tls_wrap.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 2) ext/node/ops/tcp_wrap.rs:855— ext/node/ops/tcp_wrap.rs:855-862 | ext/node/ops/tcp_wrap.rs:885-892 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node/ops/tls_wrap.rs:2996— ext/node/ops/tls_wrap.rs:2996-3007 | ext/node/ops/tls_wrap.rs:3017-3024 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node/ops/vm.rs:1547— ext/node/ops/vm.rs:1547-1554 | ext/node/ops/vm.rs:1558-1565 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node_crypto/keys.rs:2762— ext/node_crypto/keys.rs:2762-2769 | ext/node_crypto/keys.rs:2819-2826 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node_crypto/keys.rs:3624— ext/node_crypto/keys.rs:3624-3631 | ext/node_crypto/keys.rs:4095-4102 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/node_crypto/lib.rs:405— ext/node_crypto/lib.rs:405-412 | ext/node_crypto/lib.rs:454-461 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/telemetry/lib.rs:1990— ext/telemetry/lib.rs:1990-1997 | ext/telemetry/lib.rs:2639-2646 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/web/console/inspect.rs:1565— ext/web/console/inspect.rs:1565-1572 | ext/web/console/inspect.rs:3049-3056 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 2) ext/web/css_value.rs:1001— ext/web/css_value.rs:1001-1008 | ext/web/css_value.rs:1015-1022 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
ClassTooLong: Inner cli/lsp/language_server.rs:305— ClassTooLong — 2878 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 75 methods, 5 blocks, lines 305-4813. The bar is 400 significant lines; this is 2478 over it, 7.20× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: TsEsTreeBuilder cli/tools/lint/ast_buffer/ts_estree.rs:476— ClassTooLong — 1882 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 155 methods, 3 blocks, lines 476-2898. The bar is 400 significant lines; this is 1482 over it, 4.71× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: OptionsParser libs/node_shim/lib.rs:776— ClassTooLong — 1809 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 13 methods, 3 blocks, lines 776-3074. The bar is 400 significant lines; this is 1409 over it, 4.52× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: GraphDependencyResolver libs/npm/resolution/graph.rs:1106— ClassTooLong — 1456 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 27 methods, 2 blocks, lines 1106-3418. The bar is 400 significant lines; this is 1056 over it, 3.64× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: WasiContext ext/node/ops/wasi.rs:416— ClassTooLong — 1207 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 47 methods, 3 blocks, lines 416-2262. The bar is 400 significant lines; this is 807 over it, 3.02× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: ModuleMap libs/core/modules/map.rs:110— ClassTooLong — 1005 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 76 methods, 2 blocks, lines 110-1761. The bar is 400 significant lines; this is 605 over it, 2.51× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: TsJsServer cli/lsp/tsc.rs:251— ClassTooLong — 994 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 36 methods, 3 blocks, lines 251-1619. The bar is 400 significant lines; this is 594 over it, 2.49× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: TsServer cli/lsp/ts_server.rs:37— ClassTooLong — 968 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 29 methods, 2 blocks, lines 37-1310. The bar is 400 significant lines; this is 568 over it, 2.42× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: Workspace libs/config/workspace/mod.rs:540— ClassTooLong — 891 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 51 methods, 2 blocks, lines 540-1854. The bar is 400 significant lines; this is 491 over it, 2.23× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: DenoCompileBinaryWriter cli/standalone/binary.rs:367— ClassTooLong — 883 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 10 methods, 2 blocks, lines 367-1616. The bar is 400 significant lines; this is 483 over it, 2.21× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: DatabaseSync ext/node_sqlite/database.rs:648— ClassTooLong — 866 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 20 methods, 4 blocks, lines 648-2601. The bar is 400 significant lines; this is 466 over it, 2.17× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: CliFactory cli/factory.rs:340— ClassTooLong — 858 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 68 methods, 2 blocks, lines 340-1550. The bar is 400 significant lines; this is 458 over it, 2.15× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: DOMMatrixReadOnly ext/web/geometry.rs:1256— ClassTooLong — 824 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 86 methods, 4 blocks, lines 1256-2408. The bar is 400 significant lines; this is 424 over it, 2.06× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: TLSWrap ext/node/ops/tls_wrap.rs:2077— ClassTooLong — 808 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 50 methods, 6 blocks, lines 2077-4802. The bar is 400 significant lines; this is 408 over it, 2.02× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: LocalNpmPackageInstaller libs/npm_installer/local.rs:109— ClassTooLong — 777 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 3 methods, 4 blocks, lines 109-1281. The bar is 400 significant lines; this is 377 over it, 1.94× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: ConfigFile libs/config/deno_json/mod.rs:1730— ClassTooLong — 752 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 48 methods, 2 blocks, lines 1730-2829. The bar is 400 significant lines; this is 352 over it, 1.88× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: EmbeddedModuleLoader cli/rt/run.rs:157— ClassTooLong — 710 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 3 methods, 5 blocks, lines 157-1211. The bar is 400 significant lines; this is 310 over it, 1.78× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: CliOptions cli/args/mod.rs:553— ClassTooLong — 698 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 88 methods, 2 blocks, lines 553-1622. The bar is 400 significant lines; this is 298 over it, 1.75× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: LibUvStreamWrap ext/node/ops/stream_wrap.rs:210— ClassTooLong — 693 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 37 methods, 6 blocks, lines 210-2066. The bar is 400 significant lines; this is 293 over it, 1.73× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: WorkspaceDirectory libs/config/workspace/mod.rs:1918— ClassTooLong — 685 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 39 methods, 2 blocks, lines 1918-2850. The bar is 400 significant lines; this is 285 over it, 1.71× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: EszipV2 libs/eszip/v2.rs:664— ClassTooLong — 675 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 16 methods, 3 blocks, lines 664-1742. The bar is 400 significant lines; this is 275 over it, 1.69× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: GPUDevice ext/webgpu/device.rs:49— ClassTooLong — 664 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 27 methods, 6 blocks, lines 49-970. The bar is 400 significant lines; this is 264 over it, 1.66× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: SharedConn libs/http_h1/conn.rs:288— ClassTooLong — 630 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 28 methods, 4 blocks, lines 288-1532. The bar is 400 significant lines; this is 230 over it, 1.58× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: DenoPluginHandler cli/tools/bundle/mod.rs:1479— ClassTooLong — 626 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 12 methods, 4 blocks, lines 1479-2525. The bar is 400 significant lines; this is 226 over it, 1.57× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
ClassTooLong: WorkspaceResolver libs/resolver/workspace.rs:842— ClassTooLong — 623 significant lines (blank, comment-only and punctuation-only lines excluded, and inline test code — #[cfg(test)] modules and bare #[test] functions — not counted), 19 methods, 2 blocks, lines 842-1785. The bar is 400 significant lines; this is 223 over it, 1.56× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
Duplicated block (10 lines × 2) cli/lib/standalone/virtual_fs.rs:895— cli/lib/standalone/virtual_fs.rs:895-904 | cli/lib/standalone/virtual_fs.rs:943-952 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/lsp/registries.rs:761— cli/lsp/registries.rs:761-770 | cli/lsp/registries.rs:927-936 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/tools/lint/ast_buffer/swc.rs:911— cli/tools/lint/ast_buffer/swc.rs:911-920 | cli/tools/lint/ast_buffer/swc.rs:1146-1155 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/tools/lint/ast_buffer/ts_estree.rs:758— cli/tools/lint/ast_buffer/ts_estree.rs:758-767 | cli/tools/lint/ast_buffer/ts_estree.rs:791-800 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/tools/pack/package_json.rs:121— cli/tools/pack/package_json.rs:121-130 | cli/tools/pack/package_json.rs:139-148 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/tools/pm/list.rs:339— cli/tools/pm/list.rs:339-348 | cli/tools/pm/mod.rs:1282-1291 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10 lines × 2) cli/tools/pm/mod.rs:579— cli/tools/pm/mod.rs:579-588 | cli/tools/pm/mod.rs:1253-1262 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) cli/tools/task.rs:1381— cli/tools/task.rs:1381-1390 | cli/tools/task.rs:1399-1408 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/canvas/canvas.rs:65— ext/canvas/canvas.rs:65-74 | ext/canvas/canvas.rs:90-99 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/crypto/node_interop.rs:104— ext/crypto/node_interop.rs:104-113 | ext/crypto/subtle_derive_bits.rs:401-410 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10 lines × 2) ext/crypto/node_interop.rs:339— ext/crypto/node_interop.rs:339-348 | ext/crypto/subtle_generate_key.rs:784-793 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10 lines × 2) ext/crypto/node_interop.rs:356— ext/crypto/node_interop.rs:356-365 | ext/crypto/subtle_import_key.rs:1928-1937 — before extracting anything, compare `ext/crypto/node_interop.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 2) ext/crypto/subtle_decrypt.rs:63— ext/crypto/subtle_decrypt.rs:63-72 | ext/crypto/subtle_encrypt.rs:63-72 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 2) ext/crypto/subtle_decrypt.rs:243— ext/crypto/subtle_decrypt.rs:243-252 | ext/crypto/subtle_encrypt.rs:298-307 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 2) ext/crypto/subtle_derive_bits.rs:659— ext/crypto/subtle_derive_bits.rs:659-668 | ext/crypto/subtle_key.rs:195-204 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_key.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 2) ext/crypto/subtle_key.rs:130— ext/crypto/subtle_key.rs:130-139 | ext/crypto/subtle_key.rs:148-157 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/ffi/callback.rs:61— ext/ffi/callback.rs:61-70 | ext/ffi/dlfcn.rs:206-215 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10 lines × 2) ext/http/http_next.rs:5468— ext/http/http_next.rs:5468-5477 | ext/http/http_next.rs:5550-5559 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/http/request_properties.rs:166— ext/http/request_properties.rs:166-175 | ext/http/request_properties.rs:233-242 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/io/lib.rs:1072— ext/io/lib.rs:1072-1081 | ext/io/lib.rs:1083-1092 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/napi/js_native_api.rs:1096— ext/napi/js_native_api.rs:1096-1105 | ext/napi/js_native_api.rs:1162-1171 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/napi/js_native_api.rs:2707— ext/napi/js_native_api.rs:2707-2716 | ext/napi/js_native_api.rs:2735-2744 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/node/ops/fs.rs:3131— ext/node/ops/fs.rs:3131-3140 | ext/node/ops/fs.rs:3335-3344 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/node/ops/fs.rs:3302— ext/node/ops/fs.rs:3302-3311 | ext/node/ops/fs.rs:3564-3574 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 2) ext/node/ops/stream_wrap.rs:942— ext/node/ops/stream_wrap.rs:942-951 | ext/node/ops/stream_wrap.rs:1010-1019 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/http_util.rs:429— cli/http_util.rs:429-434 | cli/http_util.rs:447-452 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/lsp/tsc.rs:5857— cli/lsp/tsc.rs:5857-5862 | runtime/web_worker.rs:742-747 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (6 lines × 2) cli/tools/bundle/mod.rs:135— cli/tools/bundle/mod.rs:135-140 | cli/tools/bundle/mod.rs:209-214 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/tools/fmt.rs:432— cli/tools/fmt.rs:432-437 | cli/tools/fmt.rs:1606-1611 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/tools/lint/ast_buffer/ts_estree.rs:828— cli/tools/lint/ast_buffer/ts_estree.rs:828-833 | cli/tools/lint/ast_buffer/ts_estree.rs:855-860 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/tools/lint/ast_buffer/ts_estree.rs:1174— cli/tools/lint/ast_buffer/ts_estree.rs:1174-1179 | cli/tools/lint/ast_buffer/ts_estree.rs:1192-1197 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) cli/tools/pm/list.rs:355— cli/tools/pm/list.rs:355-360 | cli/tools/pm/outdated/mod.rs:303-309 — before extracting anything, compare `cli/tools/pm/list.rs` and `cli/tools/pm/outdated/mod.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 33 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (6 lines × 2) ext/crypto/mldsa.rs:107— ext/crypto/mldsa.rs:107-112 | ext/crypto/mldsa.rs:271-276 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/crypto/mlkem.rs:199— ext/crypto/mlkem.rs:199-204 | ext/crypto/mlkem.rs:253-258 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/crypto/subtle_derive_bits.rs:608— ext/crypto/subtle_derive_bits.rs:608-613 | ext/crypto/subtle_derive_bits.rs:627-632 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/kv/lib.rs:800— ext/kv/lib.rs:800-806 | ext/kv/lib.rs:811-816 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/napi/js_native_api.rs:2622— ext/napi/js_native_api.rs:2622-2627 | ext/napi/js_native_api.rs:2649-2654 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/net/ops_tls.rs:174— ext/net/ops_tls.rs:174-179 | ext/net/ops_tls.rs:190-195 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/node/ops/http2/session.rs:1310— ext/node/ops/http2/session.rs:1310-1315 | ext/node/ops/http2/stream.rs:389-394 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (6 lines × 2) ext/node/ops/http2/stream.rs:384— ext/node/ops/http2/stream.rs:384-389 | ext/node/ops/http2/stream.rs:415-420 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/node/ops/pipe_wrap.rs:111— ext/node/ops/pipe_wrap.rs:111-116 | ext/node/ops/tcp_wrap.rs:113-118 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (6 lines × 2) ext/node/ops/tls_wrap.rs:554— ext/node/ops/tls_wrap.rs:554-559 | ext/node/ops/tty_wrap.rs:184-189 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (6 lines × 2) ext/node/ops/tls_wrap.rs:4908— ext/node/ops/tls_wrap.rs:4908-4913 | ext/node/ops/tls_wrap.rs:5402-5407 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/node_sqlite/backup.rs:66— ext/node_sqlite/backup.rs:66-71 | ext/node_sqlite/backup.rs:79-84 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/node_sqlite/sql_tag_store.rs:565— ext/node_sqlite/sql_tag_store.rs:565-570 | ext/node_sqlite/statement.rs:797-805 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (6 lines × 2) ext/process/lib.rs:812— ext/process/lib.rs:812-817 | ext/process/lib.rs:2136-2141 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/process/lib.rs:819— ext/process/lib.rs:819-824 | ext/process/lib.rs:2143-2148 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/process/lib.rs:1606— ext/process/lib.rs:1606-1611 | ext/process/lib.rs:1643-1648 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/telemetry/lib.rs:3029— ext/telemetry/lib.rs:3029-3034 | ext/telemetry/lib.rs:3181-3186 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 2) ext/web/console/inspect.rs:3124— ext/web/console/inspect.rs:3124-3129 | ext/web/console/inspect.rs:3151-3156 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) cli/module_loader.rs:1474— cli/module_loader.rs:1474-1482 | cli/rt/run.rs:955-963 — before extracting anything, compare `cli/module_loader.rs` and `cli/rt/run.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 34 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 2) cli/standalone/native_addons.rs:218— cli/standalone/native_addons.rs:218-226 | cli/standalone/native_addons.rs:237-245 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) cli/tools/desktop.rs:481— cli/tools/desktop.rs:481-489 | cli/tools/desktop.rs:1290-1298 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) cli/tools/installer/npm_compat.rs:1311— cli/tools/installer/npm_compat.rs:1311-1319 | cli/tsc/tsconfig_gen.rs:1027-1035 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (9 lines × 2) cli/tools/pm/cache_deps.rs:228— cli/tools/pm/cache_deps.rs:228-236 | cli/tools/pm/deps.rs:814-822 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (9 lines × 2) cli/tools/publish/wasm.rs:187— cli/tools/publish/wasm.rs:187-195 | cli/tools/publish/wasm.rs:233-241 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) cli/tsc/tsconfig_gen.rs:646— cli/tsc/tsconfig_gen.rs:646-654 | cli/tsc/tsconfig_gen.rs:704-712 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/canvas/byow.rs:123— ext/canvas/byow.rs:123-131 | ext/canvas/byow.rs:147-155 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/crypto/lib.rs:640— ext/crypto/lib.rs:640-648 | ext/crypto/lib.rs:666-674 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/crypto/make_key.rs:357— ext/crypto/make_key.rs:357-365 | ext/crypto/make_key.rs:398-406 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/crypto/node_interop.rs:131— ext/crypto/node_interop.rs:131-139 | ext/crypto/node_interop.rs:169-177 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/crypto/subtle_generate_key.rs:357— ext/crypto/subtle_generate_key.rs:357-365 | ext/crypto/subtle_generate_key.rs:388-396 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/fs/ops.rs:1162— ext/fs/ops.rs:1162-1170 | ext/fs/ops.rs:1250-1258 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/http/http_next.rs:2756— ext/http/http_next.rs:2756-2764 | ext/http/lib.rs:1452-1460 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (9 lines × 2) ext/http/http_next.rs:3997— ext/http/http_next.rs:3997-4005 | ext/http/http_next.rs:4365-4373 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/http/http_next.rs:4195— ext/http/http_next.rs:4195-4203 | ext/http/http_next.rs:4348-4356 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/io/bi_pipe.rs:155— ext/io/bi_pipe.rs:155-163 | ext/io/bi_pipe.rs:291-299 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/napi/js_native_api.rs:2599— ext/napi/js_native_api.rs:2599-2607 | ext/napi/js_native_api.rs:2677-2685 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/napi/js_native_api.rs:3225— ext/napi/js_native_api.rs:3225-3233 | ext/napi/js_native_api.rs:3275-3283 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node/ops/fs.rs:3288— ext/node/ops/fs.rs:3288-3296 | ext/node/ops/fs.rs:3543-3551 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node/ops/http2/session.rs:1014— ext/node/ops/http2/session.rs:1014-1022 | ext/node/ops/http2/session.rs:1081-1089 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node/ops/llhttp/binding.rs:960— ext/node/ops/llhttp/binding.rs:960-968 | ext/node/ops/llhttp/binding.rs:1041-1049 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node/ops/wasi.rs:1636— ext/node/ops/wasi.rs:1636-1644 | ext/node/ops/wasi.rs:1807-1815 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node_crypto/cipher.rs:127— ext/node_crypto/cipher.rs:127-135 | ext/node_crypto/cipher.rs:283-291 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 2) ext/node_sqlite/database.rs:482— ext/node_sqlite/database.rs:482-490 | ext/node_sqlite/database.rs:556-564 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) cli/tools/clean.rs:200— cli/tools/clean.rs:200-206 | cli/tools/clean.rs:221-227 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) cli/tools/desktop.rs:5523— cli/tools/desktop.rs:5523-5529 | cli/tools/desktop.rs:5595-5601 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) cli/tools/fmt.rs:295— cli/tools/fmt.rs:295-301 | cli/tools/lint/mod.rs:512-518 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (7 lines × 2) cli/tools/lint/ast_buffer/swc.rs:1640— cli/tools/lint/ast_buffer/swc.rs:1640-1650 | cli/tools/lint/ast_buffer/swc.rs:1682-1688 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) cli/tsc/tsconfig_gen.rs:283— cli/tsc/tsconfig_gen.rs:283-289 | cli/tsc/tsconfig_gen.rs:300-306 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) cli/tsc/tsconfig_gen.rs:1235— cli/tsc/tsconfig_gen.rs:1235-1241 | cli/tsc/tsconfig_gen.rs:1270-1276 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/cache/lsc_shard.rs:78— ext/cache/lsc_shard.rs:78-84 | ext/cache/lsc_shard.rs:112-118 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/canvas/byow.rs:221— ext/canvas/byow.rs:221-227 | ext/canvas/canvas.rs:126-133 — before extracting anything, compare `ext/canvas/byow.rs` and `ext/canvas/canvas.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 33 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 2) ext/crypto/subtle_crypto.rs:870— ext/crypto/subtle_crypto.rs:870-876 | ext/crypto/subtle_crypto.rs:922-928 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/crypto/subtle_decrypt.rs:494— ext/crypto/subtle_decrypt.rs:494-500 | ext/crypto/subtle_encrypt.rs:559-565 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 2) ext/crypto/subtle_import_key.rs:759— ext/crypto/subtle_import_key.rs:759-765 | ext/crypto/subtle_import_key.rs:885-891 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/crypto/subtle_import_key.rs:769— ext/crypto/subtle_import_key.rs:769-775 | ext/crypto/subtle_import_key.rs:895-901 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/fs/ops.rs:830— ext/fs/ops.rs:830-836 | ext/fs/ops.rs:886-892 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/http/http_next.rs:3945— ext/http/http_next.rs:3945-3951 | ext/http/http_next.rs:4401-4408 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/http/http_next.rs:3967— ext/http/http_next.rs:3967-3973 | ext/http/http_next.rs:4174-4181 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/http/http_next.rs:4301— ext/http/http_next.rs:4301-4307 | ext/http/http_next.rs:4472-4478 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/http/lib.rs:156— ext/http/lib.rs:156-162 | libs/cache_dir/file_fetcher/http_util.rs:29-35 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (7 lines × 2) ext/http/service.rs:1229— ext/http/service.rs:1229-1235 | ext/http/service.rs:1287-1293 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/napi/js_native_api.rs:877— ext/napi/js_native_api.rs:877-883 | ext/napi/js_native_api.rs:884-890 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/napi/uv.rs:997— ext/napi/uv.rs:997-1003 | ext/napi/uv.rs:1019-1025 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/node/ops/http2/session.rs:329— ext/node/ops/http2/session.rs:329-335 | ext/node/ops/http2/session.rs:2534-2540 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 2) ext/node/ops/inspector.rs:81— ext/node/ops/inspector.rs:81-87 | libs/cli_parser/src/convert.rs:57-63 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (7 lines × 2) ext/node/ops/pipe_wrap.rs:141— ext/node/ops/pipe_wrap.rs:141-147 | ext/node/ops/tcp_wrap.rs:142-148 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 2) ext/node/ops/require.rs:45— ext/node/ops/require.rs:45-51 | ext/node/ops/worker_threads.rs:38-44 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (7 lines × 2) ext/node/ops/tls.rs:429— ext/node/ops/tls.rs:429-435 | ext/node/ops/tls.rs:561-567 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) cli/lsp/testing/execution.rs:313— cli/lsp/testing/execution.rs:313-318 | cli/tools/bench/mod.rs:316-320 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (5 lines × 2) cli/tools/desktop.rs:1001— cli/tools/desktop.rs:1001-1005 | cli/tools/desktop.rs:1082-1086 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) cli/tools/desktop.rs:4223— cli/tools/desktop.rs:4223-4228 | cli/tools/desktop.rs:4254-4258 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) cli/tools/lint/ast_buffer/ts_estree.rs:2399— cli/tools/lint/ast_buffer/ts_estree.rs:2399-2403 | cli/tools/lint/ast_buffer/ts_estree.rs:2422-2426 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/ffi/ir.rs:508— ext/ffi/ir.rs:508-512 | ext/ffi/ir.rs:561-565 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/fs/ops.rs:1156— ext/fs/ops.rs:1156-1160 | ext/fs/ops.rs:1244-1248 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/fs.rs:285— ext/node/ops/fs.rs:285-289 | ext/node/ops/fs.rs:299-303 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/http2/session.rs:887— ext/node/ops/http2/session.rs:887-891 | ext/node/ops/http2/session.rs:1380-1385 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/http2/session.rs:909— ext/node/ops/http2/session.rs:909-913 | ext/node/ops/http2/session.rs:1198-1202 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/llhttp/binding.rs:436— ext/node/ops/llhttp/binding.rs:436-440 | ext/node/ops/llhttp/binding.rs:661-665 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/pipe_wrap.rs:149— ext/node/ops/pipe_wrap.rs:149-153 | ext/node/ops/tcp_wrap.rs:150-154 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (5 lines × 2) ext/node/ops/tls_wrap.rs:4969— ext/node/ops/tls_wrap.rs:4969-4974 | ext/node/ops/tls_wrap.rs:5426-5430 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node/ops/zlib/mod.rs:917— ext/node/ops/zlib/mod.rs:917-921 | ext/node/ops/zlib/mod.rs:1003-1007 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node_crypto/keys.rs:390— ext/node_crypto/keys.rs:390-394 | ext/node_crypto/keys.rs:410-414 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node_crypto/x509.rs:735— ext/node_crypto/x509.rs:735-739 | ext/node_crypto/x509.rs:1294-1301 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/node_sqlite/backup.rs:92— ext/node_sqlite/backup.rs:92-96 | ext/node_sqlite/database.rs:268-272 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (5 lines × 2) ext/web/console/css.rs:280— ext/web/console/css.rs:280-284 | ext/web/console/css.rs:297-301 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/web/console/inspect.rs:2024— ext/web/console/inspect.rs:2024-2028 | ext/web/console/inspect.rs:2036-2040 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/web/geometry.rs:235— ext/web/geometry.rs:235-239 | ext/web/geometry.rs:271-275 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/web/geometry.rs:310— ext/web/geometry.rs:310-314 | ext/web/geometry.rs:322-326 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) ext/websocket/lib.rs:788— ext/websocket/lib.rs:788-792 | ext/websocket/lib.rs:831-837 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) libs/core/convert.rs:569— libs/core/convert.rs:569-573 | libs/serde_v8/magic/external_pointer.rs:37-41 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (5 lines × 2) libs/core/inspector.rs:2186— libs/core/inspector.rs:2186-2190 | libs/core/inspector.rs:2213-2217 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) libs/core/modules/map/evaluation.rs:140— libs/core/modules/map/evaluation.rs:140-144 | libs/core/modules/map/evaluation.rs:153-157 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (5 lines × 2) libs/core/ops_builtin.rs:809— libs/core/ops_builtin.rs:809-813 | libs/core/ops_builtin.rs:868-872 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/lib/worker.rs:1030— cli/lib/worker.rs:1030-1041 | cli/worker.rs:264-275 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (12 lines × 2) cli/lsp/documents.rs:679— cli/lsp/documents.rs:679-690 | cli/lsp/documents.rs:737-748 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/lsp/performance.rs:166— cli/lsp/performance.rs:166-177 | cli/lsp/performance.rs:198-209 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/lsp/tsc.rs:1017— cli/lsp/tsc.rs:1017-1028 | cli/lsp/tsc.rs:1150-1161 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/lsp/tsc.rs:1645— cli/lsp/tsc.rs:1645-1656 | cli/lsp/tsc.rs:1676-1687 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/rt_desktop/lib.rs:1040— cli/rt_desktop/lib.rs:1040-1051 | cli/rt_desktop/lib.rs:1092-1103 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) cli/tools/bump_version.rs:37— cli/tools/bump_version.rs:37-48 | cli/tools/pm/mod.rs:97-108 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (12 lines × 2) cli/tools/pm/mod.rs:1147— cli/tools/pm/mod.rs:1147-1158 | cli/tools/pm/mod.rs:1165-1176 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/crypto/digest.rs:396— ext/crypto/digest.rs:396-407 | ext/crypto/subtle_sign.rs:332-343 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_sign.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 39 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 2) ext/crypto/import_key.rs:890— ext/crypto/import_key.rs:890-901 | ext/crypto/import_key.rs:906-917 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/crypto/subtle_derive_bits.rs:355— ext/crypto/subtle_derive_bits.rs:355-366 | ext/crypto/subtle_key.rs:73-84 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_key.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 2) ext/crypto/subtle_generate_key.rs:548— ext/crypto/subtle_generate_key.rs:548-559 | ext/crypto/subtle_generate_key.rs:569-580 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/crypto/subtle_sign.rs:468— ext/crypto/subtle_sign.rs:468-479 | ext/crypto/subtle_verify.rs:290-301 — before extracting anything, compare `ext/crypto/subtle_sign.rs` and `ext/crypto/subtle_verify.rs` as WHOLE FILES: this scan already matched 6 separate duplicated blocks between them, totalling at least 160 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 2) ext/fs/ops.rs:1588— ext/fs/ops.rs:1588-1599 | ext/fs/ops.rs:1654-1665 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/http/http_next.rs:1643— ext/http/http_next.rs:1643-1654 | ext/http/http_next.rs:1682-1693 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node/ops/inspector.rs:383— ext/node/ops/inspector.rs:383-394 | ext/node/ops/inspector.rs:435-446 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node/ops/tls.rs:412— ext/node/ops/tls.rs:412-423 | ext/node/ops/tls.rs:531-542 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node/ops/tls_wrap.rs:2706— ext/node/ops/tls_wrap.rs:2706-2717 | ext/node/ops/tls_wrap.rs:2728-2739 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node/ops/wasi.rs:609— ext/node/ops/wasi.rs:609-620 | ext/node/ops/wasi.rs:655-666 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node/ops/wasi.rs:1256— ext/node/ops/wasi.rs:1256-1267 | ext/node/ops/wasi.rs:1832-1843 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/node_crypto/cipher.rs:1047— ext/node_crypto/cipher.rs:1047-1058 | ext/node_crypto/cipher.rs:1533-1544 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) ext/webgpu/buffer.rs:239— ext/webgpu/buffer.rs:239-250 | ext/webgpu/queue.rs:101-112 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (12 lines × 2) libs/cli_parser/src/convert.rs:622— libs/cli_parser/src/convert.rs:622-633 | libs/cli_parser/src/convert.rs:3108-3119 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) libs/cli_parser/src/convert.rs:1001— libs/cli_parser/src/convert.rs:1001-1012 | libs/cli_parser/src/convert.rs:1041-1052 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 2) libs/config/workspace/mod.rs:1407— libs/config/workspace/mod.rs:1407-1418 | libs/config/workspace/mod.rs:1421-1432 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/lsp/language_server.rs:1740— cli/lsp/language_server.rs:1740-1750 | cli/lsp/language_server.rs:1788-1798 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/lsp/registries.rs:794— cli/lsp/registries.rs:794-804 | cli/lsp/registries.rs:939-949 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/standalone/binary.rs:482— cli/standalone/binary.rs:482-492 | cli/standalone/binary.rs:557-567 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/tools/desktop.rs:1018— cli/tools/desktop.rs:1018-1028 | cli/tools/desktop.rs:1113-1123 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/tools/publish/graph.rs:69— cli/tools/publish/graph.rs:69-79 | cli/tools/publish/graph.rs:95-105 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) cli/tools/repl/session.rs:689— cli/tools/repl/session.rs:689-699 | cli/tools/repl/session.rs:724-734 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/crypto/subtle_derive_bits.rs:291— ext/crypto/subtle_derive_bits.rs:291-301 | ext/crypto/subtle_sign.rs:301-311 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_sign.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 46 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 2) ext/fs/ops.rs:313— ext/fs/ops.rs:313-323 | ext/fs/ops.rs:332-342 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/http/http_next.rs:1901— ext/http/http_next.rs:1901-1911 | ext/http/http_next.rs:1919-1929 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/http/http_next.rs:2121— ext/http/http_next.rs:2121-2131 | ext/http/http_next.rs:2216-2226 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/fs.rs:1046— ext/node/ops/fs.rs:1046-1056 | ext/node/ops/fs.rs:1070-1080 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/http2/stream.rs:60— ext/node/ops/http2/stream.rs:60-70 | ext/node/ops/http2/stream.rs:72-82 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/pipe_wrap.rs:154— ext/node/ops/pipe_wrap.rs:154-164 | ext/node/ops/tcp_wrap.rs:155-165 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 2) ext/node/ops/tls_wrap.rs:1782— ext/node/ops/tls_wrap.rs:1782-1792 | ext/node/ops/tls_wrap.rs:3401-3411 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/tls_wrap.rs:2126— ext/node/ops/tls_wrap.rs:2126-2136 | ext/node/ops/tls_wrap.rs:2184-2194 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/wasi.rs:770— ext/node/ops/wasi.rs:770-780 | ext/node/ops/wasi.rs:2212-2222 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/wasi.rs:837— ext/node/ops/wasi.rs:837-847 | ext/node/ops/wasi.rs:2147-2157 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node/ops/wasi.rs:1595— ext/node/ops/wasi.rs:1595-1605 | ext/node/ops/wasi.rs:1739-1749 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/node_crypto/sign.rs:405— ext/node_crypto/sign.rs:405-415 | ext/node_crypto/sign.rs:582-592 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/web/css_value.rs:2545— ext/web/css_value.rs:2545-2555 | ext/web/css_value.rs:2560-2570 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) ext/web/geometry.rs:2206— ext/web/geometry.rs:2206-2216 | ext/web/geometry.rs:2843-2853 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) libs/core/error.rs:989— libs/core/error.rs:989-999 | libs/core/error.rs:1184-1194 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) libs/core/modules/map/ext_script.rs:687— libs/core/modules/map/ext_script.rs:687-697 | libs/core/modules/map/ext_script.rs:731-741 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) libs/core/ops_builtin_v8.rs:335— libs/core/ops_builtin_v8.rs:335-345 | libs/core/ops_builtin_v8.rs:472-482 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 2) libs/core/runtime/jsruntime.rs:1841— libs/core/runtime/jsruntime.rs:1841-1851 | libs/core/runtime/jsruntime.rs:1872-1882 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) cli/lib/standalone/binary.rs:256— cli/lib/standalone/binary.rs:256-268 | cli/tsc/mod.rs:565-577 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (13 lines × 2) cli/lsp/tsc.rs:1273— cli/lsp/tsc.rs:1273-1285 | cli/lsp/tsc.rs:1554-1566 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) cli/tools/lint/ast_buffer/swc.rs:1443— cli/tools/lint/ast_buffer/swc.rs:1443-1455 | cli/tools/lint/ast_buffer/swc.rs:1472-1484 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) cli/tsc/mod.rs:753— cli/tsc/mod.rs:753-765 | cli/tsc/mod.rs:843-855 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/crypto/shared.rs:243— ext/crypto/shared.rs:243-255 | ext/crypto/shared.rs:382-394 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/crypto/subtle_decrypt.rs:321— ext/crypto/subtle_decrypt.rs:321-333 | ext/crypto/subtle_encrypt.rs:377-389 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (13 lines × 2) ext/crypto/subtle_export_key.rs:749— ext/crypto/subtle_export_key.rs:749-761 | ext/crypto/subtle_export_key.rs:829-841 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/crypto/subtle_import_key.rs:1131— ext/crypto/subtle_import_key.rs:1131-1143 | ext/crypto/subtle_import_key.rs:1151-1163 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/http/http_next.rs:2767— ext/http/http_next.rs:2767-2779 | ext/http/lib.rs:1467-1479 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (13 lines × 2) ext/http/http_next.rs:3648— ext/http/http_next.rs:3648-3660 | ext/http/http_next.rs:3977-3989 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/http/http_next.rs:5478— ext/http/http_next.rs:5478-5490 | ext/http/http_next.rs:5560-5572 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/http/response_body.rs:177— ext/http/response_body.rs:177-189 | ext/http/response_body.rs:195-207 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/kv/lib.rs:357— ext/kv/lib.rs:357-369 | ext/kv/lib.rs:898-910 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/dns.rs:144— ext/node/ops/dns.rs:144-156 | ext/node/ops/dns.rs:235-247 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/fs.rs:682— ext/node/ops/fs.rs:682-694 | ext/node/ops/fs.rs:720-732 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/fs.rs:1516— ext/node/ops/fs.rs:1516-1528 | ext/node/ops/fs.rs:1696-1708 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/http2/session.rs:2982— ext/node/ops/http2/session.rs:2982-2994 | ext/node/ops/http2/stream.rs:591-603 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (13 lines × 2) ext/node/ops/llhttp/binding.rs:331— ext/node/ops/llhttp/binding.rs:331-343 | ext/node/ops/llhttp/binding.rs:673-685 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/stream_wrap.rs:1421— ext/node/ops/stream_wrap.rs:1421-1433 | ext/node/ops/stream_wrap.rs:1920-1932 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node/ops/wasi.rs:2153— ext/node/ops/wasi.rs:2153-2165 | ext/node/ops/wasi.rs:2218-2230 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node_crypto/cipher.rs:1651— ext/node_crypto/cipher.rs:1651-1663 | ext/node_crypto/cipher.rs:1665-1677 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node_crypto/keys.rs:1562— ext/node_crypto/keys.rs:1562-1574 | ext/node_crypto/keys.rs:1590-1602 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/node_crypto/sign.rs:332— ext/node_crypto/sign.rs:332-344 | ext/node_crypto/sign.rs:541-553 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/web/console/error_fmt.rs:53— ext/web/console/error_fmt.rs:53-65 | ext/web/console/error_fmt.rs:69-81 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13 lines × 2) ext/webgpu/device.rs:546— ext/webgpu/device.rs:546-558 | ext/webgpu/device.rs:571-583 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Sync-over-async blocking ext/node/polyfills/_fs/_fs_glob.ts:1085— `#cache.statSync` in `#iterateSubpatterns` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking ext/node/polyfills/_fs/_fs_glob.ts:1101— `#cache.statSync` in `#iterateSubpatterns` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:12— `Deno.mkdirSync` in `removeDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:13— `Deno.statSync` in `removeDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:18— `Deno.statSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:32— `Deno.writeFileSync` in `removeFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:33— `Deno.statSync` in `removeFileSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:38— `Deno.statSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:57— `Deno.writeFileSync` in `removeFileByUrl` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:58— `Deno.statSync` in `removeFileByUrl` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:63— `Deno.statSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:76— `Deno.mkdirSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:77— `Deno.mkdirSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:78— `Deno.statSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:80— `Deno.statSync` in `removeFail` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:110— `Deno.symlinkSync` in `removeDanglingSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:114— `Deno.symlinkSync` in `removeDanglingSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:116— `Deno.lstatSync` in `removeDanglingSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:120— `Deno.lstatSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:135— `Deno.writeFileSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:137— `Deno.symlinkSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:139— `Deno.symlinkSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:141— `Deno.statSync` in `removeValidSymlinkSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:145— `Deno.statSync` in `callback to assertThrows` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Sync-over-async blocking tests/unit/remove_test.ts:166— `Deno.mkdirSync` in `removeAllDirSuccess` blocks the event loop until it finishes — a blocking call inside async code stalls the event loop — every other request waits for as long as it runs.
Duplicated block (14 lines × 2) cli/graph_util.rs:458— cli/graph_util.rs:458-471 | cli/tools/compile.rs:1178-1191 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (14 lines × 2) cli/lsp/completions.rs:697— cli/lsp/completions.rs:697-710 | cli/lsp/completions.rs:856-869 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) cli/lsp/language_server.rs:2797— cli/lsp/language_server.rs:2797-2810 | cli/lsp/language_server.rs:3425-3438 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) cli/lsp/language_server.rs:3300— cli/lsp/language_server.rs:3300-3313 | cli/lsp/language_server.rs:3343-3356 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) cli/lsp/language_server.rs:3512— cli/lsp/language_server.rs:3512-3525 | cli/lsp/language_server.rs:3549-3562 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) cli/lsp/testing/execution.rs:808— cli/lsp/testing/execution.rs:808-821 | cli/lsp/testing/execution.rs:997-1010 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) cli/rt/run.rs:1624— cli/rt/run.rs:1624-1637 | libs/resolver/workspace.rs:1276-1289 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (14 lines × 2) cli/tools/pm/list.rs:321— cli/tools/pm/list.rs:321-334 | cli/tools/pm/outdated/mod.rs:280-293 — before extracting anything, compare `cli/tools/pm/list.rs` and `cli/tools/pm/outdated/mod.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 33 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (14 lines × 2) cli/tools/repl/session.rs:644— cli/tools/repl/session.rs:644-657 | cli/tools/repl/session.rs:669-682 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/crypto/subtle_get_public_key.rs:74— ext/crypto/subtle_get_public_key.rs:74-87 | ext/crypto/subtle_get_public_key.rs:117-130 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/ffi/ir.rs:647— ext/ffi/ir.rs:647-660 | ext/ffi/ir.rs:730-743 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/node/ops/fs.rs:68— ext/node/ops/fs.rs:68-81 | ext/process/lib.rs:105-118 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (14 lines × 2) ext/node/ops/fs.rs:377— ext/node/ops/fs.rs:377-390 | ext/node/ops/fs.rs:438-451 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/node/ops/fs.rs:395— ext/node/ops/fs.rs:395-408 | ext/node/ops/fs.rs:456-469 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/node/ops/fs.rs:3160— ext/node/ops/fs.rs:3160-3173 | ext/node/ops/fs.rs:3389-3402 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/node/ops/process.rs:539— ext/node/ops/process.rs:539-552 | ext/os/lib.rs:716-729 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (14 lines × 2) ext/node_crypto/cipher.rs:70— ext/node_crypto/cipher.rs:70-83 | ext/node_crypto/cipher.rs:216-229 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/process/lib.rs:848— ext/process/lib.rs:848-861 | ext/process/lib.rs:978-991 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/web/console/mod.rs:841— ext/web/console/mod.rs:841-854 | ext/web/console/mod.rs:875-888 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/web/geometry.rs:1022— ext/web/geometry.rs:1022-1035 | ext/web/geometry.rs:1091-1104 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/web/url.rs:96— ext/web/url.rs:96-109 | ext/web/url.rs:365-378 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) ext/webgpu/webidl.rs:53— ext/webgpu/webidl.rs:53-66 | ext/webgpu/webidl.rs:163-176 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) libs/config/workspace/discovery.rs:384— libs/config/workspace/discovery.rs:384-397 | libs/config/workspace/discovery.rs:478-491 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) libs/config/workspace/discovery.rs:504— libs/config/workspace/discovery.rs:504-517 | libs/config/workspace/discovery.rs:615-628 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 2) libs/core/runtime/op_driver/futures_unordered_driver.rs:155— libs/core/runtime/op_driver/futures_unordered_driver.rs:155-168 | libs/core/runtime/op_driver/futures_unordered_driver.rs:197-210 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
deno_core::uv_compat::pipe::poll_pipe_handle (cognitive 208) REDACTED:1759— deno_core::uv_compat::pipe::poll_pipe_handle has cognitive complexity 208 (threshold 15). Drivers by points: if/else 69 (168 pts), match/switch 7 (21 pts), boolean chains 12, loops 4 (7 pts) (nesting depth added 116). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_core::uv_compat::tty::poll_tty_handle (cognitive 167) libs/core/uv_compat/tty.rs:2188— deno_core::uv_compat::tty::poll_tty_handle has cognitive complexity 167 (threshold 15). Drivers by points: if/else 39 (122 pts), match/switch 4 (24 pts), boolean chains 11, loops 3 (10 pts) (nesting depth added 110). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_core::uv_compat::tcp::poll_tcp_handle (cognitive 161) libs/core/uv_compat/tcp.rs:1271— deno_core::uv_compat::tcp::poll_tcp_handle has cognitive complexity 161 (threshold 15). Drivers by points: if/else 41 (100 pts), loops 10 (31 pts), match/switch 5 (18 pts), boolean chains 12 (nesting depth added 93). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_core::uv_compat::pipe::poll_pipe_handle (cognitive 146) REDACTED:1404— deno_core::uv_compat::pipe::poll_pipe_handle has cognitive complexity 146 (threshold 15). Drivers by points: if/else 49 (112 pts), match/switch 6 (19 pts), boolean chains 14, loops 1 (nesting depth added 76). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_core::uv_compat::tty::tty_try_read_raw (cognitive 61) libs/core/uv_compat/tty.rs:1052— deno_core::uv_compat::tty::tty_try_read_raw has cognitive complexity 61 (threshold 15). Drivers by points: if/else 23 (47 pts), match/switch 2 (6 pts), boolean chains 5, loops 2 (3 pts) (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::inspector::pump_inspector_session_messages (cognitive 56) libs/core/inspector.rs:2051— deno_core::inspector::pump_inspector_session_messages has cognitive complexity 56 (threshold 15). Drivers by points: if/else 16 (44 pts), match/switch 2 (6 pts), loops 2 (5 pts), boolean chains 1 (nesting depth added 35). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::tty::uv_tty_init (cognitive 50) libs/core/uv_compat/tty.rs:1263— deno_core::uv_compat::tty::uv_tty_init has cognitive complexity 50 (threshold 15). Drivers by points: if/else 21 (39 pts), match/switch 3 (7 pts), boolean chains 3, loops 1 (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::modules::map::wasm::render_js_wasm_module (cognitive 46) libs/core/modules/map/wasm.rs:175— deno_core::modules::map::wasm::render_js_wasm_module has cognitive complexity 46 (threshold 15). Drivers by points: if/else 17 (32 pts), loops 7 (14 pts) (nesting depth added 22). Of this number, 45 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::runtime::bindings::initialize_deno_core_ops_bindings (cognitive 46) libs/core/runtime/bindings.rs:421— deno_core::runtime::bindings::initialize_deno_core_ops_bindings has cognitive complexity 46 (threshold 15). Drivers by points: if/else 13 (28 pts), loops 7 (17 pts), boolean chains 1 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::runtime::bindings::upgrade_snapshotted_ops_with_fast_calls (cognitive 37) libs/core/runtime/bindings.rs:613— deno_core::runtime::bindings::upgrade_snapshotted_ops_with_fast_calls has cognitive complexity 37 (threshold 15). Drivers by points: if/else 12 (30 pts), loops 4 (6 pts), boolean chains 1 (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::pipe::uv_pipe_open (cognitive 35) REDACTED:342— deno_core::uv_compat::pipe::uv_pipe_open has cognitive complexity 35 (threshold 15). Drivers by points: if/else 12 (22 pts), match/switch 4 (13 pts) (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::stream::write_pipe (cognitive 35) libs/core/uv_compat/stream.rs:797— deno_core::uv_compat::stream::write_pipe has cognitive complexity 35 (threshold 15). Drivers by points: if/else 12 (17 pts), loops 3 (8 pts), match/switch 2 (7 pts), boolean chains 3 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::extension_set::into_sources_and_source_maps (cognitive 32) libs/core/extension_set.rs:349— deno_core::extension_set::into_sources_and_source_maps has cognitive complexity 32 (threshold 15). Drivers by points: if/else 8 (19 pts), loops 6 (11 pts), boolean chains 2 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::stream::uv_try_writev (cognitive 30) libs/core/uv_compat/stream.rs:256— deno_core::uv_compat::stream::uv_try_writev has cognitive complexity 30 (threshold 15). Drivers by points: if/else 9 (23 pts), loops 2 (4 pts), match/switch 2, boolean chains 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::error::format_frame (cognitive 29) libs/core/error.rs:2440— deno_core::error::format_frame has cognitive complexity 29 (threshold 15). Drivers by points: if/else 15 (25 pts), boolean chains 4 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::tcp::uv_listen (cognitive 26) libs/core/uv_compat/tcp.rs:1130— deno_core::uv_compat::tcp::uv_listen has cognitive complexity 26 (threshold 15). Drivers by points: if/else 9 (14 pts), match/switch 4 (12 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::stream::uv_writev_owned (cognitive 25) libs/core/uv_compat/stream.rs:448— deno_core::uv_compat::stream::uv_writev_owned has cognitive complexity 25 (threshold 15). Drivers by points: if/else 6 (16 pts), match/switch 2 (5 pts), loops 1 (3 pts), boolean chains 1 (nesting depth added 15). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_core::uv_compat::tty::uv_tty_set_mode (cognitive 24) libs/core/uv_compat/tty.rs:1518— deno_core::uv_compat::tty::uv_tty_set_mode has cognitive complexity 24 (threshold 15). Drivers by points: if/else 9 (17 pts), loops 2 (4 pts), match/switch 2, boolean chains 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::tty::write_tty (cognitive 24) libs/core/uv_compat/tty.rs:1837— deno_core::uv_compat::tty::write_tty has cognitive complexity 24 (threshold 15). Drivers by points: if/else 6 (13 pts), match/switch 2 (6 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::ops_builtin_v8::op_serialize (cognitive 22) libs/core/ops_builtin_v8.rs:849— deno_core::ops_builtin_v8::op_serialize has cognitive complexity 22 (threshold 15). Drivers by points: if/else 7 (15 pts), loops 2 (3 pts), match/switch 3, boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::tty::select_thread_main (cognitive 22) libs/core/uv_compat/tty.rs:2886— deno_core::uv_compat::tty::select_thread_main has cognitive complexity 22 (threshold 15). Drivers by points: if/else 9 (20 pts), boolean chains 1, loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::pipe::uv_pipe_connect (cognitive 20) REDACTED:981— deno_core::uv_compat::pipe::uv_pipe_connect has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (18 pts), boolean chains 1, match/switch 1 (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_core::ops_builtin_v8::op_deserialize (cognitive 19) libs/core/ops_builtin_v8.rs:962— deno_core::ops_builtin_v8::op_deserialize has cognitive complexity 19 (threshold 15). Drivers by points: match/switch 6 (12 pts), if/else 3 (4 pts), loops 1 (3 pts) (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_core::runtime::bindings::op_ctx_template_or_accessor (cognitive 18) libs/core/runtime/bindings.rs:808— deno_core::runtime::bindings::op_ctx_template_or_accessor has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11 (18 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_core::uv_compat::uv_guess_handle (cognitive 18) libs/core/uv_compat.rs:893— deno_core::uv_compat::uv_guess_handle has cognitive complexity 18 (threshold 15). Drivers by points: if/else 12 (14 pts), boolean chains 4 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
deno_web::console::inspect::format_raw (cognitive 170) ext/web/console/inspect.rs:1920— deno_web::console::inspect::format_raw has cognitive complexity 170 (threshold 15). Drivers by points: if/else 76 (136 pts), boolean chains 21, match/switch 7 (12 pts), loops 1 (nesting depth added 65). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::error_fmt::format_error (cognitive 121) ext/web/console/error_fmt.rs:687— deno_web::console::error_fmt::format_error has cognitive complexity 121 (threshold 15). Drivers by points: if/else 40 (95 pts), match/switch 7 (13 pts), boolean chains 7, loops 2 (6 pts) (nesting depth added 65). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::console::inspect::add_prototype_properties (cognitive 113) ext/web/console/inspect.rs:1494— deno_web::console::inspect::add_prototype_properties has cognitive complexity 113 (threshold 15). Drivers by points: if/else 30 (101 pts), loops 4 (9 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 77). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::console::apply_options (cognitive 97) ext/web/console/mod.rs:278— deno_web::console::apply_options has cognitive complexity 97 (threshold 15). Drivers by points: if/else 25 (75 pts), loops 4 (14 pts), match/switch 2 (6 pts), boolean chains 2 (nesting depth added 64). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::error_fmt::get_duplicate_error_frame_ranges (cognitive 71) ext/web/console/error_fmt.rs:264— deno_web::console::error_fmt::get_duplicate_error_frame_ranges has cognitive complexity 71 (threshold 15). Drivers by points: if/else 17 (52 pts), loops 6 (14 pts), boolean chains 3, match/switch 1 (2 pts) (nesting depth added 44). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect_args_impl (cognitive 69) ext/web/console/mod.rs:677— deno_web::console::inspect_args_impl has cognitive complexity 69 (threshold 15). Drivers by points: if/else 18 (59 pts), match/switch 1 (5 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 46). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::console::inspect::get_constructor_name (cognitive 69) ext/web/console/inspect.rs:1669— deno_web::console::inspect::get_constructor_name has cognitive complexity 69 (threshold 15). Drivers by points: if/else 19 (59 pts), match/switch 3 (6 pts), boolean chains 3, loops 1 (nesting depth added 43). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::console::inspect::format_property (cognitive 65) ext/web/console/inspect.rs:3528— deno_web::console::inspect::format_property has cognitive complexity 65 (threshold 15). Drivers by points: if/else 31 (54 pts), match/switch 5 (9 pts), boolean chains 2 (nesting depth added 27). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::width::ansi_sequence_len (cognitive 52) ext/web/console/width.rs:13— deno_web::console::width::ansi_sequence_len has cognitive complexity 52 (threshold 15). Drivers by points: loops 10 (20 pts), boolean chains 17, if/else 10 (15 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::reduce_to_single_string (cognitive 51) ext/web/console/inspect.rs:3742— deno_web::console::inspect::reduce_to_single_string has cognitive complexity 51 (threshold 15). Drivers by points: if/else 20 (48 pts), boolean chains 3 (nesting depth added 28). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::url::parse_simple_special_url (cognitive 49) ext/web/url.rs:112— deno_web::url::parse_simple_special_url has cognitive complexity 49 (threshold 15). Drivers by points: if/else 14 (32 pts), boolean chains 7, loops 4 (6 pts), match/switch 2 (4 pts) (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::css::parse_css (cognitive 48) ext/web/console/css.rs:342— deno_web::console::css::parse_css has cognitive complexity 48 (threshold 15). Drivers by points: if/else 15 (36 pts), loops 4 (8 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::group_array_elements (cognitive 45) ext/web/console/inspect.rs:3855— deno_web::console::inspect::group_array_elements has cognitive complexity 45 (threshold 15). Drivers by points: if/else 12 (27 pts), loops 6 (15 pts), boolean chains 3 (nesting depth added 24). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_web::console::inspect::get_keys (cognitive 42) ext/web/console/inspect.rs:1279— deno_web::console::inspect::get_keys has cognitive complexity 42 (threshold 15). Drivers by points: if/else 13 (28 pts), loops 4 (10 pts), match/switch 2 (4 pts) (nesting depth added 23). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::try_custom_inspect (cognitive 38) ext/web/console/inspect.rs:677— deno_web::console::inspect::try_custom_inspect has cognitive complexity 38 (threshold 15). Drivers by points: if/else 15 (29 pts), match/switch 4 (7 pts), boolean chains 1, loops 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::url::simple_special_host_is_canonical (cognitive 34) ext/web/url.rs:223— deno_web::url::simple_special_host_is_canonical has cognitive complexity 34 (threshold 15). Drivers by points: if/else 9 (21 pts), boolean chains 8, loops 2 (3 pts), match/switch 1 (2 pts) (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::js_parse_float (cognitive 32) ext/web/console/mod.rs:547— deno_web::console::js_parse_float has cognitive complexity 32 (threshold 15). Drivers by points: if/else 10 (16 pts), boolean chains 10, loops 3 (6 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::format_value (cognitive 32) ext/web/console/inspect.rs:562— deno_web::console::inspect::format_value has cognitive complexity 32 (threshold 15). Drivers by points: if/else 15 (23 pts), boolean chains 3, loops 1 (3 pts), match/switch 1 (3 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::css_stylesheet::split_top_level_rules (cognitive 32) ext/web/css_stylesheet.rs:60— deno_web::css_stylesheet::split_top_level_rules has cognitive complexity 32 (threshold 15). Drivers by points: if/else 10 (21 pts), loops 3 (7 pts), boolean chains 4 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::error_fmt::improve_stack (cognitive 30) ext/web/console/error_fmt.rs:131— deno_web::console::error_fmt::improve_stack has cognitive complexity 30 (threshold 15). Drivers by points: if/else 10 (20 pts), match/switch 2 (6 pts), boolean chains 4 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::format_special_array (cognitive 30) ext/web/console/inspect.rs:3028— deno_web::console::inspect::format_special_array has cognitive complexity 30 (threshold 15). Drivers by points: if/else 12 (25 pts), loops 2 (3 pts), boolean chains 1, match/switch 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::format_primitive (cognitive 29) ext/web/console/inspect.rs:1122— deno_web::console::inspect::format_primitive has cognitive complexity 29 (threshold 15). Drivers by points: if/else 13 (21 pts), loops 2 (6 pts), boolean chains 2 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::inspect::get_user_options (cognitive 26) ext/web/console/inspect.rs:806— deno_web::console::inspect::get_user_options has cognitive complexity 26 (threshold 15). Drivers by points: if/else 6 (16 pts), match/switch 5, loops 1 (3 pts), boolean chains 2 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::css::parse_css_color (cognitive 24) ext/web/console/css.rs:185— deno_web::console::css::parse_css_color has cognitive complexity 24 (threshold 15). Drivers by points: if/else 14 (19 pts), boolean chains 5 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_web::console::error_fmt::match_null_proto_error_start (cognitive 23) ext/web/console/error_fmt.rs:202— deno_web::console::error_fmt::match_null_proto_error_start has cognitive complexity 23 (threshold 15). Drivers by points: if/else 6 (13 pts), loops 2 (6 pts), boolean chains 4 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_crypto::supports_params_valid (cognitive 83) ext/crypto/subtle_crypto.rs:648— deno_crypto::subtle_crypto::supports_params_valid has cognitive complexity 83 (threshold 15). Drivers by points: if/else 21 (51 pts), boolean chains 21, match/switch 6 (11 pts) (nesting depth added 35). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_rsa (cognitive 60) ext/crypto/subtle_import_key.rs:340— deno_crypto::subtle_import_key::import_key_rsa has cognitive complexity 60 (threshold 15). Drivers by points: if/else 23 (46 pts), loops 2 (6 pts), match/switch 5, boolean chains 3 (nesting depth added 27). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_ec (cognitive 60) ext/crypto/subtle_import_key.rs:1075— deno_crypto::subtle_import_key::import_key_ec has cognitive complexity 60 (threshold 15). Drivers by points: if/else 21 (42 pts), match/switch 7 (9 pts), loops 2 (6 pts), boolean chains 3 (nesting depth added 27). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_wrap_key::jwk_to_utf8 (cognitive 57) ext/crypto/subtle_wrap_key.rs:291— deno_crypto::subtle_wrap_key::jwk_to_utf8 has cognitive complexity 57 (threshold 15). Drivers by points: if/else 37 (55 pts), loops 1 (2 pts) (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_okp (cognitive 45) ext/crypto/subtle_import_key.rs:1374— deno_crypto::subtle_import_key::import_key_okp has cognitive complexity 45 (threshold 15). Drivers by points: if/else 15 (36 pts), loops 2 (6 pts), boolean chains 2, match/switch 1 (nesting depth added 25). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::import_key::import_key_ec (cognitive 43) ext/crypto/import_key.rs:723— deno_crypto::import_key::import_key_ec has cognitive complexity 43 (threshold 15). Drivers by points: if/else 12 (34 pts), match/switch 5 (9 pts) (nesting depth added 26). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_derive_bits::run (cognitive 39) ext/crypto/subtle_derive_bits.rs:417— deno_crypto::subtle_derive_bits::run has cognitive complexity 39 (threshold 15). Drivers by points: if/else 22 (33 pts), match/switch 3 (5 pts), boolean chains 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_kmac (cognitive 38) ext/crypto/subtle_import_key.rs:1665— deno_crypto::subtle_import_key::import_key_kmac has cognitive complexity 38 (threshold 15). Drivers by points: if/else 13 (26 pts), loops 2 (6 pts), boolean chains 5, match/switch 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::export_key::export_key_ec (cognitive 35) ext/crypto/export_key.rs:252— deno_crypto::export_key::export_key_ec has cognitive complexity 35 (threshold 15). Drivers by points: if/else 12 (24 pts), match/switch 7 (11 pts) (nesting depth added 16). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_encrypt::run (cognitive 34) ext/crypto/subtle_encrypt.rs:480— deno_crypto::subtle_encrypt::run has cognitive complexity 34 (threshold 15). Drivers by points: if/else 14 (26 pts), match/switch 3 (5 pts), boolean chains 3 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::verify_key_sync (cognitive 33) ext/crypto/lib.rs:526— deno_crypto::verify_key_sync has cognitive complexity 33 (threshold 15). Drivers by points: match/switch 14 (28 pts), if/else 2 (5 pts) (nesting depth added 17). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_decrypt::run (cognitive 32) ext/crypto/subtle_decrypt.rs:423— deno_crypto::subtle_decrypt::run has cognitive complexity 32 (threshold 15). Drivers by points: if/else 14 (24 pts), match/switch 3 (5 pts), boolean chains 3 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_ml_kem (cognitive 32) ext/crypto/subtle_import_key.rs:645— deno_crypto::subtle_import_key::import_key_ml_kem has cognitive complexity 32 (threshold 15). Drivers by points: if/else 13 (28 pts), match/switch 3 (4 pts) (nesting depth added 16). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::derive_bits_sync (cognitive 30) ext/crypto/lib.rs:731— deno_crypto::derive_bits_sync has cognitive complexity 30 (threshold 15). Drivers by points: if/else 6 (15 pts), match/switch 7 (15 pts) (nesting depth added 17). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::node_interop::build_algorithm_dict_from_v8 (cognitive 27) ext/crypto/node_interop.rs:403— deno_crypto::node_interop::build_algorithm_dict_from_v8 has cognitive complexity 27 (threshold 15). Drivers by points: if/else 14 (24 pts), boolean chains 3 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_import_key::import_key_ml_dsa (cognitive 23) ext/crypto/subtle_import_key.rs:786— deno_crypto::subtle_import_key::import_key_ml_dsa has cognitive complexity 23 (threshold 15). Drivers by points: if/else 9 (19 pts), match/switch 3 (4 pts) (nesting depth added 11). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_generate_key::run (cognitive 22) ext/crypto/subtle_generate_key.rs:311— deno_crypto::subtle_generate_key::run has cognitive complexity 22 (threshold 15). Drivers by points: if/else 10 (17 pts), match/switch 3 (4 pts), boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::algorithm::compute_key_length (cognitive 20) ext/crypto/algorithm.rs:383— deno_crypto::algorithm::compute_key_length has cognitive complexity 20 (threshold 15). Drivers by points: if/else 8 (14 pts), match/switch 2 (4 pts), boolean chains 2 (nesting depth added 8). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_import_key::import_key_slh_dsa (cognitive 20) ext/crypto/subtle_import_key.rs:909— deno_crypto::subtle_import_key::import_key_slh_dsa has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (19 pts), match/switch 1 (nesting depth added 10). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_crypto::supports_inner (cognitive 19) ext/crypto/subtle_crypto.rs:515— deno_crypto::subtle_crypto::supports_inner has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (12 pts), match/switch 2 (5 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::subtle_sign::run (cognitive 19) ext/crypto/subtle_sign.rs:409— deno_crypto::subtle_sign::run has cognitive complexity 19 (threshold 15). Drivers by points: if/else 10 (18 pts), match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_crypto::sign_key_sync (cognitive 17) ext/crypto/lib.rs:310— deno_crypto::sign_key_sync has cognitive complexity 17 (threshold 15). Drivers by points: match/switch 8 (13 pts), if/else 2 (4 pts) (nesting depth added 7). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_export_key::export_okp (cognitive 17) ext/crypto/subtle_export_key.rs:613— deno_crypto::subtle_export_key::export_okp has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (11 pts), match/switch 5 (6 pts) (nesting depth added 6). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_crypto::subtle_import_key::validate_jwk_akp (cognitive 17) ext/crypto/subtle_import_key.rs:1031— deno_crypto::subtle_import_key::validate_jwk_akp has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (11 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_crypto::subtle_import_key::validate_jwk_oct) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_crypto::subtle_import_key::validate_jwk_oct (cognitive 17) ext/crypto/subtle_import_key.rs:1844— deno_crypto::subtle_import_key::validate_jwk_oct has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (11 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_crypto::subtle_import_key::validate_jwk_akp) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node::ops::tls_wrap::build_server_config (cognitive 72) ext/node/ops/tls_wrap.rs:5397— deno_node::ops::tls_wrap::build_server_config has cognitive complexity 72 (threshold 15). Drivers by points: if/else 21 (40 pts), loops 5 (16 pts), match/switch 4 (11 pts), boolean chains 5 (nesting depth added 37). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::tls_wrap::build_client_config (cognitive 60) ext/node/ops/tls_wrap.rs:4895— deno_node::ops::tls_wrap::build_client_config has cognitive complexity 60 (threshold 15). Drivers by points: if/else 27 (41 pts), match/switch 4 (8 pts), loops 3 (6 pts), boolean chains 5 (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::http2::session::on_stream_read_callback (cognitive 48) ext/node/ops/http2/session.rs:1410— deno_node::ops::http2::session::on_stream_read_callback has cognitive complexity 48 (threshold 15). Drivers by points: if/else 21 (45 pts), boolean chains 3 (nesting depth added 24). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_node::ops::tls_wrap::parse_extensions (cognitive 48) ext/node/ops/tls_wrap.rs:4052— deno_node::ops::tls_wrap::parse_extensions has cognitive complexity 48 (threshold 15). Drivers by points: if/else 13 (37 pts), loops 2 (4 pts), match/switch 2 (4 pts), boolean chains 3 (nesting depth added 28). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::llhttp::binding::consume_read_callback (cognitive 39) ext/node/ops/llhttp/binding.rs:730— deno_node::ops::llhttp::binding::consume_read_callback has cognitive complexity 39 (threshold 15). Drivers by points: if/else 20 (34 pts), boolean chains 5 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::stream_wrap::on_uv_read (cognitive 37) ext/node/ops/stream_wrap.rs:617— deno_node::ops::stream_wrap::on_uv_read has cognitive complexity 37 (threshold 15). Drivers by points: if/else 24 (36 pts), boolean chains 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::shell::scan_and_split (cognitive 32) ext/node/ops/shell.rs:34— deno_node::ops::shell::scan_and_split has cognitive complexity 32 (threshold 15). Drivers by points: if/else 7 (17 pts), boolean chains 10, loops 2 (5 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::http2::session::on_frame_recv_callback (cognitive 31) ext/node/ops/http2/session.rs:782— deno_node::ops::http2::session::on_frame_recv_callback has cognitive complexity 31 (threshold 15). Drivers by points: if/else 19 (29 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::udp::resolve_ipv6_interface (cognitive 31) ext/node/ops/udp.rs:187— deno_node::ops::udp::resolve_ipv6_interface has cognitive complexity 31 (threshold 15). Drivers by points: if/else 8 (28 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 21). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_node::ops::assert::get_first_expression (cognitive 29) ext/node/ops/assert.rs:92— deno_node::ops::assert::get_first_expression has cognitive complexity 29 (threshold 15). Drivers by points: if/else 11 (23 pts), boolean chains 4, loops 1, match/switch 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::ipc::impl_::serialize_v8_value (cognitive 25) ext/node/ops/ipc.rs:75— deno_node::ops::ipc::impl_::serialize_v8_value has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (19 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::llhttp::binding::on_headers_complete (cognitive 24) ext/node/ops/llhttp/binding.rs:446— deno_node::ops::llhttp::binding::on_headers_complete has cognitive complexity 24 (threshold 15). Drivers by points: if/else 16 (21 pts), boolean chains 2, match/switch 1 (nesting depth added 5). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node::ops::fs::op_node_cp_on_link (cognitive 22) ext/node/ops/fs.rs:3112— deno_node::ops::fs::op_node_cp_on_link has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11 (17 pts), boolean chains 4, match/switch 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_node::ops::fs::op_node_cp_on_link_sync) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node::ops::fs::op_node_cp_on_link_sync (cognitive 22) ext/node/ops/fs.rs:3315— deno_node::ops::fs::op_node_cp_on_link_sync has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11 (17 pts), boolean chains 4, match/switch 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_node::ops::fs::op_node_cp_on_link) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node::ops::v8::op_v8_query_objects_count (cognitive 22) ext/node/ops/v8.rs:400— deno_node::ops::v8::op_v8_query_objects_count has cognitive complexity 22 (threshold 15). Drivers by points: if/else 8 (13 pts), match/switch 7 (8 pts), loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::vm::property_definer (cognitive 22) ext/node/ops/vm.rs:1112— deno_node::ops::vm::property_definer has cognitive complexity 22 (threshold 15). Drivers by points: if/else 15 (19 pts), boolean chains 2, match/switch 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node::ops::vm::op_vm_compile_function (cognitive 22) ext/node/ops/vm.rs:1489— deno_node::ops::vm::op_vm_compile_function has cognitive complexity 22 (threshold 15). Drivers by points: if/else 15 (17 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node::ops::util::op_node_call_is_from_dependency (cognitive 19) ext/node/ops/util.rs:88— deno_node::ops::util::op_node_call_is_from_dependency has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (16 pts), boolean chains 2, loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::vm::op_vm_module_get_module_requests (cognitive 18) ext/node/ops/vm.rs:2316— deno_node::ops::vm::op_vm_module_get_module_requests has cognitive complexity 18 (threshold 15). Drivers by points: if/else 4 (12 pts), loops 2 (4 pts), match/switch 1 (2 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::ipc::impl_::ab_view_to_index (cognitive 17) ext/node/ops/ipc.rs:319— deno_node::ops::ipc::impl_::ab_view_to_index has cognitive complexity 17 (threshold 15). Drivers by points: if/else 16 (17 pts) (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_node::ops::fs::check_parent_paths_impl (cognitive 16) ext/node/ops/fs.rs:2531— deno_node::ops::fs::check_parent_paths_impl has cognitive complexity 16 (threshold 15). Drivers by points: if/else 3 (7 pts), match/switch 3 (6 pts), boolean chains 2, loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_node::ops::fs::check_parent_paths_impl_sync) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node::ops::fs::check_parent_paths_impl_sync (cognitive 16) ext/node/ops/fs.rs:2624— deno_node::ops::fs::check_parent_paths_impl_sync has cognitive complexity 16 (threshold 15). Drivers by points: if/else 3 (7 pts), match/switch 3 (6 pts), boolean chains 2, loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_node::ops::fs::check_parent_paths_impl) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node::ops::http2::session::h2_read_cb (cognitive 16) ext/node/ops/http2/session.rs:271— deno_node::ops::http2::session::h2_read_cb has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 3 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node::ops::tls_wrap::der_time_secs (cognitive 16) ext/node/ops/tls_wrap.rs:3939— deno_node::ops::tls_wrap::der_time_secs has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (10 pts), boolean chains 4, loops 1, match/switch 1 (nesting depth added 2). Of this number, 13 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node::ops::vm::property_setter (cognitive 16) ext/node/ops/vm.rs:996— deno_node::ops::vm::property_setter has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (9 pts), boolean chains 5, match/switch 2 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Change coupling: global.rs ↔ local.rs libs/resolver/npm/managed/global.rs:1— `libs/resolver/npm/managed/global.rs` and `libs/resolver/npm/managed/local.rs` change together 90% of the time (35 of the 39 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 35 shared commits counted here, the most recent 3 are `9ab5c0ce` fix(npm): resolve bundled npm deps in packages properly when not usin…; `c27d8f04` fix: make '@types' package resolution more consistent (#31512); `f146dbe1` feat(npm): support `bundleDependencies` in npm dependencies (#30521) — run `git show` on any of them.
Change coupling: 99_main.js ↔ worker_bootstrap.rs runtime/js/99_main.js:1— `runtime/js/99_main.js` and `runtime/worker_bootstrap.rs` change together 73% of the time (33 of the 45 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 33 shared commits counted here, the most recent 3 are `52962aae` refactor(runtime): allow disabling the OffscreenCanvas global via env…; `0ad03b50` fix(ext/node): implement node:cluster fork/Worker and worker-side det…; `fd352537` feat: add `DENO_AUTO_SERVE` env var (#29852) — run `git show` on any of them.
Change coupling: fs.ts ↔ promises.ts ext/node/polyfills/fs.ts:1— `ext/node/polyfills/fs.ts` and `ext/node/polyfills/internal/fs/promises.ts` change together 73% of the time (11 of the 15 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 11 shared commits counted here, the most recent 3 are `d9f981f9` perf(ext/node): convert more polyfills to lazy-loaded JS (#33913); `98e65bc8` fix(ext/node): implement fs.mkdtempDisposableSync / fsPromises.mkdtem…; `4da9f0b3` refactor(ext/node): consolidate node:fs (part 9) (#32659) — run `git show` on any of them.
Change coupling: map.rs ↔ tests.rs libs/core/modules/map.rs:1— `libs/core/modules/map.rs` and `libs/core/modules/tests.rs` change together 72% of the time (13 of the 18 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 13 shared commits counted here, the most recent 3 are `985d2187` fix(core): don't resolve internal module imports with the user's impo…; `fb78add1` fix(core): allow dynamic imports during cached module evaluation (#36…; `ca368e28` fix(core): restrict extension loaders to internal modules (#36013) — run `git show` on any of them.
Change coupling: lib.rs ↔ lib.rs ext/broadcast_channel/lib.rs:1— `ext/broadcast_channel/lib.rs` and `ext/net/lib.rs` change together 70% of the time (7 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `25b9abcd` feat: use new feature checker (#29091); `aaf2bf4b` chore: upgrade deno_core (#25674); `c464cd70` refactor: FeatureChecker integration in ext/ crates (#20797) — run `git show` on any of them.
Change coupling: fs.ts ↔ promises.ts ext/node/polyfills/fs.ts:1— `ext/node/polyfills/fs.ts` and `ext/node/polyfills/fs/promises.ts` change together 70% of the time (7 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `05e01fff` perf(ext/node): convert child_process, fs, http, http2, https, inspec…; `98e65bc8` fix(ext/node): implement fs.mkdtempDisposableSync / fsPromises.mkdtem…; `4e6470ab` fix(ext/node): remove fs.promises.fstat, not a public Node.js API (#3… — run `git show` on any of them.
Change coupling: 40_tty.js ↔ tty.rs runtime/js/40_tty.js:1— `runtime/js/40_tty.js` and `runtime/ops/tty.rs` change together 70% of the time (7 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `9df917c0` chore: upgrade deno_core (#22725); `c1fac11d` feat(fs): `Deno.FsFile.{isTerminal,setRaw}()` (#22234); `4eedac36` feat: `Deno.{stdin,stdout,stderr}.isTerminal()`, deprecate `Deno.isat… — run `git show` on any of them.
Change coupling: buffer.mjs ↔ _utils.ts ext/node/polyfills/internal/buffer.mjs:1— `ext/node/polyfills/internal/buffer.mjs` and `ext/node/polyfills/internal_binding/_utils.ts` change together 64% of the time (7 of the 11 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `32e63812` perf(ext/node): Buffer hex paths via native Uint8Array toHex/setFromH…; `ca568b1c` perf(ext/web): apply the base64url op design to standard base64 (#36422); `e0523a56` perf(ext/web): implement base64url encode/decode as simdutf ops (#36398) — run `git show` on any of them.
Change coupling: ipc.rs ↔ child_process.ts ext/node/ops/ipc.rs:1— `ext/node/ops/ipc.rs` and `ext/node/polyfills/internal/child_process.ts` change together 62% of the time (10 of the 16 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 10 shared commits counted here, the most recent 3 are `9d69a647` fix(ext/node): support sending net.Socket and net.Server handles to c…; `51f7f573` Revert "fix(ext/node): make IPC writes synchronous to match Node.js b…; `eeda7328` fix(ext/node): make IPC writes synchronous to match Node.js behavior … — run `git show` on any of them.
Change coupling: js.rs ↔ web_worker.rs runtime/js.rs:1— `runtime/js.rs` and `runtime/web_worker.rs` change together 60% of the time (6 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `d4893eb5` refactor: remove snapshotting from deno_runtime (#21794); `c1c8eb3d` build: allow disabling snapshots for dev (#20048); `914b08fc` build: add "include_js_files_for_snapshotting" Cargo feature (#17826) — run `git show` on any of them.
Change coupling: export_key.rs ↔ import_key.rs ext/crypto/export_key.rs:1— `ext/crypto/export_key.rs` and `ext/crypto/import_key.rs` change together 60% of the time (6 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `bfdca5bc` feat(ext/crypto): import and export p521 keys (#25789); `5202f546` chore(ext/crypto): upgrade ec crates; `02cc37e0` chore: upgrade rsa to 0.9 (#21016) — run `git show` on any of them.
Change coupling: module_info.rs ↔ doc.rs cli/cache/module_info.rs:1— `cli/cache/module_info.rs` and `cli/tools/doc.rs` change together 58% of the time (7 of the 12 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `7a1e949c` refactor: extract `DenoDir`, `Emitter`, `EmitCache` and `ParsedSource…; `b42d5906` refactor: upgrade to deno_graph 0.95 (#29575); `cb23193f` refactor: allow deno_permissions to compile to wasm32-unknown-unknown… — run `git show` on any of them.
Change coupling: flags.rs ↔ args.rs cli/args/flags.rs:1— `cli/args/flags.rs` and `cli/lib/args.rs` change together 57% of the time (8 of the 14 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 8 shared commits counted here, the most recent 3 are `1e4b28cf` chore: remove the dead forked typescript-go integration (#35935); `e8c6f4ac` feat: stabilize bare node built-in resolution (#33316); `99ae41f6` feat: stabilize --allow-net subdomain wildcards (#29902) — run `git show` on any of them.
Change coupling: main.rs ↔ binary.rs cli/rt/main.rs:1— `cli/rt/main.rs` and `cli/standalone/binary.rs` change together 55% of the time (12 of the 22 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 12 shared commits counted here, the most recent 3 are `5f8be055` refactor(unstable): otel configuration (#27333) (at that commit the file was still `cli/mainrt.rs`); `ce778a94` Revert "perf(upgrade): cache downloaded binaries in DENO_DIR" (#26799) (at that commit the file was still `cli/mainrt.rs`); `01de3317` perf(upgrade): cache downloaded binaries in DENO_DIR (#26108) (at that commit the file was still `cli/mainrt.rs`) — run `git show` on any of them.
Change coupling: lib.rs ↔ bindings.rs libs/core/lib.rs:1— `libs/core/lib.rs` and `libs/core/runtime/bindings.rs` change together 55% of the time (6 of the 11 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `a748c295` perf(core): split OpCtx into shared OpCommonCtx + borrowed op declara…; `9eeca7be` fix(ext/node): avoid panic when vm.SourceTextModule uses import.meta …; `eb2298ae` fix(runtime): show import location for unsupported import attributes … — run `git show` on any of them.
Change coupling: diagnostics.rs ↔ server.rs cli/lsp/diagnostics.rs:1— `cli/lsp/diagnostics.rs` and `cli/lsp/testing/server.rs` change together 55% of the time (6 of the 11 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `97d16353` fix(lsp): panic on url_to_uri() (#25238); `7446b016` perf(lsp): don't keep remote module ast's in memory (#23230); `fe90ba65` refactor(lsp): log names (#21413) — run `git show` on any of them.
Change coupling: sig.ts ↔ sign.rs ext/node/polyfills/internal/crypto/sig.ts:1— `ext/node/polyfills/internal/crypto/sig.ts` and `ext/node_crypto/sign.rs` change together 54% of the time (7 of the 13 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 7 shared commits counted here, the most recent 3 are `d7b5c73f` fix(ext/node): enable test-crypto.js node compat test (#33822); `8ec2df30` fix(ext/node): enable test-crypto-sign-verify node compat test (#33810); `f79eedcf` fix(ext/node): improve sign/verify crypto compat with Node.js (#33083) — run `git show` on any of them.
Change coupling: http.rs ↔ http.ts ext/node/ops/http.rs:1— `ext/node/ops/http.rs` and `ext/node/polyfills/http.ts` change together 53% of the time (9 of the 17 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 9 shared commits counted here, the most recent 3 are `0905fd9d` feat(node/http): enable keepAlive connection reuse for HTTP Agent (#3…; `5f139910` fix(ext/node): support http over unix sockets (#29182); `1cecc0a8` fix(ext/node): support proxy http request (#27871) — run `git show` on any of them.
Change coupling: module_loader.rs ↔ node.rs cli/module_loader.rs:1— `cli/module_loader.rs` and `cli/node.rs` change together 50% of the time (12 of the 24 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 12 shared commits counted here, the most recent 3 are `c1751d7e` refactor: extract PreparedModuleLoader from CLI (#29977); `7a1e949c` refactor: extract `DenoDir`, `Emitter`, `EmitCache` and `ParsedSource…; `b42d5906` refactor: upgrade to deno_graph 0.95 (#29575) — run `git show` on any of them.
Change coupling: _next_tick.ts ↔ process.ts ext/node/polyfills/_next_tick.ts:1— `ext/node/polyfills/_next_tick.ts` and `ext/node/polyfills/process.ts` change together 50% of the time (6 of the 12 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `92ed54bb` Reland refactor(core): move nextTick/immediate queues into core, repl…; `9f02e001` Revert "refactor(core): move nextTick/immediate queues into core, rep…; `91e84aef` refactor(core): move nextTick/immediate queues into core, replace ops… — run `git show` on any of them.
Change coupling: module_info.rs ↔ module_loader.rs cli/cache/module_info.rs:1— `cli/cache/module_info.rs` and `cli/module_loader.rs` change together 50% of the time (6 of the 12 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 6 shared commits counted here, the most recent 3 are `7a1e949c` refactor: extract `DenoDir`, `Emitter`, `EmitCache` and `ParsedSource…; `b42d5906` refactor: upgrade to deno_graph 0.95 (#29575); `ed2fac89` refactor: handle deno_media_type having `Html` and `Sql` variants (#2… — run `git show` on any of them.
Change coupling: graph_container.rs ↔ graph_util.rs cli/graph_container.rs:1— `cli/graph_container.rs` and `cli/graph_util.rs` change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `3a101425` fix(bundle): respect runtime file permissions (#36107); `b23cb76e` fix(resolver): scope sloppy import hints to prepared modules (#36221); `22b7401b` fix: support loading `npm:` and `jsr:` specifiers in required ES modu… — run `git show` on any of them.
Change coupling: 98_global_scope_shared.js ↔ 98_global_scope_window.js runtime/js/98_global_scope_shared.js:1— `runtime/js/98_global_scope_shared.js` and `runtime/js/98_global_scope_window.js` change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency between them. They sit in the same directory, but in this ecosystem each file is its own module — a sibling reference still needs an import — so the missing import edge is real: the coupling runs through shared behaviour, not a declared dependency. If they duplicate structure, extract the common part into one unit; otherwise the coupling is hidden and worth breaking. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `741f4df6` feat(ext/web): web locks api (#31166); `a317222e` perf(ext): convert ext/kv and ext/webgpu JS sources to lazy-loaded sc…; `c8b2af8e` refactor: use web utils and lazy load utils from core (#22289) — run `git show` on any of them.
Change coupling: 90_deno_ns.js ↔ mod.rs runtime/js/90_deno_ns.js:1— `runtime/js/90_deno_ns.js` and `runtime/ops/mod.rs` change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) and are written in DIFFERENT LANGUAGES, so no import can join them and they cannot be co-located into one unit — they compile and ship as separate artifacts. What binds them is a CONTRACT across that boundary — an event or message name, a route, a serialised shape — that each side currently spells out on its own, which is exactly why a change to one drags the other. Declare that contract once where both sides read it (a shared schema, a generated constants file, an interface-definition file) so a change on one side fails the other's build instead of drifting silently; where the surface is too small to be worth that, name the counterpart in a comment on both sides so the next reader finds it. There is nothing here to merge. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `0050857f` refactor: add 'deno_process' crate (#27680); `974e2f44` refactor: add 'deno_os' crate (#27655); `fe368b72` refactor: Add "deno_fs" extension crate (#18040) — run `git show` on any of them.
Change coupling: child_process.ts ↔ pipe_wrap.ts ext/node/polyfills/internal/child_process.ts:1— `ext/node/polyfills/internal/child_process.ts` and `ext/node/polyfills/internal_binding/pipe_wrap.ts` change together 50% of the time (5 of the 10 commits that touched whichever of the two files changed less often, counting a file under its earlier names as well, and counted over this repository's 10,000 most recent commits rather than its whole history — a repo-wide or module-wide sweep is evidence about the sweep rather than about any pair inside it and is left out of BOTH sides of this ratio, while a dependency bump, a formatter/rename sweep, or a commit whose edit to one of the two files was a tool directive such as //go:generate or whitespace only is left out of the shared count ONLY, so the two sides are not taken over identical commit sets) with no explicit dependency — the edge is real but nothing declares it. Read the pair before acting: if one registers itself into the other through a hook or an initialiser, the missing dependency is DELIBERATE — the registration is the link, and it is meant not to be an import — and the thing to add is a comment on each side naming the other, not a merge; if they simply belong together, co-locate them; if neither holds, the coupling is hidden and worth breaking. You can check this without leaving the row: of the 5 shared commits counted here, the most recent 3 are `daeaf3c4` feat: native uv_pipe_t implementation with NativePipe and FdTable (#3…; `62dfdab0` refactor(ext/process): bypass resource table for Node child_process s…; `4e6eb1e1` fix(ext/node): create net.Socket from file descriptors (#33150) — run `git show` on any of them.
deno_crypto::subtle_crypto::supports_params_valid (cyclomatic 59) ext/crypto/subtle_crypto.rs:648— deno_crypto::subtle_crypto::supports_params_valid has cyclomatic complexity 59 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_import_key::import_key_ec (cyclomatic 42) ext/crypto/subtle_import_key.rs:1075— deno_crypto::subtle_import_key::import_key_ec has cyclomatic complexity 42 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::verify_key_sync (cyclomatic 40) ext/crypto/lib.rs:526— deno_crypto::verify_key_sync has cyclomatic complexity 40 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_crypto::subtle_import_key::import_key_rsa (cyclomatic 39) ext/crypto/subtle_import_key.rs:340— deno_crypto::subtle_import_key::import_key_rsa has cyclomatic complexity 39 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_wrap_key::jwk_to_utf8 (cyclomatic 38) ext/crypto/subtle_wrap_key.rs:291— deno_crypto::subtle_wrap_key::jwk_to_utf8 has cyclomatic complexity 38 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_derive_bits::run (cyclomatic 34) ext/crypto/subtle_derive_bits.rs:417— deno_crypto::subtle_derive_bits::run has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::sign_key_sync (cyclomatic 31) ext/crypto/lib.rs:310— deno_crypto::sign_key_sync has cyclomatic complexity 31 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_crypto::subtle_decrypt::run (cyclomatic 28) ext/crypto/subtle_decrypt.rs:423— deno_crypto::subtle_decrypt::run has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_encrypt::run (cyclomatic 28) ext/crypto/subtle_encrypt.rs:480— deno_crypto::subtle_encrypt::run has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::import_key::import_key_ec (cyclomatic 26) ext/crypto/import_key.rs:723— deno_crypto::import_key::import_key_ec has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_generate_key::run (cyclomatic 26) ext/crypto/subtle_generate_key.rs:311— deno_crypto::subtle_generate_key::run has cyclomatic complexity 26 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_crypto::subtle_get_public_key::run (cyclomatic 24) ext/crypto/subtle_get_public_key.rs:38— deno_crypto::subtle_get_public_key::run has cyclomatic complexity 24 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_crypto::derive_bits_sync (cyclomatic 23) ext/crypto/lib.rs:731— deno_crypto::derive_bits_sync has cyclomatic complexity 23 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_crypto::export_key::export_key_ec (cyclomatic 23) ext/crypto/export_key.rs:252— deno_crypto::export_key::export_key_ec has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_import_key::import_key_okp (cyclomatic 23) ext/crypto/subtle_import_key.rs:1374— deno_crypto::subtle_import_key::import_key_okp has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_import_key::aes_jwk_alg (cyclomatic 24) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_import_key::import_key_ml_kem (cyclomatic 21) ext/crypto/subtle_import_key.rs:645— deno_crypto::subtle_import_key::import_key_ml_kem has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_import_key::aes_jwk_alg (cyclomatic 24) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_import_key::import_key_kmac (cyclomatic 21) ext/crypto/subtle_import_key.rs:1665— deno_crypto::subtle_import_key::import_key_kmac has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_import_key::aes_jwk_alg (cyclomatic 24) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_export_key::export_ec (cyclomatic 19) ext/crypto/subtle_export_key.rs:510— deno_crypto::subtle_export_key::export_ec has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_export_key::rsa_jwk_alg (cyclomatic 22) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_sign::run (cyclomatic 19) ext/crypto/subtle_sign.rs:409— deno_crypto::subtle_sign::run has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_export_key::jwk_alg_for_symmetric (cyclomatic 18) ext/crypto/subtle_export_key.rs:332— deno_crypto::subtle_export_key::jwk_alg_for_symmetric has cyclomatic complexity 18 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_export_key::rsa_jwk_alg (cyclomatic 22) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_export_key::export_okp (cyclomatic 18) ext/crypto/subtle_export_key.rs:613— deno_crypto::subtle_export_key::export_okp has cyclomatic complexity 18 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_export_key::rsa_jwk_alg (cyclomatic 22) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_verify::run (cyclomatic 18) ext/crypto/subtle_verify.rs:228— deno_crypto::subtle_verify::run has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_crypto::subtle_export_key::jwk_to_object (cyclomatic 17) ext/crypto/subtle_export_key.rs:157— deno_crypto::subtle_export_key::jwk_to_object has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_export_key::rsa_jwk_alg (cyclomatic 22) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_crypto::subtle_import_key::import_key_ml_dsa (cyclomatic 17) ext/crypto/subtle_import_key.rs:786— deno_crypto::subtle_import_key::import_key_ml_dsa has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_crypto::subtle_import_key::aes_jwk_alg (cyclomatic 24) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
R4 · Test Coverage· This test file cannot be loaded · ×24
This test file cannot be loaded tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6— tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6 imports './index.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/registry/npm/@denotest/lifecycle-scripts-simple/1.0.0/main.js:2— tests/registry/npm/@denotest/lifecycle-scripts-simple/1.0.0/main.js:2 imports './message.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/registry/npm/@denotest/node-addon-implicit-node-gyp/1.0.0/index.js:1— tests/registry/npm/@denotest/node-addon-implicit-node-gyp/1.0.0/index.js:1 imports './build/Release/node_addon', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/registry/npm/@denotest/node-addon/1.0.0/index.js:1— tests/registry/npm/@denotest/node-addon/1.0.0/index.js:1 imports './build/Release/node_addon', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/specs/npm/node_modules_import/main.ts:2— tests/specs/npm/node_modules_import/main.ts:2 imports './node_modules/@denotest/esm-basic/main.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/specs/npm/node_modules_import_auto/main.ts:2— tests/specs/npm/node_modules_import_auto/main.ts:2 imports './node_modules/@denotest/esm-basic/main.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/specs/npm/workspace_sub_deno_json/member/main.ts:3— tests/specs/npm/workspace_sub_deno_json/member/main.ts:3 imports '../node_modules', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/specs/npm/workspace_sub_deno_json/member_with_deno_json/main.ts:3— tests/specs/npm/workspace_sub_deno_json/member_with_deno_json/main.ts:3 imports '../node_modules', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/specs/run/import_common_js/require_error.js:2— tests/specs/run/import_common_js/require_error.js:2 imports './a', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/check/import_non_existent.ts:1— tests/testdata/check/import_non_existent.ts:1 imports './non-existent-module.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/check/module_detection_force.ts:2— tests/testdata/check/module_detection_force.ts:2 imports './module_detection_force/import.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/dynamic_import/b.js:1— tests/testdata/dynamic_import/b.js:1 imports './bad.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/dynamic_import/c.js:1— tests/testdata/dynamic_import/c.js:1 imports './bad2.mjs', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/import_maps/test.ts:6— tests/testdata/import_maps/test.ts:6 imports './scope/scoped.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/info/error_009_missing_js_module.js:1— tests/testdata/info/error_009_missing_js_module.js:1 imports './bad-module.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/module_graph/file_tests-a.mjs:1— tests/testdata/module_graph/file_tests-a.mjs:1 imports './b.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/module_graph/file_tests-diag.ts:1— tests/testdata/module_graph/file_tests-diag.ts:1 imports './c/mod.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/module_graph/https_deno.land-x-a-mod.ts:1— tests/testdata/module_graph/https_deno.land-x-a-mod.ts:1 imports '../b/mod.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/module_graph/https_deno.land-x-lib-mod.d.ts:2— tests/testdata/module_graph/https_deno.land-x-lib-mod.d.ts:2 imports './b.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either (1 further unresolvable import(s) in the same file). The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/module_graph/https_deno.land-x-lib-mod.js:2— tests/testdata/module_graph/https_deno.land-x-lib-mod.js:2 imports './b.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either (1 further unresolvable import(s) in the same file). The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/run/permissions_prompt_allow_all_2.ts:8— tests/testdata/run/permissions_prompt_allow_all_2.ts:8 imports '../', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/run/top_level_await/tla3/b.js:2— tests/testdata/run/top_level_await/tla3/b.js:2 imports '../circular.js', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/tsc2/file_reexports.ts:1— tests/testdata/tsc2/file_reexports.ts:1 imports './exportc.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
This test file cannot be loaded tests/testdata/tsc2/https_deno.land-x-a.ts:1— tests/testdata/tsc2/https_deno.land-x-a.ts:1 imports './b.ts', which names no file in this repository — and no rule in its .gitignore chain could cover one, so no build writes it either. The import throws as the runner collects this file, so none of its test cases run and nothing it was written to verify is verified. Restore the missing module or delete the test. It is excluded from the reachability measured above, because a file that cannot load reaches nothing.
deno_web::console::inspect::format_raw (cyclomatic 97) ext/web/console/inspect.rs:1920— deno_web::console::inspect::format_raw has cyclomatic complexity 97 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::apply_options (cyclomatic 54) ext/web/console/mod.rs:278— deno_web::console::apply_options has cyclomatic complexity 54 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::error_fmt::format_error (cyclomatic 48) ext/web/console/error_fmt.rs:687— deno_web::console::error_fmt::format_error has cyclomatic complexity 48 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::width::ansi_sequence_len (cyclomatic 38) ext/web/console/width.rs:13— deno_web::console::width::ansi_sequence_len has cyclomatic complexity 38 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
deno_web::console::inspect::add_prototype_properties (cyclomatic 34) ext/web/console/inspect.rs:1494— deno_web::console::inspect::add_prototype_properties has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::format_property (cyclomatic 32) ext/web/console/inspect.rs:3528— deno_web::console::inspect::format_property has cyclomatic complexity 32 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::css::parse_css (cyclomatic 29) ext/web/console/css.rs:342— deno_web::console::css::parse_css has cyclomatic complexity 29 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::url::parse_simple_special_url (cyclomatic 28) ext/web/url.rs:112— deno_web::url::parse_simple_special_url has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::error_fmt::get_duplicate_error_frame_ranges (cyclomatic 27) ext/web/console/error_fmt.rs:264— deno_web::console::error_fmt::get_duplicate_error_frame_ranges has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::get_constructor_name (cyclomatic 26) ext/web/console/inspect.rs:1669— deno_web::console::inspect::get_constructor_name has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect_args_impl (cyclomatic 25) ext/web/console/mod.rs:677— deno_web::console::inspect_args_impl has cyclomatic complexity 25 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::js_parse_float (cyclomatic 23) ext/web/console/mod.rs:547— deno_web::console::js_parse_float has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::try_custom_inspect (cyclomatic 22) ext/web/console/inspect.rs:677— deno_web::console::inspect::try_custom_inspect has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::url::simple_special_host_is_canonical (cyclomatic 22) ext/web/url.rs:223— deno_web::url::simple_special_host_is_canonical has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::group_array_elements (cyclomatic 20) ext/web/console/inspect.rs:3855— deno_web::console::inspect::group_array_elements has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::css::parse_css_color (cyclomatic 19) ext/web/console/css.rs:185— deno_web::console::css::parse_css_color has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::format_value (cyclomatic 19) ext/web/console/inspect.rs:562— deno_web::console::inspect::format_value has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::get_user_options (cyclomatic 18) ext/web/console/inspect.rs:806— deno_web::console::inspect::get_user_options has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::get_keys (cyclomatic 18) ext/web/console/inspect.rs:1279— deno_web::console::inspect::get_keys has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::reduce_to_single_string (cyclomatic 18) ext/web/console/inspect.rs:3742— deno_web::console::inspect::reduce_to_single_string has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::css_stylesheet::split_top_level_rules (cyclomatic 18) ext/web/css_stylesheet.rs:60— deno_web::css_stylesheet::split_top_level_rules has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::format_primitive (cyclomatic 16) ext/web/console/inspect.rs:1122— deno_web::console::inspect::format_primitive has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_web::console::inspect::get_function_base (cyclomatic 16) ext/web/console/inspect.rs:2764— deno_web::console::inspect::get_function_base has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
FixmeComment tests/unit_node/http_test.ts:726— // FIXME(kt3k): This is necessary for preventing op leak on windows — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit_node/http_test.ts:785— // FIXME(kt3k): This is necessary for preventing op leak on windows — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit_node/http_test.ts:839— // FIXME(kt3k): This is necessary for preventing op leak on windows — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit_node/http_test.ts:1394— // FIXME(kt3k): This is necessary for preventing op leak on windows — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit_node/crypto/crypto_sign_test.ts:204— // @ts-ignore FIXME: types dont allow this — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit_node/crypto/crypto_sign_test.ts:212— // @ts-ignore FIXME: types dont allow this — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/command_test.ts:1031— // FIXME(bartlomieju): this test is very flaky on CI, fix it — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/serve_test.ts:511— // FIXME(bartlomieju): — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/serve_test.ts:853— // FIXME(bartlomieju): — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/serve_test.ts:888— // FIXME(bartlomieju): — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/serve_test.ts:2513— // FIXME: — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/serve_test.ts:2765— // FIXME: — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/url_test.ts:347— // FIXME(nayeemrmn): This is true according to — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/unit/url_test.ts:356— // FIXME(nayeemrmn): This is true according to — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/integration/repl_tests.rs:976— // FIXME(nayeemrmn): REPL unit tests don't support output capturing. — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment tests/integration/serve_tests.rs:268— // FIXME: flaky on macOS, it tends to not distribute requests evenly — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment runtime/subprocess_windows/src/process.rs:1496— // FIXME: This needs tests to ensure that the arguments are properly — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment runtime/ops/runtime.rs:75— // FIXME: Using the process ID exposes a race condition — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment libs/node_resolver/analyze.rs:389— // FIXME(bartlomieju): check if these conditions are okay, probably — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment libs/core/modules/map.rs:987— // FIXME(bartomieju): there are no stack frames if exception — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment libs/core/modules/map.rs:1187— // FIXME: instantiate_module is called more than it should be, — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment ext/node/polyfills/process.ts:207— // FIXME(bartlomieju): this is wrong, we won't be using syscall to exit — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
FixmeComment cli/module_loader.rs:1183— // FIXME(bartlomieju): this is a hacky way to provide compatibility with REPL — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
TooManyMethods: TsEsTreeBuilder cli/tools/lint/ast_buffer/ts_estree.rs:476— TooManyMethods — 155 methods. The bar is 30 methods; this is 125 over it, 5.17× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: CliOptions cli/args/mod.rs:553— TooManyMethods — 88 methods. The bar is 30 methods; this is 58 over it, 2.93× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: DOMMatrixReadOnly ext/web/geometry.rs:1256— TooManyMethods — 86 methods. The bar is 30 methods; this is 56 over it, 2.87× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: ModuleMap libs/core/modules/map.rs:110— TooManyMethods — 76 methods, declared across 5 files: modules/map.rs (41), map/ext_script.rs (16), map/dynamic.rs (12), map/evaluation.rs (5), +1 more file(s). The bar is 30 methods; this is 46 over it, 2.53× the bar. That list is where to read them, not a suggestion to split the file: the members belong to the type wherever they are declared, so moving them between files leaves the count unchanged. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: Inner cli/lsp/language_server.rs:305— TooManyMethods — 75 methods. The bar is 30 methods; this is 45 over it, 2.50× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: CliFactory cli/factory.rs:340— TooManyMethods — 68 methods. The bar is 30 methods; this is 38 over it, 2.27× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: JsRuntime libs/core/runtime/jsruntime.rs:456— TooManyMethods — 64 methods. The bar is 30 methods; this is 34 over it, 2.13× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: DOMMatrix ext/web/geometry.rs:2413— TooManyMethods — 59 methods. The bar is 30 methods; this is 29 over it, 1.97× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: PermissionsContainer runtime/permissions/lib.rs:4132— TooManyMethods — 59 methods. The bar is 30 methods; this is 29 over it, 1.97× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: UnaryPermission runtime/permissions/lib.rs:931— TooManyMethods — 55 methods. The bar is 30 methods; this is 25 over it, 1.83× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: Workspace libs/config/workspace/mod.rs:540— TooManyMethods — 51 methods. The bar is 30 methods; this is 21 over it, 1.70× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: TLSWrap ext/node/ops/tls_wrap.rs:2077— TooManyMethods — 50 methods. The bar is 30 methods; this is 20 over it, 1.67× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: ConfigFile libs/config/deno_json/mod.rs:1730— TooManyMethods — 48 methods. The bar is 30 methods; this is 18 over it, 1.60× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: NodeResolver libs/node_resolver/resolution.rs:334— TooManyMethods — 48 methods. The bar is 30 methods; this is 18 over it, 1.60× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: WasiContext ext/node/ops/wasi.rs:416— TooManyMethods — 47 methods. The bar is 30 methods; this is 17 over it, 1.57× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: Interface ext/node/polyfills/internal/readline/interface.mjs:383— TooManyMethods — 41 methods. The bar is 30 methods; this is 11 over it, 1.37× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: WorkspaceDirectory libs/config/workspace/mod.rs:1918— TooManyMethods — 39 methods. The bar is 30 methods; this is 9 over it, 1.30× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: LibUvStreamWrap ext/node/ops/stream_wrap.rs:210— TooManyMethods — 37 methods. The bar is 30 methods; this is 7 over it, 1.23× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: TsJsServer cli/lsp/tsc.rs:251— TooManyMethods — 36 methods. The bar is 30 methods; this is 6 over it, 1.20× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: Socket ext/node/polyfills/dgram.ts:174— TooManyMethods — 35 methods. The bar is 30 methods; this is 5 over it, 1.17× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: HttpRecord ext/http/service.rs:792— TooManyMethods — 31 methods. The bar is 30 methods; this is 1 over it, 1.03× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
TooManyMethods: UDP ext/node/polyfills/internal_binding/udp_wrap.ts:124— TooManyMethods — 31 methods. The bar is 30 methods; this is 1 over it, 1.03× the bar. To reduce it, group the members that share the same data into a smaller type of their own and delegate to it, so no single type carries every responsibility.
Duplicated block (16 lines × 2) cli/lsp/tsc.rs:2911— cli/lsp/tsc.rs:2911-2926 | cli/lsp/tsc.rs:2944-2959 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) cli/module_loader.rs:2010— cli/module_loader.rs:2010-2025 | cli/rt/run.rs:2091-2106 — before extracting anything, compare `cli/module_loader.rs` and `cli/rt/run.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 34 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (16 lines × 2) cli/tools/pm/mod.rs:1258— cli/tools/pm/mod.rs:1258-1273 | cli/tools/pm/outdated/mod.rs:267-282 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (16 lines × 2) cli/tools/repl/session.rs:265— cli/tools/repl/session.rs:265-280 | cli/tools/run/hmr.rs:304-319 — before extracting anything, compare `cli/tools/repl/session.rs` and `cli/tools/run/hmr.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 38 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (16 lines × 2) ext/cache/lsc_shard.rs:88— ext/cache/lsc_shard.rs:88-103 | ext/cache/lsc_shard.rs:122-137 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/canvas/byow.rs:236— ext/canvas/byow.rs:236-251 | ext/canvas/canvas.rs:139-154 — before extracting anything, compare `ext/canvas/byow.rs` and `ext/canvas/canvas.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 33 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (16 lines × 2) ext/crypto/subtle_import_key.rs:424— ext/crypto/subtle_import_key.rs:424-439 | ext/crypto/subtle_import_key.rs:590-605 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/crypto/subtle_sign.rs:72— ext/crypto/subtle_sign.rs:72-87 | ext/crypto/subtle_verify.rs:66-81 — before extracting anything, compare `ext/crypto/subtle_sign.rs` and `ext/crypto/subtle_verify.rs` as WHOLE FILES: this scan already matched 6 separate duplicated blocks between them, totalling at least 160 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (16 lines × 2) ext/ffi/call.rs:338— ext/ffi/call.rs:338-353 | ext/ffi/call.rs:398-413 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/fs/ops.rs:351— ext/fs/ops.rs:351-366 | ext/fs/ops.rs:375-390 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/node/ops/dns.rs:118— ext/node/ops/dns.rs:118-133 | ext/node/ops/dns.rs:203-218 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/node/ops/stream_wrap.rs:980— ext/node/ops/stream_wrap.rs:980-995 | ext/node/ops/stream_wrap.rs:1039-1054 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/node/ops/zlib/mod.rs:737— ext/node/ops/zlib/mod.rs:737-752 | ext/node/ops/zlib/mod.rs:783-798 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) ext/node_crypto/x509.rs:291— ext/node_crypto/x509.rs:291-306 | ext/node_crypto/x509.rs:328-343 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) libs/core/arena/raw_arena.rs:325— libs/core/arena/raw_arena.rs:325-340 | libs/core/arena/raw_arena.rs:354-369 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) libs/core/ops_builtin_v8.rs:318— libs/core/ops_builtin_v8.rs:318-333 | libs/core/ops_builtin_v8.rs:445-460 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) libs/http_h1/parse.rs:186— libs/http_h1/parse.rs:186-201 | libs/http_h1/parse.rs:246-261 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (16 lines × 2) libs/ops/conversion/from_v8/enum.rs:208— libs/ops/conversion/from_v8/enum.rs:208-223 | libs/ops/conversion/to_v8/enum.rs:394-409 — `libs/ops/conversion/from_v8/enum.rs` and `libs/ops/conversion/to_v8/enum.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 4 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
deno_core::uv_compat::pipe::poll_pipe_handle (cyclomatic 86) REDACTED:1759— deno_core::uv_compat::pipe::poll_pipe_handle has cyclomatic complexity 86 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::pipe::poll_pipe_handle (cyclomatic 72) REDACTED:1404— deno_core::uv_compat::pipe::poll_pipe_handle has cyclomatic complexity 72 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::tcp::poll_tcp_handle (cyclomatic 70) libs/core/uv_compat/tcp.rs:1271— deno_core::uv_compat::tcp::poll_tcp_handle has cyclomatic complexity 70 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::tty::poll_tty_handle (cyclomatic 56) libs/core/uv_compat/tty.rs:2188— deno_core::uv_compat::tty::poll_tty_handle has cyclomatic complexity 56 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_core::uv_compat::tty::get_vt100_fn_key (cyclomatic 137) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_core::inspector::pump_inspector_session_messages (cyclomatic 35) libs/core/inspector.rs:2051— deno_core::inspector::pump_inspector_session_messages has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::tty::uv_tty_init (cyclomatic 29) libs/core/uv_compat/tty.rs:1263— deno_core::uv_compat::tty::uv_tty_init has cyclomatic complexity 29 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_core::uv_compat::tty::get_vt100_fn_key (cyclomatic 137) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_core::uv_compat::io_error_to_uv (cyclomatic 28) libs/core/uv_compat.rs:110— deno_core::uv_compat::io_error_to_uv has cyclomatic complexity 28 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_core::uv_compat::tty::tty_try_read_raw (cyclomatic 28) libs/core/uv_compat/tty.rs:1052— deno_core::uv_compat::tty::tty_try_read_raw has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_core::uv_compat::tty::get_vt100_fn_key (cyclomatic 137) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_core::runtime::bindings::initialize_deno_core_ops_bindings (cyclomatic 20) libs/core/runtime/bindings.rs:421— deno_core::runtime::bindings::initialize_deno_core_ops_bindings has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::modules::map::wasm::render_js_wasm_module (cyclomatic 19) libs/core/modules/map/wasm.rs:175— deno_core::modules::map::wasm::render_js_wasm_module has cyclomatic complexity 19 (threshold 15). Of this number, 18 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::stream::write_pipe (cyclomatic 19) libs/core/uv_compat/stream.rs:797— deno_core::uv_compat::stream::write_pipe has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::runtime::bindings::upgrade_snapshotted_ops_with_fast_calls (cyclomatic 17) libs/core/runtime/bindings.rs:613— deno_core::runtime::bindings::upgrade_snapshotted_ops_with_fast_calls has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::uv_guess_handle (cyclomatic 17) libs/core/uv_compat.rs:893— deno_core::uv_compat::uv_guess_handle has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This is NOT this file's highest cyclomatic complexity: deno_core::uv_compat::uv_error_message (cyclomatic 20) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_core::error::format_frame (cyclomatic 16) libs/core/error.rs:2440— deno_core::error::format_frame has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::extension_set::into_sources_and_source_maps (cyclomatic 16) libs/core/extension_set.rs:349— deno_core::extension_set::into_sources_and_source_maps has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::stream::uv_try_writev (cyclomatic 16) libs/core/uv_compat/stream.rs:256— deno_core::uv_compat::stream::uv_try_writev has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_core::uv_compat::tty::uv_tty_set_mode (cyclomatic 16) libs/core/uv_compat/tty.rs:1518— deno_core::uv_compat::tty::uv_tty_set_mode has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_core::uv_compat::tty::get_vt100_fn_key (cyclomatic 137) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_cli_parser::parse::parse_args (cognitive 120) libs/cli_parser/src/parse.rs:112— deno_cli_parser::parse::parse_args has cognitive complexity 120 (threshold 15). Drivers by points: if/else 30 (78 pts), loops 9 (22 pts), boolean chains 12, match/switch 2 (8 pts) (nesting depth added 67). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_cli_parser::convert::validate_permission_args (cognitive 51) libs/cli_parser/src/convert.rs:1197— deno_cli_parser::convert::validate_permission_args has cognitive complexity 51 (threshold 15). Drivers by points: if/else 15 (31 pts), loops 7 (14 pts), boolean chains 6 (nesting depth added 23). Of this number, 45 points are the body's own statements and 6 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::help::render_help (cognitive 49) libs/cli_parser/src/help.rs:9— deno_cli_parser::help::render_help has cognitive complexity 49 (threshold 15). Drivers by points: if/else 17 (34 pts), loops 4 (8 pts), match/switch 2 (6 pts), boolean chains 1 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::apply_node_options (cognitive 40) libs/cli_parser/src/convert.rs:3041— deno_cli_parser::convert::apply_node_options has cognitive complexity 40 (threshold 15). Drivers by points: if/else 12 (17 pts), loops 4 (9 pts), match/switch 4 (9 pts), boolean chains 5 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::completions::get_candidates (cognitive 31) libs/cli_parser/src/completions.rs:604— deno_cli_parser::completions::get_candidates has cognitive complexity 31 (threshold 15). Drivers by points: if/else 11 (22 pts), boolean chains 8, loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::parse::parse_long_flag (cognitive 31) libs/cli_parser/src/parse.rs:427— deno_cli_parser::parse::parse_long_flag has cognitive complexity 31 (threshold 15). Drivers by points: if/else 10 (17 pts), boolean chains 6, loops 1 (4 pts), match/switch 3 (4 pts) (nesting depth added 11). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_cli_parser::parse::resolve_subcommand (cognitive 29) libs/cli_parser/src/parse.rs:48— deno_cli_parser::parse::resolve_subcommand has cognitive complexity 29 (threshold 15). Drivers by points: if/else 9 (23 pts), boolean chains 5, loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::permission_args_parse (cognitive 25) libs/cli_parser/src/convert.rs:537— deno_cli_parser::convert::permission_args_parse has cognitive complexity 25 (threshold 15). Drivers by points: if/else 24, boolean chains 1. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_cli_parser::convert::serialize_command_def (cognitive 24) libs/cli_parser/src/convert.rs:3328— deno_cli_parser::convert::serialize_command_def has cognitive complexity 24 (threshold 15). Drivers by points: if/else 11 (19 pts), boolean chains 3, loops 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::parse::parse_short_flag (cognitive 24) libs/cli_parser/src/parse.rs:527— deno_cli_parser::parse::parse_short_flag has cognitive complexity 24 (threshold 15). Drivers by points: if/else 5 (15 pts), match/switch 2 (5 pts), boolean chains 3, loops 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::default_parse (cognitive 23) libs/cli_parser/src/convert.rs:280— deno_cli_parser::convert::default_parse has cognitive complexity 23 (threshold 15). Drivers by points: if/else 9 (18 pts), boolean chains 5 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::test_parse (cognitive 22) libs/cli_parser/src/convert.rs:1621— deno_cli_parser::convert::test_parse has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11, match/switch 6 (10 pts), boolean chains 1 (nesting depth added 4). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_cli_parser::completions::generate_zsh (cognitive 21) libs/cli_parser/src/completions.rs:151— deno_cli_parser::completions::generate_zsh has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (13 pts), loops 4 (5 pts), boolean chains 3 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::completions::generate_fish (cognitive 21) libs/cli_parser/src/completions.rs:253— deno_cli_parser::completions::generate_fish has cognitive complexity 21 (threshold 15). Drivers by points: if/else 6 (13 pts), loops 5 (6 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::escape_and_split_commas (cognitive 19) libs/cli_parser/src/convert.rs:1331— deno_cli_parser::convert::escape_and_split_commas has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (18 pts), loops 1 (nesting depth added 10). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_cli_parser::convert::install_parse (cognitive 17) libs/cli_parser/src/convert.rs:2239— deno_cli_parser::convert::install_parse has cognitive complexity 17 (threshold 15). Drivers by points: if/else 10 (16 pts), loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cli_parser::convert::ignore_scripts_value (cognitive 16) libs/cli_parser/src/convert.rs:1023— deno_cli_parser::convert::ignore_scripts_value has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (12 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Low cohesion: DOMMatrixReadOnly (LCOM4 15) ext/web/geometry.rs:1256— DOMMatrixReadOnly's methods fall into 15 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 15 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: Matrix4 (LCOM4 7) ext/web/geometry.rs:140— Matrix4's methods fall into 7 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 7 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: TlsStreamResource (LCOM4 6) ext/net/ops_tls.rs:109— TlsStreamResource's methods fall into 6 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 6 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: WefDesktopApi (LCOM4 5) cli/rt_desktop/lib.rs:52— WefDesktopApi's methods fall into 5 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 5 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: WasiContext (LCOM4 5) ext/node/ops/wasi.rs:416— WasiContext's methods fall into 5 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 5 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: Flags (LCOM4 5) libs/cli_parser/src/flags.rs:943— Flags's methods fall into 5 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 5 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: JsError (LCOM4 5) libs/core/error.rs:495— JsError's methods fall into 5 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 5 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: CliNodeRequireLoader (LCOM4 4) cli/module_loader.rs:2093— CliNodeRequireLoader's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: DocResolver (LCOM4 4) cli/tools/doc.rs:432— DocResolver's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: WatcherCommunicator (LCOM4 4) cli/util/file_watcher.rs:170— WatcherCommunicator's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: Env (LCOM4 4) ext/napi/lib.rs:597— Env's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: NamedPipe (LCOM4 4) ext/net/win_pipe.rs:29— NamedPipe's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: Session (LCOM4 4) ext/node/ops/http2/session.rs:2022— Session's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: LoaderHookRegistry (LCOM4 4) ext/node/ops/module_hooks.rs:53— LoaderHookRegistry's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: JsRuntime (LCOM4 4) libs/core/runtime/jsruntime.rs:456— JsRuntime's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: PackageSubpathFromDenoModuleResolveError (LCOM4 4) libs/node_resolver/errors.rs:219— PackageSubpathFromDenoModuleResolveError's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Low cohesion: WhichSysAdapter (LCOM4 4) runtime/permissions/which.rs:40— WhichSysAdapter's methods fall into 4 groups that share no field and call none of each other, against a bar of more than 3 for this run (LCOM4, configurable — your repository's bar is the one quoted here). Each group is a set of methods reachable from one another through shared fields or direct calls, so 4 groups means the type has that many internally-connected clusters with nothing tying them together. Types whose shape makes a high count expected — and which would otherwise dominate this list — are excluded before this row is raised, so this is a genuine split candidate rather than a metric reading. It is still a shape, not a defect: confirm the groups match responsibilities you can name before splitting.
Hotspot: libs/cli_parser/src/convert.rs libs/cli_parser/src/convert.rs:162— libs/cli_parser/src/convert.rs changed 10 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 56 in deno_cli_parser::convert::convert at line 162. 5 of those changes were fix/bug commits, and the other 5 changed it for other reasons — this file is under both repair and feature pressure. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- libs/cli_parser/src/convert.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: REDACTED REDACTED:607— REDACTED changed 10 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 49 in (anonymous) at line 607. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- REDACTED`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: cli/lib.rs cli/lib.rs:124— cli/lib.rs changed 4 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 71 in deno::run_subcommand at line 124. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- cli/lib.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: ext/http/http_next.rs ext/http/http_next.rs:4532— ext/http/http_next.rs changed 4 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 68 in deno_http::http_next::serve_http11_raw at line 4532. 3 of those changes were fix/bug commits, so the churn is repair rather than feature work. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/http/http_next.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: cli/tools/desktop.rs cli/tools/desktop.rs:176— cli/tools/desktop.rs changed 5 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 53 in deno::tools::desktop::compile_desktop at line 176. 4 of those changes were fix/bug commits, so the churn is repair rather than feature work. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- cli/tools/desktop.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: REDACTED REDACTED:505— REDACTED changed 3 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 87 in _http_client.ClientRequest at line 505. 2 of those changes were fix/bug commits, so the churn is repair rather than feature work. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- REDACTED`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: runtime/js/99_main.js runtime/js/99_main.js:936— runtime/js/99_main.js changed 7 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 34 in 99_main.bootstrapMainRuntime at line 936. 2 of those changes were fix/bug commits, and the other 5 changed it for other reasons — this file is under both repair and feature pressure. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- runtime/js/99_main.js`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: ext/node/ops/tls_wrap.rs ext/node/ops/tls_wrap.rs:4895— ext/node/ops/tls_wrap.rs changed 3 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 35 in deno_node::ops::tls_wrap::build_client_config at line 4895. 3 of those changes were fix/bug commits, so the churn is repair rather than feature work. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/node/ops/tls_wrap.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: libs/cli_parser/src/parse.rs libs/cli_parser/src/parse.rs:112— libs/cli_parser/src/parse.rs changed 2 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 50 in deno_cli_parser::parse::parse_args at line 112. 1 of those changes was a fix/bug commit, and the other 1 changed it for other reasons — this file is under both repair and feature pressure. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- libs/cli_parser/src/parse.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: libs/core/runtime/jsruntime.rs libs/core/runtime/jsruntime.rs:815— libs/core/runtime/jsruntime.rs changed 5 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 18 in JsRuntime::new_inner at line 815. 2 of those changes were fix/bug commits, and the other 3 changed it for other reasons — this file is under both repair and feature pressure. Before the next change lands here, make sure the area it touches is under test, then split that area out of the file so the following change is smaller than this one — a file this often edited pays the complexity back every time. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- libs/core/runtime/jsruntime.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: cli/rt/run.rs cli/rt/run.rs:469— cli/rt/run.rs changed 3 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 25 in EmbeddedModuleLoader::load_default at line 469. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- cli/rt/run.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: ext/fetch/lib.rs ext/fetch/lib.rs:1045— ext/fetch/lib.rs changed 4 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 17 in deno_fetch::create_http_client at line 1045. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/fetch/lib.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: libs/cli_parser/src/completions.rs libs/cli_parser/src/completions.rs:151— libs/cli_parser/src/completions.rs changed 4 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 15 in deno_cli_parser::completions::generate_zsh at line 151. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- libs/cli_parser/src/completions.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: ext/node/polyfills/https.ts ext/node/polyfills/https.ts:255— ext/node/polyfills/https.ts changed 2 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 22 in https.Agent.getName at line 255. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/node/polyfills/https.ts`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: ext/web/13_message_port.js ext/web/13_message_port.js:294— ext/web/13_message_port.js changed 2 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 20 in MessagePort.postMessage at line 294. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/web/13_message_port.js`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Hotspot: libs/npm_cache/registry_info.rs libs/npm_cache/registry_info.rs:295— libs/npm_cache/registry_info.rs changed 2 times in last 90 days, and the most complex body those changes touched has cyclomatic complexity 18 in RegistryInfoProviderInner::create_load_future at line 295. Frequent change and high complexity in one file compound: schedule the next change to it to include carving out the part being edited, with the area under test before it moves. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- libs/npm_cache/registry_info.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
R4 · Test Coverage· No test reaches this file · ×16
No test reaches this file ext/web/06_streams.js:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/http2.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/internal/errors.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/testing.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/internal/buffer.mjs:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/net.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/internal/child_process.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/worker_threads.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/repl.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file REDACTED:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/_tls_wrap.js:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/web/02_event.js:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file REDACTED:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/_http_outgoing.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/node/polyfills/dgram.ts:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
No test reaches this file ext/webidl/00_webidl.js:1— No test imports this module directly or transitively. Import reachability cannot see a test that executes a file by path instead of importing it, nor one that drives it through a running browser by navigating to a URL — if neither does, no test reaches this one.
Duplicated block (11 lines × 3) ext/crypto/subtle_crypto.rs:903— ext/crypto/subtle_crypto.rs:903-913 | ext/crypto/subtle_generate_key.rs:800-810 | ext/crypto/subtle_import_key.rs:1944-1954 — before extracting anything, compare `ext/crypto/subtle_crypto.rs` and `ext/crypto/subtle_generate_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 38 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 3) ext/crypto/subtle_decrypt.rs:285— ext/crypto/subtle_decrypt.rs:285-295 | ext/crypto/subtle_encrypt.rs:341-351 | ext/crypto/subtle_sign.rs:344-354 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 3) ext/crypto/subtle_import_key.rs:403— ext/crypto/subtle_import_key.rs:403-413 | ext/crypto/subtle_import_key.rs:423-433 | ext/crypto/subtle_import_key.rs:557-568 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) ext/napi/js_native_api.rs:2829— ext/napi/js_native_api.rs:2829-2839 | ext/napi/js_native_api.rs:2870-2880 | ext/napi/js_native_api.rs:2920-2930 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) ext/telemetry/lib.rs:2924— ext/telemetry/lib.rs:2924-2934 | ext/telemetry/lib.rs:2969-2979 | ext/telemetry/lib.rs:3022-3032 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) ext/telemetry/lib.rs:3092— ext/telemetry/lib.rs:3092-3102 | ext/telemetry/lib.rs:3130-3140 | ext/telemetry/lib.rs:3174-3184 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) ext/web/console/inspect.rs:3042— ext/web/console/inspect.rs:3042-3052 | ext/web/console/mod.rs:1532-1542 | ext/web/console/mod.rs:1675-1685 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (11 lines × 3) libs/resolver/cjs/analyzer/deno_ast.rs:180— libs/resolver/cjs/analyzer/deno_ast.rs:180-190 | libs/resolver/cjs/analyzer/deno_ast.rs:221-231 | libs/resolver/cjs/analyzer/deno_ast.rs:239-249 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) ext/crypto/decrypt.rs:165— ext/crypto/decrypt.rs:165-175 | ext/crypto/decrypt.rs:177-187 | ext/crypto/decrypt.rs:188-198 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 3) libs/npm_cache/rt.rs:14— libs/npm_cache/rt.rs:14-24 | libs/npm_installer/rt.rs:14-24 | libs/resolver/rt.rs:15-25 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (11 lines × 3) ext/napi/js_native_api.rs:3664— ext/napi/js_native_api.rs:3664-3674 | ext/napi/js_native_api.rs:4005-4015 | ext/napi/node_api.rs:614-624 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (11 lines × 3) ext/webgpu/compute_pass.rs:97— ext/webgpu/compute_pass.rs:97-107 | ext/webgpu/render_pass.rs:443-453 | ext/webgpu/render_pass.rs:461-471 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_pass.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 146 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 3) ext/webgpu/compute_pass.rs:120— ext/webgpu/compute_pass.rs:120-130 | ext/webgpu/compute_pass.rs:143-153 | ext/webgpu/render_pass.rs:194-204 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_pass.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 146 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11 lines × 3) libs/config/deno_json/mod.rs:2315— libs/config/deno_json/mod.rs:2315-2325 | libs/config/deno_json/mod.rs:2343-2353 | libs/config/deno_json/mod.rs:2422-2432 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Off the main sequence: deno_crypto_provider — deno_crypto_provider: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 2 project(s), so it's rigid to change.
Off the main sequence: deno_dotenv — deno_dotenv: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 2 project(s), so it's rigid to change.
Off the main sequence: deno_http_h1 — deno_http_h1: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 1 project(s), so it's rigid to change.
Off the main sequence: deno_npmrc — deno_npmrc: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 5 project(s), so it's rigid to change.
Off the main sequence: deno_signals — deno_signals: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 6 project(s), so it's rigid to change.
Off the main sequence: node_shim — node_shim: abstractness 0.00, instability 0.00, distance 1.00 — zone of pain — concrete and depended on by 2 project(s), so it's rigid to change.
Off the main sequence: deno_lockfile — deno_lockfile: abstractness 0.03, instability 0.00, distance 0.97 — zone of pain — concrete and depended on by 4 project(s), so it's rigid to change.
Off the main sequence: deno_subprocess_windows — deno_subprocess_windows: abstractness 0.06, instability 0.00, distance 0.94 — zone of pain — concrete and depended on by 5 project(s), so it's rigid to change.
Off the main sequence: deno_permissions — deno_permissions: abstractness 0.15, instability 0.00, distance 0.85 — zone of pain — concrete and depended on by 17 project(s), so it's rigid to change.
Off the main sequence: deno_features — deno_features: abstractness 0.00, instability 0.20, distance 0.80 — zone of pain — concrete and depended on by 4 project(s), so it's rigid to change.
Off the main sequence: deno_core — deno_core: abstractness 0.13, instability 0.08, distance 0.80 — zone of pain — concrete and depended on by 36 project(s), so it's rigid to change.
Off the main sequence: deno_tls — deno_tls: abstractness 0.10, instability 0.13, distance 0.78 — zone of pain — concrete and depended on by 7 project(s), so it's rigid to change.
Off the main sequence: deno_package_json — deno_package_json: abstractness 0.14, instability 0.11, distance 0.75 — zone of pain — concrete and depended on by 8 project(s), so it's rigid to change.
Off the main sequence: deno_npm — deno_npm: abstractness 0.05, instability 0.22, distance 0.73 — zone of pain — concrete and depended on by 7 project(s), so it's rigid to change.
Duplicated block (9 lines × 3) cli/lsp/language_server.rs:1769— cli/lsp/language_server.rs:1769-1777 | cli/lsp/language_server.rs:1811-1819 | cli/lsp/language_server.rs:4471-4479 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) ext/crypto/crypto_key.rs:221— ext/crypto/crypto_key.rs:221-229 | ext/crypto/node_interop.rs:379-387 | ext/crypto/subtle_import_key.rs:1971-1979 — before extracting anything, compare `ext/crypto/node_interop.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 3) ext/crypto/node_interop.rs:517— ext/crypto/node_interop.rs:517-525 | ext/crypto/subtle_import_key.rs:1909-1917 | ext/crypto/subtle_import_key.rs:1961-1969 — before extracting anything, compare `ext/crypto/node_interop.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 3) ext/crypto/subtle_derive_bits.rs:405— ext/crypto/subtle_derive_bits.rs:405-413 | ext/crypto/subtle_import_key.rs:1912-1920 | ext/crypto/subtle_key.rs:152-160 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_key.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 3) ext/crypto/subtle_derive_bits.rs:559— ext/crypto/subtle_derive_bits.rs:559-567 | ext/crypto/subtle_derive_bits.rs:596-604 | ext/crypto/subtle_derive_bits.rs:615-623 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) ext/crypto/subtle_generate_key.rs:487— ext/crypto/subtle_generate_key.rs:487-495 | ext/crypto/subtle_generate_key.rs:503-511 | ext/crypto/subtle_generate_key.rs:519-527 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) ext/http/http_next.rs:1037— ext/http/http_next.rs:1037-1045 | ext/http/http_next.rs:1053-1061 | ext/http/http_next.rs:1069-1077 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) ext/node/ops/http2/session.rs:282— ext/node/ops/http2/session.rs:282-290 | ext/node/ops/http2/session.rs:340-348 | ext/node/ops/http2/session.rs:362-370 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) ext/web/console/mod.rs:841— ext/web/console/mod.rs:841-849 | ext/web/console/mod.rs:875-883 | ext/web/console/mod.rs:909-917 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) runtime/worker.rs:1076— runtime/worker.rs:1076-1084 | runtime/worker.rs:1094-1102 | runtime/worker.rs:1110-1118 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 3) libs/core/arena/shared_arena.rs:94— libs/core/arena/shared_arena.rs:94-102 | libs/core/arena/shared_atomic_arena.rs:94-102 | libs/core/arena/unique_arena.rs:76-84 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from all 3 call sites, so a change lands once.
Duplicated block (9 lines × 3) ext/crypto/node_interop.rs:105— ext/crypto/node_interop.rs:105-113 | ext/crypto/subtle_derive_bits.rs:402-410 | ext/crypto/subtle_key.rs:172-180 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_key.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 3) ext/crypto/subtle_export_key.rs:723— ext/crypto/subtle_export_key.rs:723-731 | ext/crypto/subtle_export_key.rs:803-811 | ext/crypto/subtle_export_key.rs:884-892 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) cli/tools/bundle/mod.rs:526— cli/tools/bundle/mod.rs:526-533 | cli/tools/transpile.rs:198-205 | cli/tools/transpile.rs:322-329 — before extracting anything, compare `cli/tools/bundle/mod.rs` and `cli/tools/transpile.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 40 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 3) ext/crypto/subtle_crypto.rs:920— ext/crypto/subtle_crypto.rs:920-927 | ext/crypto/subtle_generate_key.rs:857-864 | ext/crypto/subtle_import_key.rs:1990-1997 — before extracting anything, compare `ext/crypto/subtle_crypto.rs` and `ext/crypto/subtle_generate_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 38 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 3) ext/crypto/subtle_export_key.rs:784— ext/crypto/subtle_export_key.rs:784-791 | ext/crypto/subtle_export_key.rs:865-872 | ext/crypto/subtle_export_key.rs:933-940 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) ext/napi/js_native_api.rs:541— ext/napi/js_native_api.rs:541-548 | ext/napi/js_native_api.rs:568-575 | ext/napi/js_native_api.rs:623-630 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) ext/napi/js_native_api.rs:2709— ext/napi/js_native_api.rs:2709-2716 | ext/napi/js_native_api.rs:2737-2744 | ext/napi/js_native_api.rs:2765-2772 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) ext/node_crypto/lib.rs:418— ext/node_crypto/lib.rs:418-426 | ext/node_crypto/lib.rs:467-474 | ext/node_crypto/lib.rs:551-558 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) libs/cli_parser/src/convert.rs:1517— libs/cli_parser/src/convert.rs:1517-1524 | libs/cli_parser/src/convert.rs:1581-1588 | libs/cli_parser/src/convert.rs:2637-2644 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) REDACTED:1135— REDACTED:1135-1142 | REDACTED:1162-1169 | REDACTED:1171-1178 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) REDACTED:1978— REDACTED:1978-1985 | libs/core/uv_compat/tty.rs:2224-2231 | libs/core/uv_compat/tty.rs:2311-2318 — before extracting anything, compare `REDACTED` and `libs/core/uv_compat/tty.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 52 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 3) libs/node_shim/lib.rs:3585— libs/node_shim/lib.rs:3585-3592 | libs/node_shim/lib.rs:3664-3671 | libs/node_shim/lib.rs:3714-3721 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) libs/npm_installer/package_json.rs:294— libs/npm_installer/package_json.rs:294-301 | libs/npm_installer/package_json.rs:343-350 | libs/npm_installer/package_json.rs:384-391 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 3) cli/lib/util/text_encoding.rs:11— cli/lib/util/text_encoding.rs:11-18 | ext/fs/interface.rs:497-505 | libs/resolver/loader/npm.rs:305-312 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (8 lines × 3) ext/crypto/subtle_derive_bits.rs:682— ext/crypto/subtle_derive_bits.rs:682-689 | ext/crypto/subtle_sign.rs:587-594 | ext/crypto/subtle_verify.rs:397-404 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_sign.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 46 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
deno_node::ops::tls_wrap::build_client_config (cyclomatic 35) ext/node/ops/tls_wrap.rs:4895— deno_node::ops::tls_wrap::build_client_config has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::tls_wrap::build_server_config (cyclomatic 34) ext/node/ops/tls_wrap.rs:5397— deno_node::ops::tls_wrap::build_server_config has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::tls_wrap::parse_extensions (cyclomatic 24) ext/node/ops/tls_wrap.rs:4052— deno_node::ops::tls_wrap::parse_extensions has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_node::ops::tls_wrap::rustls_error_to_node_error (cyclomatic 26) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_node::ops::llhttp::binding::consume_read_callback (cyclomatic 23) ext/node/ops/llhttp/binding.rs:730— deno_node::ops::llhttp::binding::consume_read_callback has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::stream_wrap::on_uv_read (cyclomatic 22) ext/node/ops/stream_wrap.rs:617— deno_node::ops::stream_wrap::on_uv_read has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::http2::session::on_stream_read_callback (cyclomatic 21) ext/node/ops/http2/session.rs:1410— deno_node::ops::http2::session::on_stream_read_callback has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::shell::scan_and_split (cyclomatic 20) ext/node/ops/shell.rs:34— deno_node::ops::shell::scan_and_split has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::http2::session::on_frame_recv_callback (cyclomatic 19) ext/node/ops/http2/session.rs:782— deno_node::ops::http2::session::on_frame_recv_callback has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::assert::get_first_expression (cyclomatic 17) ext/node/ops/assert.rs:92— deno_node::ops::assert::get_first_expression has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::ipc::impl_::serialize_v8_value (cyclomatic 17) ext/node/ops/ipc.rs:75— deno_node::ops::ipc::impl_::serialize_v8_value has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node::ops::v8::op_v8_query_objects_count (cyclomatic 17) ext/node/ops/v8.rs:400— deno_node::ops::v8::op_v8_query_objects_count has cyclomatic complexity 17 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_node::ops::vm::property_setter (cyclomatic 16) ext/node/ops/vm.rs:996— deno_node::ops::vm::property_setter has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
TooManyFields: EnvironmentOptions libs/node_shim/lib.rs:147— TooManyFields — 132 stored fields beside 1 method. The bar is 30 stored fields; this is 102 over it, 4.40× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: FsConstants ext/node/ops/constant.rs:9— TooManyFields — 57 stored fields. The bar is 30 stored fields; this is 27 over it, 1.90× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: Flags libs/cli_parser/src/flags.rs:943— TooManyFields — 48 stored fields beside 2 methods. The bar is 30 stored fields; this is 18 over it, 1.60× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: TLSWrapInner ext/node/ops/tls_wrap.rs:1061— TooManyFields — 42 stored fields beside 11 methods. The bar is 30 stored fields; this is 12 over it, 1.40× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: PerProcessOptions libs/node_shim/lib.rs:603— TooManyFields — 38 stored fields beside 1 method. The bar is 30 stored fields; this is 8 over it, 1.27× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: ConfigFileJson libs/config/deno_json/mod.rs:1501— TooManyFields — 35 stored fields. The bar is 30 stored fields; this is 5 over it, 1.17× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: Session ext/node/ops/http2/session.rs:2022— TooManyFields — 34 stored fields beside 28 methods. The bar is 30 stored fields; this is 4 over it, 1.13× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: ContextState libs/core/runtime/jsrealm.rs:74— TooManyFields — 33 stored fields beside 3 methods. The bar is 30 stored fields; this is 3 over it, 1.10× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: GeneratorState libs/ops/op2/generator_state.rs:7— TooManyFields — 33 stored fields. The bar is 30 stored fields; this is 3 over it, 1.10× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: Ctx ext/web/console/inspect.rs:194— TooManyFields — 32 stored fields beside 1 method. The bar is 30 stored fields; this is 2 over it, 1.07× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: PackageJson libs/package_json/lib.rs:379— TooManyFields — 31 stored fields beside 9 methods. The bar is 30 stored fields; this is 1 over it, 1.03× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
TooManyFields: LibMainWorkerOptions cli/lib/worker.rs:266— TooManyFields — 31 stored fields. The bar is 30 stored fields; this is 1 over it, 1.03× the bar. This is width in DATA, not behaviour: every reader that takes the whole type couples to all of its fields, so a change to any one of them is a change every reader has to be checked against. To reduce it, group the fields that are read together by the same callers into a smaller type of their own, and have this one hold that type as a single member — each reader then names only the group it uses.
D4 · Code Duplication· Members sharing a duplicated core (4 members, 50+ identical tokens) · ×12
Members sharing a duplicated core (4 members, 50+ identical tokens) cli/lsp/tsc.rs:635— cli/lsp/tsc.rs:635-661 | cli/lsp/tsc.rs:1037-1063 | cli/lsp/tsc.rs:1170-1196 | cli/lsp/tsc.rs:1335-1367 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/crypto/subtle_import_key.rs:652— ext/crypto/subtle_import_key.rs:652-784 | ext/crypto/subtle_import_key.rs:793-907 | ext/crypto/subtle_import_key.rs:916-1020 | ext/crypto/subtle_import_key.rs:1381-1506 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/fs/ops.rs:1150— ext/fs/ops.rs:1150-1180 | ext/fs/ops.rs:1189-1223 | ext/fs/ops.rs:1232-1268 | ext/fs/ops.rs:1277-1313 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/fs/ops.rs:1489— ext/fs/ops.rs:1489-1525 | ext/fs/ops.rs:1563-1603 | ext/fs/ops.rs:1634-1671 | ext/net/ops.rs:1128-1235 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/node/ops/fs.rs:570— ext/node/ops/fs.rs:570-591 | ext/node/ops/fs.rs:616-628 | ext/node/ops/fs.rs:651-663 | ext/node/ops/fs.rs:763-775 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/node/ops/llhttp/binding.rs:310— ext/node/ops/llhttp/binding.rs:310-343 | ext/node/ops/llhttp/binding.rs:446-590 | ext/node/ops/llhttp/binding.rs:596-637 | ext/node/ops/llhttp/binding.rs:639-685 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/node/ops/llhttp/binding.rs:735— ext/node/ops/llhttp/binding.rs:735-912 | ext/node/ops/stream_wrap.rs:621-808 | ext/node/ops/stream_wrap.rs:935-995 | ext/node/ops/stream_wrap.rs:1005-1054 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/telemetry/lib.rs:2900— ext/telemetry/lib.rs:2900-2913 | ext/telemetry/lib.rs:2923-2955 | ext/telemetry/lib.rs:2968-3006 | ext/telemetry/lib.rs:3021-3067 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) ext/web/console/mod.rs:1107— ext/web/console/mod.rs:1107-1125 | ext/web/console/mod.rs:1230-1249 | ext/web/console/mod.rs:1258-1294 | ext/web/console/mod.rs:1342-1371 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) libs/resolver/bun_lockfile_import.rs:40— libs/resolver/bun_lockfile_import.rs:40-188 | libs/resolver/npm_lockfile_import.rs:64-266 | libs/resolver/pnpm_lockfile_import.rs:43-246 | libs/resolver/yarn_lockfile_import.rs:30-151 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) libs/resolver/bun_lockfile_import.rs:339— libs/resolver/bun_lockfile_import.rs:339-350 | libs/resolver/npm_lockfile_import.rs:285-296 | libs/resolver/pnpm_lockfile_import.rs:739-756 | libs/resolver/yarn_lockfile_import.rs:180-190 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Members sharing a duplicated core (4 members, 50+ identical tokens) runtime/permissions/lib.rs:2523— runtime/permissions/lib.rs:2523-2540 | runtime/permissions/lib.rs:2542-2559 | runtime/permissions/lib.rs:2561-2578 | runtime/permissions/lib.rs:2580-2597 — These 4 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
Duplicated block (21 lines × 2) ext/crypto/subtle_generate_key.rs:852— ext/crypto/subtle_generate_key.rs:852-872 | ext/crypto/subtle_import_key.rs:1985-2005 — before extracting anything, compare `ext/crypto/subtle_generate_key.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 118 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (21 lines × 2) ext/node/ops/vm.rs:486— ext/node/ops/vm.rs:486-506 | ext/node/ops/vm.rs:596-616 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) ext/node_crypto/keys.rs:2771— ext/node_crypto/keys.rs:2771-2791 | ext/node_crypto/keys.rs:2828-2848 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) ext/node_crypto/lib.rs:520— ext/node_crypto/lib.rs:520-540 | ext/node_crypto/lib.rs:578-598 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) ext/node_sqlite/sql_tag_store.rs:161— ext/node_sqlite/sql_tag_store.rs:161-181 | ext/node_sqlite/statement.rs:338-358 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (21 lines × 2) libs/core/modules/map.rs:450— libs/core/modules/map.rs:450-470 | libs/core/modules/map.rs:555-575 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) libs/core/ops_builtin_v8.rs:377— libs/core/ops_builtin_v8.rs:377-397 | libs/core/ops_builtin_v8.rs:529-549 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) libs/core/uv_compat/stream.rs:622— libs/core/uv_compat/stream.rs:622-642 | libs/core/uv_compat/tty.rs:3183-3203 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (21 lines × 2) libs/http_h1/parse.rs:158— libs/http_h1/parse.rs:158-178 | libs/http_h1/parse.rs:211-231 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) libs/http_h1/write.rs:228— libs/http_h1/write.rs:228-248 | libs/http_h1/write.rs:297-317 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) libs/node_shim/lib.rs:2877— libs/node_shim/lib.rs:2877-2897 | libs/node_shim/lib.rs:2902-2922 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21 lines × 2) libs/ops/op2/dispatch_async.rs:150— libs/ops/op2/dispatch_async.rs:150-170 | libs/ops/op2/dispatch_slow.rs:141-161 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (15 lines × 2) cli/ops/bench.rs:80— cli/ops/bench.rs:80-94 | cli/ops/testing.rs:109-123 — before extracting anything, compare `cli/ops/bench.rs` and `cli/ops/testing.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 39 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (15 lines × 2) ext/fs/ops.rs:1166— ext/fs/ops.rs:1166-1180 | ext/fs/ops.rs:1209-1223 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) ext/node/ops/vm.rs:165— ext/node/ops/vm.rs:165-179 | ext/node/ops/vm.rs:1594-1608 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) libs/cache_dir/file_fetcher/mod.rs:1122— libs/cache_dir/file_fetcher/mod.rs:1122-1136 | libs/cache_dir/file_fetcher/mod.rs:1146-1160 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) libs/config/workspace/discovery.rs:858— libs/config/workspace/discovery.rs:858-872 | libs/config/workspace/discovery.rs:922-936 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) libs/core/modules/map/dynamic.rs:117— libs/core/modules/map/dynamic.rs:117-131 | libs/core/modules/map/dynamic.rs:148-162 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) libs/core/ops_builtin_v8.rs:864— libs/core/ops_builtin_v8.rs:864-878 | libs/core/ops_builtin_v8.rs:970-984 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) REDACTED:1702— REDACTED:1702-1721 | REDACTED:2117-2131 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15 lines × 2) libs/eszip/v2.rs:293— libs/eszip/v2.rs:293-307 | libs/resolver/workspace.rs:1855-1869 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (15 lines × 2) libs/ops/conversion/from_v8/enum.rs:177— libs/ops/conversion/from_v8/enum.rs:177-191 | libs/ops/conversion/to_v8/enum.rs:363-377 — `libs/ops/conversion/from_v8/enum.rs` and `libs/ops/conversion/to_v8/enum.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 4 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
Duplicated block (15 lines × 2) libs/ops/conversion/from_v8/struct.rs:285— libs/ops/conversion/from_v8/struct.rs:285-299 | libs/ops/conversion/to_v8/struct.rs:266-280 — `libs/ops/conversion/from_v8/struct.rs` and `libs/ops/conversion/to_v8/struct.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 5 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
Duplicated block (15 lines × 2) cli/tools/bundle/esbuild.rs:82— cli/tools/bundle/esbuild.rs:82-96 | cli/tsc/native.rs:137-153 — before extracting anything, compare `cli/tools/bundle/esbuild.rs` and `cli/tsc/native.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 42 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
deno_resolver::npm_lockfile_import::package_lock_to_deno_lock_v5 (cognitive 63) libs/resolver/npm_lockfile_import.rs:62— deno_resolver::npm_lockfile_import::package_lock_to_deno_lock_v5 has cognitive complexity 63 (threshold 15). Drivers by points: if/else 22 (42 pts), loops 7 (12 pts), match/switch 3 (7 pts), boolean chains 2 (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::pnpm_lockfile_import::pnpm_lock_to_deno_lock_v5 (cognitive 59) libs/resolver/pnpm_lockfile_import.rs:41— deno_resolver::pnpm_lockfile_import::pnpm_lock_to_deno_lock_v5 has cognitive complexity 59 (threshold 15). Drivers by points: if/else 20 (45 pts), loops 7 (13 pts), boolean chains 1 (nesting depth added 31). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::bun_lockfile_import::bun_lock_to_deno_lock_v5 (cognitive 44) libs/resolver/bun_lockfile_import.rs:38— deno_resolver::bun_lockfile_import::bun_lock_to_deno_lock_v5 has cognitive complexity 44 (threshold 15). Drivers by points: if/else 17 (37 pts), loops 3 (6 pts), match/switch 1 (nesting depth added 23). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::patch_react_cves (cognitive 39) libs/resolver/lib.rs:715— deno_resolver::patch_react_cves has cognitive complexity 39 (threshold 15). Drivers by points: if/else 16 (32 pts), loops 3 (4 pts), match/switch 2, boolean chains 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::yarn_lockfile_import::yarn_lock_to_deno_lock_v5 (cognitive 30) libs/resolver/yarn_lockfile_import.rs:28— deno_resolver::yarn_lockfile_import::yarn_lock_to_deno_lock_v5 has cognitive complexity 30 (threshold 15). Drivers by points: if/else 14 (25 pts), loops 4 (5 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::yarn_lockfile_import::parse_yarn_v1 (cognitive 30) libs/resolver/yarn_lockfile_import.rs:208— deno_resolver::yarn_lockfile_import::parse_yarn_v1 has cognitive complexity 30 (threshold 15). Drivers by points: if/else 11 (21 pts), match/switch 2 (7 pts), boolean chains 1, loops 1 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::pnpm_lockfile_import::collect_importer_specifiers (cognitive 28) libs/resolver/pnpm_lockfile_import.rs:435— deno_resolver::pnpm_lockfile_import::collect_importer_specifiers has cognitive complexity 28 (threshold 15). Drivers by points: if/else 9 (21 pts), match/switch 1 (4 pts), loops 2 (3 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::emit::ensure_no_import_assertion (cognitive 23) libs/resolver/emit.rs:705— deno_resolver::emit::ensure_no_import_assertion has cognitive complexity 23 (threshold 15). Drivers by points: if/else 4 (13 pts), match/switch 2 (5 pts), boolean chains 4, loops 1 (nesting depth added 12). Of this number, 22 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::graph::get_import_prefix_missing_error (cognitive 23) libs/resolver/graph.rs:1005— deno_resolver::graph::get_import_prefix_missing_error has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (17 pts), boolean chains 4, match/switch 1 (2 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::graph::format_deno_graph_error (cognitive 19) libs/resolver/graph.rs:1076— deno_resolver::graph::format_deno_graph_error has cognitive complexity 19 (threshold 15). Drivers by points: if/else 5 (13 pts), loops 2 (6 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_resolver::npm::managed::common::find_definitely_typed_package_from_snapshot (cognitive 17) libs/resolver/npm/managed/common.rs:104— deno_resolver::npm::managed::common::find_definitely_typed_package_from_snapshot has cognitive complexity 17 (threshold 15). Drivers by points: if/else 4 (9 pts), match/switch 3 (6 pts), boolean chains 1, loops 1 (nesting depth added 8). Of this number, 16 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Duplicated block (17 lines × 2) cli/lsp/completions.rs:661— cli/lsp/completions.rs:661-677 | cli/lsp/completions.rs:820-836 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) cli/lsp/registries.rs:809— cli/lsp/registries.rs:809-825 | cli/lsp/registries.rs:953-969 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) cli/tools/bump_version.rs:638— cli/tools/bump_version.rs:638-654 | cli/tools/bump_version.rs:681-697 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) ext/cache/lscache.rs:96— ext/cache/lscache.rs:96-112 | ext/cache/lscache.rs:272-288 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) ext/crypto/export_key.rs:260— ext/crypto/export_key.rs:260-276 | ext/crypto/export_key.rs:280-296 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) ext/crypto/subtle_decrypt.rs:562— ext/crypto/subtle_decrypt.rs:562-578 | ext/crypto/subtle_encrypt.rs:632-648 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (17 lines × 2) ext/http/http_next.rs:4784— ext/http/http_next.rs:4784-4800 | ext/http/http_next.rs:4862-4878 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) ext/node_sqlite/sql_tag_store.rs:753— ext/node_sqlite/sql_tag_store.rs:753-769 | ext/node_sqlite/statement.rs:962-978 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (17 lines × 2) REDACTED:1866— REDACTED:1866-1882 | REDACTED:2003-2019 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17 lines × 2) libs/npm_installer/hoisted.rs:769— libs/npm_installer/hoisted.rs:769-785 | libs/npm_installer/local.rs:1128-1144 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (17 lines × 2) libs/serde_v8/magic/v8slice.rs:159— libs/serde_v8/magic/v8slice.rs:159-175 | libs/serde_v8/magic/v8slice.rs:184-200 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 3) cli/standalone/native_addons.rs:218— cli/standalone/native_addons.rs:218-223 | cli/standalone/native_addons.rs:267-272 | cli/tools/compile.rs:452-457 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (6 lines × 3) ext/cron/socket.rs:427— ext/cron/socket.rs:427-432 | ext/cron/socket.rs:442-447 | ext/cron/socket.rs:455-460 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/crypto/subtle_import_key.rs:757— ext/crypto/subtle_import_key.rs:757-762 | ext/crypto/subtle_import_key.rs:883-888 | ext/crypto/subtle_import_key.rs:996-1001 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/crypto/subtle_import_key.rs:767— ext/crypto/subtle_import_key.rs:767-772 | ext/crypto/subtle_import_key.rs:893-898 | ext/crypto/subtle_import_key.rs:1006-1011 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/crypto/subtle_import_key.rs:1131— ext/crypto/subtle_import_key.rs:1131-1136 | ext/crypto/subtle_import_key.rs:1151-1156 | ext/crypto/subtle_import_key.rs:1167-1172 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/node/ops/http2/session.rs:329— ext/node/ops/http2/session.rs:329-334 | ext/node/ops/http2/session.rs:2534-2539 | ext/node/ops/http2/session.rs:3205-3210 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/node/ops/process.rs:539— ext/node/ops/process.rs:539-544 | ext/os/lib.rs:716-721 | runtime/ops/worker_host.rs:943-948 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (6 lines × 3) ext/node/ops/stream_wrap.rs:1423— ext/node/ops/stream_wrap.rs:1423-1428 | ext/node/ops/stream_wrap.rs:1922-1927 | ext/node/ops/stream_wrap.rs:2002-2007 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) libs/resolver/cjs/analyzer/deno_ast.rs:204— libs/resolver/cjs/analyzer/deno_ast.rs:204-209 | libs/resolver/cjs/analyzer/deno_ast.rs:253-258 | libs/resolver/cjs/analyzer/deno_ast.rs:266-271 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 3) ext/fetch/lib.rs:135— ext/fetch/lib.rs:135-140 | ext/kv/remote.rs:39-44 | ext/net/lib.rs:103-108 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (6 lines × 3) cli/tools/desktop.rs:1697— cli/tools/desktop.rs:1697-1702 | cli/tools/desktop.rs:1828-1833 | cli/tools/desktop.rs:3306-3311 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
deno_http::http_next::serve_http11_raw (cognitive 184) ext/http/http_next.rs:4532— deno_http::http_next::serve_http11_raw has cognitive complexity 184 (threshold 15). Drivers by points: if/else 42 (139 pts), match/switch 9 (29 pts), boolean chains 15, loops 1 (nesting depth added 117). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_http::http_next::write_h1_stream_response_shared (cognitive 54) ext/http/http_next.rs:4338— deno_http::http_next::write_h1_stream_response_shared has cognitive complexity 54 (threshold 15). Drivers by points: if/else 18 (40 pts), match/switch 4 (9 pts), boolean chains 4, loops 1 (nesting depth added 27). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::http_next::write_h1_stream_response (cognitive 36) ext/http/http_next.rs:4184— deno_http::http_next::write_h1_stream_response has cognitive complexity 36 (threshold 15). Drivers by points: if/else 12 (22 pts), match/switch 4 (9 pts), boolean chains 4, loops 1 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::http_next::op_http_get_request_headers (cognitive 23) ext/http/http_next.rs:2367— deno_http::http_next::op_http_get_request_headers has cognitive complexity 23 (threshold 15). Drivers by points: if/else 11 (20 pts), loops 2 (3 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::parse_serve_address (cognitive 22) ext/http/lib.rs:1852— deno_http::parse_serve_address has cognitive complexity 22 (threshold 15). Drivers by points: match/switch 7 (16 pts), if/else 3 (6 pts) (nesting depth added 12). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_http::http_next::is_normal_close (cognitive 19) ext/http/http_next.rs:5626— deno_http::http_next::is_normal_close has cognitive complexity 19 (threshold 15). Drivers by points: if/else 12 (19 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::http_next::write_h1_flat_response (cognitive 18) ext/http/http_next.rs:3561— deno_http::http_next::write_h1_flat_response has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (9 pts), match/switch 4 (5 pts), boolean chains 4 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::request_properties::req_host_from_addr (cognitive 18) ext/http/request_properties.rs:257— deno_http::request_properties::req_host_from_addr has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (12 pts), boolean chains 5, match/switch 1 (nesting depth added 6). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_http::op_http_write_resource (cognitive 16) ext/http/lib.rs:1508— deno_http::op_http_write_resource has cognitive complexity 16 (threshold 15). Drivers by points: if/else 4 (11 pts), match/switch 2 (4 pts), loops 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_http::http_next::write_h1_flat_response_shared (cognitive 16) ext/http/http_next.rs:3920— deno_http::http_next::write_h1_flat_response_shared has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (11 pts), match/switch 2 (3 pts), boolean chains 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_ops::op2::signature::parse_type (cognitive 92) libs/ops/op2/signature.rs:1699— deno_ops::op2::signature::parse_type has cognitive complexity 92 (threshold 15). Drivers by points: if/else 18 (46 pts), match/switch 15 (44 pts), boolean chains 2 (nesting depth added 57). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_ops::op2::dispatch_slow::from_arg (cognitive 39) libs/ops/op2/dispatch_slow.rs:425— deno_ops::op2::dispatch_slow::from_arg has cognitive complexity 39 (threshold 15). Drivers by points: if/else 16 (26 pts), match/switch 4 (13 pts) (nesting depth added 19). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_ops::op2::generate_op2 (cognitive 34) libs/ops/op2/mod.rs:203— deno_ops::op2::generate_op2 has cognitive complexity 34 (threshold 15). Drivers by points: if/else 20 (24 pts), boolean chains 4, loops 3, match/switch 2 (3 pts) (nesting depth added 5). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_ops::op2::object_wrap::generate_impl_ops (cognitive 31) libs/ops/op2/object_wrap.rs:75— deno_ops::op2::object_wrap::generate_impl_ops has cognitive complexity 31 (threshold 15). Drivers by points: if/else 13 (29 pts), loops 1, match/switch 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_ops::op2::signature::parse_generics (cognitive 31) libs/ops/op2/signature.rs:1228— deno_ops::op2::signature::parse_generics has cognitive complexity 31 (threshold 15). Drivers by points: if/else 11 (27 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_ops::op2::dispatch_fast::generate_dispatch_fast (cognitive 29) libs/ops/op2/dispatch_fast.rs:415— deno_ops::op2::dispatch_fast::generate_dispatch_fast has cognitive complexity 29 (threshold 15). Drivers by points: if/else 24, boolean chains 4, match/switch 1. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_ops::op2::dispatch_slow::generate_dispatch_slow (cognitive 27) libs/ops/op2/dispatch_slow.rs:76— deno_ops::op2::dispatch_slow::generate_dispatch_slow has cognitive complexity 27 (threshold 15). Drivers by points: if/else 25, boolean chains 2. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_ops::op2::dispatch_async::generate_dispatch_async (cognitive 26) libs/ops/op2/dispatch_async.rs:59— deno_ops::op2::dispatch_async::generate_dispatch_async has cognitive complexity 26 (threshold 15). Drivers by points: if/else 23, boolean chains 3. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_ops::op2::signature::parse_attribute (cognitive 21) libs/ops/op2/signature.rs:1337— deno_ops::op2::signature::parse_attribute has cognitive complexity 21 (threshold 15). Drivers by points: if/else 13 (18 pts), match/switch 2 (3 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_ops::op2::signature::parse_cppgc (cognitive 21) libs/ops/op2/signature.rs:1604— deno_ops::op2::signature::parse_cppgc has cognitive complexity 21 (threshold 15). Drivers by points: match/switch 6 (12 pts), if/else 4 (7 pts), boolean chains 2 (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_napi::js_native_api::napi_define_properties (cognitive 38) ext/napi/js_native_api.rs:842— deno_napi::js_native_api::napi_define_properties has cognitive complexity 38 (threshold 15). Drivers by points: if/else 17 (34 pts), match/switch 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::js_native_api::napi_define_class (cognitive 27) ext/napi/js_native_api.rs:311— deno_napi::js_native_api::napi_define_class has cognitive complexity 27 (threshold 15). Drivers by points: if/else 12 (20 pts), loops 2 (3 pts), match/switch 2 (3 pts), boolean chains 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::js_native_api::napi_get_typedarray_info (cognitive 20) ext/napi/js_native_api.rs:3875— deno_napi::js_native_api::napi_get_typedarray_info has cognitive complexity 20 (threshold 15). Drivers by points: if/else 19 (20 pts) (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_napi::js_native_api::create_external_string (cognitive 19) ext/napi/js_native_api.rs:1715— deno_napi::js_native_api::create_external_string has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (17 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::op_napi_open (cognitive 18) ext/napi/lib.rs:916— deno_napi::op_napi_open has cognitive complexity 18 (threshold 15). Drivers by points: if/else 7 (10 pts), match/switch 6 (7 pts), boolean chains 1 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::js_native_api::node_api_create_object_with_properties (cognitive 17) ext/napi/js_native_api.rs:1088— deno_napi::js_native_api::node_api_create_object_with_properties has cognitive complexity 17 (threshold 15). Drivers by points: if/else 10 (15 pts), loops 2 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::js_native_api::napi_check_object_type_tag (cognitive 17) ext/napi/js_native_api.rs:3252— deno_napi::js_native_api::napi_check_object_type_tag has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (12 pts), boolean chains 3, match/switch 1 (2 pts) (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::uv::_napi_uv_close (cognitive 17) ext/napi/uv.rs:284— deno_napi::uv::_napi_uv_close has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (16 pts), match/switch 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_napi::uv::uv_ref (cognitive 16) ext/napi/uv.rs:1085— deno_napi::uv::uv_ref has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (15 pts), match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_napi::uv::uv_unref) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_napi::uv::uv_unref (cognitive 16) ext/napi/uv.rs:1128— deno_napi::uv::uv_unref has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (15 pts), match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_napi::uv::uv_ref) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Duplicated block (10 lines × 3) ext/crypto/subtle_crypto.rs:818— ext/crypto/subtle_crypto.rs:818-827 | ext/crypto/subtle_generate_key.rs:817-826 | ext/crypto/subtle_import_key.rs:143-152 — before extracting anything, compare `ext/crypto/subtle_crypto.rs` and `ext/crypto/subtle_generate_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 38 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 3) ext/crypto/subtle_decrypt.rs:298— ext/crypto/subtle_decrypt.rs:298-307 | ext/crypto/subtle_encrypt.rs:354-363 | ext/crypto/subtle_sign.rs:378-387 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 3) ext/crypto/subtle_derive_bits.rs:671— ext/crypto/subtle_derive_bits.rs:671-680 | ext/crypto/subtle_sign.rs:576-585 | ext/crypto/subtle_verify.rs:386-395 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_sign.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 46 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 3) ext/node/ops/wasi.rs:870— ext/node/ops/wasi.rs:870-879 | ext/node/ops/wasi.rs:893-902 | ext/node/ops/wasi.rs:2166-2175 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10 lines × 3) ext/node_crypto/lib.rs:1211— ext/node_crypto/lib.rs:1211-1220 | ext/node_crypto/lib.rs:1224-1233 | ext/node_crypto/lib.rs:1249-1258 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10 lines × 3) ext/node_sqlite/sql_tag_store.rs:372— ext/node_sqlite/sql_tag_store.rs:372-381 | ext/node_sqlite/sql_tag_store.rs:393-402 | ext/node_sqlite/sql_tag_store.rs:452-461 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10 lines × 3) ext/telemetry/lib.rs:3102— ext/telemetry/lib.rs:3102-3111 | ext/telemetry/lib.rs:3141-3150 | ext/telemetry/lib.rs:3186-3195 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10 lines × 3) libs/core/uv_compat.rs:1220— libs/core/uv_compat.rs:1220-1229 | libs/core/uv_compat.rs:1278-1287 | libs/core/uv_compat.rs:1336-1345 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10 lines × 3) ext/crypto/ed25519.rs:76— ext/crypto/ed25519.rs:76-85 | ext/crypto/x25519.rs:74-83 | ext/crypto/x448.rs:81-90 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from all 3 call sites, so a change lands once.
Duplicated block (10 lines × 3) runtime/worker.rs:746— runtime/worker.rs:746-755 | runtime/worker.rs:766-776 | runtime/worker.rs:778-789 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) ext/crypto/subtle_import_key.rs:748— ext/crypto/subtle_import_key.rs:748-752 | ext/crypto/subtle_import_key.rs:874-878 | ext/crypto/subtle_import_key.rs:986-990 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) ext/http/http_next.rs:1025— ext/http/http_next.rs:1025-1029 | ext/http/http_next.rs:1085-1089 | ext/http/http_next.rs:1111-1115 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) ext/node/ops/zlib/mod.rs:306— ext/node/ops/zlib/mod.rs:306-311 | ext/node/ops/zlib/mod.rs:968-972 | ext/node/ops/zlib/mod.rs:1056-1060 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) ext/web/geometry.rs:345— ext/web/geometry.rs:345-349 | ext/web/geometry.rs:359-363 | ext/web/geometry.rs:399-403 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) libs/core/uv_compat/stream.rs:501— libs/core/uv_compat/stream.rs:501-505 | libs/core/uv_compat/stream.rs:606-610 | libs/core/uv_compat/stream.rs:704-708 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) libs/core/uv_compat/tty.rs:1771— libs/core/uv_compat/tty.rs:1771-1775 | libs/core/uv_compat/tty.rs:2000-2004 | libs/core/uv_compat/tty.rs:2067-2071 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) libs/eszip/v2.rs:97— libs/eszip/v2.rs:97-101 | libs/eszip/v2.rs:122-126 | libs/eszip/v2.rs:153-157 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 3) cli/lib/standalone/binary.rs:403— cli/lib/standalone/binary.rs:403-407 | cli/rt/binary.rs:1264-1268 | libs/eszip/v2.rs:1887-1891 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (5 lines × 3) ext/node/ops/tls_wrap.rs:2940— ext/node/ops/tls_wrap.rs:2940-2945 | ext/node/ops/tty_wrap.rs:186-190 | ext/node/ops/tty_wrap.rs:191-195 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (5 lines × 3) ext/crypto/subtle_import_key.rs:1528— ext/crypto/subtle_import_key.rs:1528-1532 | ext/crypto/subtle_import_key.rs:1576-1580 | ext/crypto/subtle_import_key.rs:1624-1628 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Repeated repair: ext/net/ops.rs ext/net/ops.rs:1335— ext/net/ops.rs changed 5 times in last 90 days and 5 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 13 (its worst body is deno_net::ops::format_rdata at line 1335), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(net): check permissions for multicast membership (#36529)”; “fix(ext/node): improve node:dns error codes and lookupService/setLocalAddress compat (#36552)”; “fix(ext/net): skip unsupported DNS records in ANY queries (#36650)”; “fix(net): handle malformed DNS record text (#36374)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/net/ops.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: tests/unit/fetch_test.ts tests/unit/fetch_test.ts:1692— tests/unit/fetch_test.ts changed 5 times in last 90 days and 5 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 6 (its worst body is fetchHeaderValueShouldNotPanic at line 1692), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(ext/fetch): raise default HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE to 256KB (#36558)”; “fix(ext/fetch): only retry transport errors on pooled connections (#36415)”; “fix(ext/fetch): enforce permissions for proxy transports (#36217)”; “fix(ext/tls): avoid panic for mismatched client certificate and key (#36457)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- tests/unit/fetch_test.ts`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: ext/napi/lib.rs ext/napi/lib.rs:916— ext/napi/lib.rs changed 5 times in last 90 days and 4 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 14 (its worst body is deno_napi::op_napi_open at line 916), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(ext/napi): surface OS error and path on addon load failure (#36630)”; “fix(ext/napi): run JS-calling finalizers safely, NULL string result, and Float16Array (#36572)”; “fix(ext/napi): don't invoke napi_wrap finalizer twice at teardown (#36556)”; “fix(ext/napi): track pending finalizers by identity (#36551)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/napi/lib.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: tests/unit_node/http_test.ts tests/unit_node/http_test.ts:3437— tests/unit_node/http_test.ts changed 4 times in last 90 days and 4 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 5 (its worst body is (anonymous) at line 3437), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(node): align IncomingMessage header map prototypes (#36438)”; “fix(ext/node): build the proxied request target with the URL parser (#36557)”; “fix(node): validate raw outgoing HTTP headers (#36471)”; “fix(ext/node): fix perf_hooks detail.req.url proxied path duplication (#36407)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- tests/unit_node/http_test.ts`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: runtime/ops/desktop.rs runtime/ops/desktop.rs:42— runtime/ops/desktop.rs changed 5 times in last 90 days and 3 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 10 (its worst body is DesktopValue::to_v8 at line 42), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(desktop): transport binding args and results as DesktopValue so Uint8Array survives (#36573)”; “fix(desktop): keep the macOS bundle signature valid unless an update is applied (#36574)”; “fix(desktop): never block the JS thread on the error-report dialog (#36575)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- runtime/ops/desktop.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: ext/node/lib.rs ext/node/lib.rs:140— ext/node/lib.rs changed 3 times in last 90 days and 3 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 4 (its worst body is deno_node::op_node_load_env_file at line 140), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(ext/node): don't panic on prime sizes below 2 bits (#36400)”; “fix(ext/node): improve node:dns error codes and lookupService/setLocalAddress compat (#36552)”; “fix(os): serialize process environment updates (#36074)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- ext/node/lib.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: cli/registry.rs cli/registry.rs:227— cli/registry.rs changed 3 times in last 90 days and 3 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 7 (its worst body is deno::registry::parse_package_name at line 227), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(publish): authenticate the package existence check so private packages work (#36656)”; “fix(publish): reject invalid JSR package names (#36474)”; “fix(cli): escape control characters in external metadata (#36198)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- cli/registry.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: tests/unit_node/crypto/crypto_key_test.ts tests/unit_node/crypto/crypto_key_test.ts:873— tests/unit_node/crypto/crypto_key_test.ts changed 3 times in last 90 days and 3 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 3 (its worst body is (anonymous) at line 873), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(node_crypto): apply RFC 7748 scalar decoding for X448 (#36466)”; “fix(node/crypto): preserve binary key export passphrases (#36443)”; “fix(ext/node): use signatureAlgorithm digest for X509 ECDSA verify (#36326)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- tests/unit_node/crypto/crypto_key_test.ts`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Repeated repair: cli/tools/bundle/mod.rs cli/tools/bundle/mod.rs:1584— cli/tools/bundle/mod.rs changed 3 times in last 90 days and 3 of those changes were fix/bug commits, so repair is the majority of this file's churn. Its max cyclomatic complexity is 13 (its worst body is DenoPluginHandler::on_resolve at line 1584), UNDER the 15 threshold, so this is deliberately not filed as a churn × complexity hotspot — the difficulty here is in the behaviour the file has to get right, not in its control flow, and refactoring it for complexity would be the wrong move. The repairs counted were: “fix(bundle): isolate esbuild downloads from workspace registries (#36467)”; “fix(bundle): respect runtime file permissions (#36107)”; “fix(cjs): use loader sources for recursive analysis (#36111)”. Each one is a case this code did not handle. Before the next change lands here, check that every one of them is pinned by a test that fails without its fix; where the same area keeps coming back, the durable fix is usually at the interface that keeps being misused rather than at the line that was last corrected. Counted over 2026-07-27..2026-10-25, the 90 days ending at the analysed commit. Reproduce with `git log --since='2026-07-27 12:06:20 +00:00' --until='2026-10-25 12:06:20 +00:00' --full-history --no-merges -- cli/tools/bundle/mod.rs`: merges are excluded because a merge re-states changes already counted at their own commits, and history is NOT path-simplified because a change that reached the file through a merged branch is still a change to it. That command counts raw commits and can read HIGHER than this row, which counts a cherry-picked re-land, and a revert together with the commit it undoes, once each — a difference of several commits on a file whose history was re-landed or reverted inside the window.
Duplicated block (18 lines × 2) cli/lsp/language_server.rs:2467— cli/lsp/language_server.rs:2467-2484 | cli/lsp/language_server.rs:2536-2553 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18 lines × 2) ext/crypto/decrypt.rs:327— ext/crypto/decrypt.rs:327-344 | ext/crypto/encrypt.rs:206-223 — before extracting anything, compare `ext/crypto/decrypt.rs` and `ext/crypto/encrypt.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 53 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (18 lines × 2) ext/crypto/subtle_decrypt.rs:376— ext/crypto/subtle_decrypt.rs:376-393 | ext/crypto/subtle_encrypt.rs:432-449 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (18 lines × 2) ext/crypto/subtle_decrypt.rs:402— ext/crypto/subtle_decrypt.rs:402-419 | ext/crypto/subtle_encrypt.rs:458-475 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (18 lines × 2) ext/crypto/subtle_export_key.rs:763— ext/crypto/subtle_export_key.rs:763-780 | ext/crypto/subtle_export_key.rs:843-860 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18 lines × 2) ext/crypto/subtle_import_key.rs:861— ext/crypto/subtle_import_key.rs:861-878 | ext/crypto/subtle_import_key.rs:973-990 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18 lines × 2) ext/node/ops/pipe_wrap.rs:210— ext/node/ops/pipe_wrap.rs:210-227 | ext/node/ops/tcp_wrap.rs:217-234 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (18 lines × 2) ext/web/console/mod.rs:1532— ext/web/console/mod.rs:1532-1549 | ext/web/console/mod.rs:1675-1692 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18 lines × 2) libs/ops/op2/dispatch_slow.rs:985— libs/ops/op2/dispatch_slow.rs:985-1002 | libs/ops/op2/dispatch_slow.rs:1018-1035 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 3) cli/lsp/ts_server.rs:719— cli/lsp/ts_server.rs:719-730 | cli/lsp/ts_server.rs:810-821 | cli/lsp/ts_server.rs:938-949 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12 lines × 3) cli/rt/hmr.rs:227— cli/rt/hmr.rs:227-238 | cli/tools/repl/session.rs:249-260 | cli/tools/run/hmr.rs:119-130 — before extracting anything, compare `cli/rt/hmr.rs` and `cli/tools/run/hmr.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 62 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 3) cli/tools/pm/list.rs:316— cli/tools/pm/list.rs:316-327 | cli/tools/pm/mod.rs:1266-1277 | cli/tools/pm/outdated/mod.rs:275-286 — before extracting anything, compare `cli/tools/pm/list.rs` and `cli/tools/pm/outdated/mod.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 33 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 3) ext/crypto/subtle_export_key.rs:763— ext/crypto/subtle_export_key.rs:763-774 | ext/crypto/subtle_export_key.rs:843-854 | ext/crypto/subtle_export_key.rs:917-928 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12 lines × 3) ext/webgpu/compute_pass.rs:233— ext/webgpu/compute_pass.rs:233-244 | ext/webgpu/render_bundle.rs:229-240 | ext/webgpu/render_pass.rs:306-317 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_bundle.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 63 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 3) ext/webgpu/webidl.rs:45— ext/webgpu/webidl.rs:45-56 | ext/webgpu/webidl.rs:155-166 | ext/webgpu/webidl.rs:250-261 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12 lines × 3) libs/ops/conversion/from_v8/struct.rs:202— libs/ops/conversion/from_v8/struct.rs:202-213 | libs/ops/conversion/to_v8/struct.rs:193-204 | libs/ops/webidl/dictionary.rs:226-237 — `libs/ops/conversion/from_v8/struct.rs` and `libs/ops/conversion/to_v8/struct.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 5 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
Duplicated block (12 lines × 3) ext/crypto/subtle_import_key.rs:470— ext/crypto/subtle_import_key.rs:470-481 | ext/crypto/subtle_import_key.rs:1208-1219 | ext/crypto/subtle_import_key.rs:1880-1891 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12 lines × 3) cli/lsp/language_server.rs:3278— cli/lsp/language_server.rs:3278-3289 | cli/lsp/language_server.rs:3667-3678 | cli/lsp/language_server.rs:4630-4641 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
deno_cli_parser::parse::parse_args (cyclomatic 50) libs/cli_parser/src/parse.rs:112— deno_cli_parser::parse::parse_args has cyclomatic complexity 50 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_cli_parser::convert::validate_permission_args (cyclomatic 29) libs/cli_parser/src/convert.rs:1197— deno_cli_parser::convert::validate_permission_args has cyclomatic complexity 29 (threshold 15). Of this number, 26 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_cli_parser::convert::convert (cyclomatic 56) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_cli_parser::convert::permission_args_parse (cyclomatic 26) libs/cli_parser/src/convert.rs:537— deno_cli_parser::convert::permission_args_parse has cyclomatic complexity 26 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This is NOT this file's highest cyclomatic complexity: deno_cli_parser::convert::convert (cyclomatic 56) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_cli_parser::convert::apply_node_options (cyclomatic 26) libs/cli_parser/src/convert.rs:3041— deno_cli_parser::convert::apply_node_options has cyclomatic complexity 26 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions. This is NOT this file's highest cyclomatic complexity: deno_cli_parser::convert::convert (cyclomatic 56) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_cli_parser::help::render_help (cyclomatic 26) libs/cli_parser/src/help.rs:9— deno_cli_parser::help::render_help has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_cli_parser::parse::parse_long_flag (cyclomatic 22) libs/cli_parser/src/parse.rs:427— deno_cli_parser::parse::parse_long_flag has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_cli_parser::completions::get_candidates (cyclomatic 20) libs/cli_parser/src/completions.rs:604— deno_cli_parser::completions::get_candidates has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_cli_parser::convert::test_parse (cyclomatic 17) libs/cli_parser/src/convert.rs:1621— deno_cli_parser::convert::test_parse has cyclomatic complexity 17 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This is NOT this file's highest cyclomatic complexity: deno_cli_parser::convert::convert (cyclomatic 56) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_resolver::npm_lockfile_import::package_lock_to_deno_lock_v5 (cyclomatic 34) libs/resolver/npm_lockfile_import.rs:62— deno_resolver::npm_lockfile_import::package_lock_to_deno_lock_v5 has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::pnpm_lockfile_import::pnpm_lock_to_deno_lock_v5 (cyclomatic 29) libs/resolver/pnpm_lockfile_import.rs:41— deno_resolver::pnpm_lockfile_import::pnpm_lock_to_deno_lock_v5 has cyclomatic complexity 29 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::patch_react_cves (cyclomatic 22) libs/resolver/lib.rs:715— deno_resolver::patch_react_cves has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::bun_lockfile_import::bun_lock_to_deno_lock_v5 (cyclomatic 22) libs/resolver/bun_lockfile_import.rs:38— deno_resolver::bun_lockfile_import::bun_lock_to_deno_lock_v5 has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::yarn_lockfile_import::yarn_lock_to_deno_lock_v5 (cyclomatic 19) libs/resolver/yarn_lockfile_import.rs:28— deno_resolver::yarn_lockfile_import::yarn_lock_to_deno_lock_v5 has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::npmrc::discover_npmrc (cyclomatic 18) libs/resolver/npmrc.rs:94— deno_resolver::npmrc::discover_npmrc has cyclomatic complexity 18 (threshold 15). Of this number, 12 points are the body's own statements and 6 belong to 3 function items inside it that branch. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_resolver::yarn_lockfile_import::parse_yarn_v1 (cyclomatic 17) libs/resolver/yarn_lockfile_import.rs:208— deno_resolver::yarn_lockfile_import::parse_yarn_v1 has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_resolver::graph::get_import_prefix_missing_error (cyclomatic 16) libs/resolver/graph.rs:1005— deno_resolver::graph::get_import_prefix_missing_error has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDependencyResolver::resolve_peers_of_node (cognitive 129) libs/npm/resolution/graph.rs:1864— GraphDependencyResolver::resolve_peers_of_node has cognitive complexity 129 (threshold 15). Drivers by points: if/else 33 (78 pts), loops 17 (38 pts), boolean chains 7, match/switch 2 (6 pts) (nesting depth added 70). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
GraphDependencyResolver::run_dedup_pass (cognitive 105) libs/npm/resolution/graph.rs:3047— GraphDependencyResolver::run_dedup_pass has cognitive complexity 105 (threshold 15). Drivers by points: if/else 28 (71 pts), loops 18 (30 pts), boolean chains 4 (nesting depth added 55). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::drain_pending_parallel (cognitive 46) libs/npm/resolution/graph.rs:2469— GraphDependencyResolver::drain_pending_parallel has cognitive complexity 46 (threshold 15). Drivers by points: if/else 12 (34 pts), loops 5 (9 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 27). Of this number, 36 points are the body's own statements and 10 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::find_peers_cache_hit_inner (cognitive 44) libs/npm/resolution/graph.rs:2350— GraphDependencyResolver::find_peers_cache_hit_inner has cognitive complexity 44 (threshold 15). Drivers by points: if/else 11 (32 pts), loops 4 (7 pts), match/switch 1 (3 pts), boolean chains 2 (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::apply_dedup_mappings (cognitive 26) libs/npm/resolution/graph.rs:1794— GraphDependencyResolver::apply_dedup_mappings has cognitive complexity 26 (threshold 15). Drivers by points: if/else 6 (16 pts), loops 6 (10 pts) (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::auto_install_missing_peers (cognitive 25) libs/npm/resolution/graph.rs:1497— GraphDependencyResolver::auto_install_missing_peers has cognitive complexity 25 (threshold 15). Drivers by points: if/else 4 (13 pts), loops 3 (5 pts), match/switch 2 (4 pts), boolean chains 3 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::add_peer_deps_to_path (cognitive 23) libs/npm/resolution/graph.rs:2839— GraphDependencyResolver::add_peer_deps_to_path has cognitive complexity 23 (threshold 15). Drivers by points: if/else 5 (11 pts), loops 3 (6 pts), match/switch 2 (6 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDependencyResolver::dedup_dep_paths (cognitive 17) libs/npm/resolution/graph.rs:1670— GraphDependencyResolver::dedup_dep_paths has cognitive complexity 17 (threshold 15). Drivers by points: if/else 4 (10 pts), loops 3 (6 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Duplicated block (7 lines × 3) ext/crypto/subtle_wrap_key.rs:387— ext/crypto/subtle_wrap_key.rs:387-393 | libs/cli_parser/src/convert.rs:3428-3434 | libs/core/modules/import_graph.rs:186-192 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere all 3 call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made 3 times.
Duplicated block (7 lines × 3) ext/fs/ops.rs:1510— ext/fs/ops.rs:1510-1517 | ext/fs/ops.rs:1588-1594 | ext/fs/ops.rs:1654-1660 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 3) ext/node/ops/http2/session.rs:880— ext/node/ops/http2/session.rs:880-886 | ext/node/ops/http2/session.rs:993-999 | ext/node/ops/http2/session.rs:1373-1379 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 3) ext/node_crypto/x509.rs:296— ext/node_crypto/x509.rs:296-302 | ext/node_crypto/x509.rs:333-339 | ext/node_crypto/x509.rs:683-689 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 3) ext/node_sqlite/database.rs:3054— ext/node_sqlite/database.rs:3054-3060 | ext/node_sqlite/database.rs:3073-3079 | ext/node_sqlite/database.rs:3094-3100 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 3) libs/dcore/src/inspector_server.rs:217— libs/dcore/src/inspector_server.rs:217-223 | libs/inspector_server/lib.rs:446-452 | libs/inspector_server/lib.rs:557-563 — before extracting anything, compare `libs/dcore/src/inspector_server.rs` and `libs/inspector_server/lib.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 128 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 3) libs/config/workspace/mod.rs:679— libs/config/workspace/mod.rs:679-685 | libs/config/workspace/mod.rs:688-694 | libs/config/workspace/mod.rs:696-703 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 3) ext/node_crypto/lib.rs:1284— ext/node_crypto/lib.rs:1284-1290 | ext/node_crypto/lib.rs:1292-1298 | ext/node_crypto/lib.rs:1300-1306 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
deno_ops::op2::signature::parse_type (cyclomatic 52) libs/ops/op2/signature.rs:1699— deno_ops::op2::signature::parse_type has cyclomatic complexity 52 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_ops::op2::dispatch_slow::from_arg (cyclomatic 44) libs/ops/op2/dispatch_slow.rs:425— deno_ops::op2::dispatch_slow::from_arg has cyclomatic complexity 44 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_ops::op2::signature::parse_attribute (cyclomatic 29) libs/ops/op2/signature.rs:1337— deno_ops::op2::signature::parse_attribute has cyclomatic complexity 29 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_ops::op2::generate_op2 (cyclomatic 23) libs/ops/op2/mod.rs:203— deno_ops::op2::generate_op2 has cyclomatic complexity 23 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_ops::op2::dispatch_fast::generate_dispatch_fast (cyclomatic 20) libs/ops/op2/dispatch_fast.rs:415— deno_ops::op2::dispatch_fast::generate_dispatch_fast has cyclomatic complexity 20 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This is NOT this file's highest cyclomatic complexity: deno_ops::op2::dispatch_fast::map_arg_to_v8_fastcall_type (cyclomatic 28) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_ops::op2::dispatch_async::generate_dispatch_async (cyclomatic 16) libs/ops/op2/dispatch_async.rs:59— deno_ops::op2::dispatch_async::generate_dispatch_async has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_ops::op2::dispatch_slow::generate_dispatch_slow (cyclomatic 16) libs/ops/op2/dispatch_slow.rs:76— deno_ops::op2::dispatch_slow::generate_dispatch_slow has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_node_crypto::keys::op_node_get_asymmetric_key_details (cyclomatic 29) ext/node_crypto/keys.rs:2756— deno_node_crypto::keys::op_node_get_asymmetric_key_details has cyclomatic complexity 29 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_node_crypto::x509::op_node_x509_verify (cyclomatic 22) ext/node_crypto/x509.rs:1072— deno_node_crypto::x509::op_node_x509_verify has cyclomatic complexity 22 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_node_crypto::cipher::aes_unwrap_key (cyclomatic 20) ext/node_crypto/cipher.rs:198— deno_node_crypto::cipher::aes_unwrap_key has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node_crypto::keys::parse_rsa_pss_params (cyclomatic 20) ext/node_crypto/keys.rs:1899— deno_node_crypto::keys::parse_rsa_pss_params has cyclomatic complexity 20 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_node_crypto::op_node_ecdh_compute_secret (cyclomatic 16) ext/node_crypto/lib.rs:1338— deno_node_crypto::op_node_ecdh_compute_secret has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_node_crypto::cipher::aes_wrap_key (cyclomatic 16) ext/node_crypto/cipher.rs:52— deno_node_crypto::cipher::aes_wrap_key has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: Cipher::r#final (cyclomatic 18) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_node_crypto::keys::parse_legacy_encrypted_pem (cyclomatic 16) ext/node_crypto/keys.rs:3680— deno_node_crypto::keys::parse_legacy_encrypted_pem has cyclomatic complexity 16 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_config::workspace::discovery::discover_workspace_config_files_for_single_dir (cognitive 56) libs/config/workspace/discovery.rs:235— deno_config::workspace::discovery::discover_workspace_config_files_for_single_dir has cognitive complexity 56 (threshold 15). Drivers by points: if/else 21 (44 pts), match/switch 5 (8 pts), boolean chains 3, loops 1 (nesting depth added 26). Of this number, 55 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::workspace::discovery::resolve_workspace_for_config_folder (cognitive 51) libs/config/workspace/discovery.rs:682— deno_config::workspace::discovery::resolve_workspace_for_config_folder has cognitive complexity 51 (threshold 15). Drivers by points: if/else 12 (20 pts), match/switch 4 (14 pts), loops 6 (12 pts), boolean chains 5 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::util::parse_iso8601_duration (cognitive 44) libs/config/util.rs:168— deno_config::util::parse_iso8601_duration has cognitive complexity 44 (threshold 15). Drivers by points: if/else 18 (30 pts), loops 3 (6 pts), boolean chains 5, match/switch 2 (3 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::workspace::discovery::resolve_auto_link_config_folders (cognitive 24) libs/config/workspace/discovery.rs:1303— deno_config::workspace::discovery::resolve_auto_link_config_folders has cognitive complexity 24 (threshold 15). Drivers by points: if/else 4 (13 pts), loops 5 (8 pts), match/switch 1 (3 pts) (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::workspace::discovery::handle_workspace_with_members (cognitive 19) libs/config/workspace/discovery.rs:580— deno_config::workspace::discovery::handle_workspace_with_members has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (15 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::workspace::discovery::resolve_link_member_config_folders (cognitive 19) libs/config/workspace/discovery.rs:1204— deno_config::workspace::discovery::resolve_link_member_config_folders has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (17 pts), loops 1 (2 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_config::import_map::rewrite_jsr_imports_to_npm (cognitive 17) libs/config/import_map.rs:133— deno_config::import_map::rewrite_jsr_imports_to_npm has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (11 pts), loops 3 (4 pts), boolean chains 2 (nesting depth added 6). Most of this is not in the body itself: 8 of the 17 points are its own statements and the rest belongs to one function item inside it that branches (rewrite_map). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
WasiContext::fd_read (cognitive 51) ext/node/ops/wasi.rs:829— WasiContext::fd_read has cognitive complexity 51 (threshold 15). Drivers by points: if/else 12 (35 pts), match/switch 4 (10 pts), loops 3 (6 pts) (nesting depth added 32). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WasiContext::poll_oneoff (cognitive 38) ext/node/ops/wasi.rs:1919— WasiContext::poll_oneoff has cognitive complexity 38 (threshold 15). Drivers by points: if/else 10 (17 pts), match/switch 6 (16 pts), boolean chains 3, loops 2 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WasiContext::fd_write (cognitive 29) ext/node/ops/wasi.rs:762— WasiContext::fd_write has cognitive complexity 29 (threshold 15). Drivers by points: if/else 7 (15 pts), loops 4 (8 pts), match/switch 3 (6 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WasiContext::path_open (cognitive 26) ext/node/ops/wasi.rs:1378— WasiContext::path_open has cognitive complexity 26 (threshold 15). Drivers by points: if/else 12 (15 pts), match/switch 4 (7 pts), boolean chains 4 (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
WasiContext::fd_pread (cognitive 24) ext/node/ops/wasi.rs:2138— WasiContext::fd_pread has cognitive complexity 24 (threshold 15). Drivers by points: if/else 7 (16 pts), match/switch 3 (6 pts), loops 1 (2 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WasiContext::fd_pwrite (cognitive 17) ext/node/ops/wasi.rs:2203— WasiContext::fd_pwrite has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (8 pts), match/switch 3 (7 pts), loops 1 (2 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WasiContext::fd_readdir (cognitive 16) ext/node/ops/wasi.rs:1291— WasiContext::fd_readdir has cognitive complexity 16 (threshold 15). Drivers by points: if/else 5 (8 pts), match/switch 4 (6 pts), boolean chains 1, loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::hoisted::compute_hoisted_layout (cognitive 40) libs/npm_installer/hoisted.rs:98— deno_npm_installer::hoisted::compute_hoisted_layout has cognitive complexity 40 (threshold 15). Drivers by points: if/else 10 (25 pts), loops 7 (9 pts), boolean chains 4, match/switch 1 (2 pts) (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::local::remove_stale_member_symlinks (cognitive 31) libs/npm_installer/local.rs:1810— deno_npm_installer::local::remove_stale_member_symlinks has cognitive complexity 31 (threshold 15). Drivers by points: if/else 8 (23 pts), loops 2 (5 pts), boolean chains 2, match/switch 1 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::local::cleanup_unused_packages (cognitive 25) libs/npm_installer/local.rs:2133— deno_npm_installer::local::cleanup_unused_packages has cognitive complexity 25 (threshold 15). Drivers by points: if/else 8 (20 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::hoisted::cleanup_hoisted_packages (cognitive 23) libs/npm_installer/hoisted.rs:1037— deno_npm_installer::hoisted::cleanup_hoisted_packages has cognitive complexity 23 (threshold 15). Drivers by points: if/else 6 (16 pts), loops 2 (6 pts), boolean chains 1 (nesting depth added 14). Of this number, 22 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::bin_entries::sort_by_depth (cognitive 20) libs/npm_installer/bin_entries.rs:339— deno_npm_installer::bin_entries::sort_by_depth has cognitive complexity 20 (threshold 15). Drivers by points: if/else 5 (14 pts), loops 2 (4 pts), match/switch 1 (2 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::lifecycle_scripts::compute_lifecycle_script_layers (cognitive 20) libs/npm_installer/lifecycle_scripts.rs:338— deno_npm_installer::lifecycle_scripts::compute_lifecycle_script_layers has cognitive complexity 20 (threshold 15). Drivers by points: if/else 4 (10 pts), loops 5 (10 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_installer::resolution::peer_dep_diagnostics_to_display_tree (cognitive 16) libs/npm_installer/resolution.rs:435— deno_npm_installer::resolution::peer_dep_diagnostics_to_display_tree has cognitive complexity 16 (threshold 15). Drivers by points: if/else 5 (12 pts), loops 3 (4 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Duplicated block (25 lines × 2) cli/lsp/testing/collectors.rs:269— cli/lsp/testing/collectors.rs:269-293 | cli/lsp/testing/collectors.rs:297-321 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (25 lines × 2) cli/tsc/diagnostics.rs:22— cli/tsc/diagnostics.rs:22-46 | runtime/fmt_errors.rs:129-153 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (25 lines × 2) ext/crypto/subtle_export_key.rs:723— ext/crypto/subtle_export_key.rs:723-747 | ext/crypto/subtle_export_key.rs:803-827 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (25 lines × 2) ext/net/ops.rs:649— ext/net/ops.rs:649-673 | ext/net/ops_tls.rs:481-505 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (25 lines × 2) libs/node_resolver/resolution.rs:514— libs/node_resolver/resolution.rs:514-538 | libs/node_resolver/resolution.rs:559-583 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (25 lines × 2) libs/resolver/loader/module_loader.rs:425— libs/resolver/loader/module_loader.rs:425-449 | libs/resolver/loader/module_loader.rs:466-490 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (25 lines × 2) ext/crypto/decrypt.rs:211— ext/crypto/decrypt.rs:211-235 | ext/crypto/encrypt.rs:366-390 — before extracting anything, compare `ext/crypto/decrypt.rs` and `ext/crypto/encrypt.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 53 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (20 lines × 2) ext/canvas/bitmaprenderer.rs:199— ext/canvas/bitmaprenderer.rs:199-218 | ext/canvas/bitmaprenderer.rs:315-334 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20 lines × 2) ext/canvas/bitmaprenderer.rs:273— ext/canvas/bitmaprenderer.rs:273-292 | ext/canvas/bitmaprenderer.rs:361-380 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20 lines × 2) ext/node/ops/tls_wrap.rs:1757— ext/node/ops/tls_wrap.rs:1757-1776 | ext/node/ops/tls_wrap.rs:1978-1997 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20 lines × 2) ext/node_crypto/keys.rs:1286— ext/node_crypto/keys.rs:1286-1305 | ext/node_crypto/keys.rs:1679-1698 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20 lines × 2) ext/webgpu/compute_pass.rs:228— ext/webgpu/compute_pass.rs:228-247 | ext/webgpu/render_pass.rs:301-320 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_pass.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 146 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (20 lines × 2) libs/npm_installer/package_json.rs:290— libs/npm_installer/package_json.rs:290-309 | libs/npm_installer/package_json.rs:380-399 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20 lines × 2) libs/resolver/loader/module_loader.rs:534— libs/resolver/loader/module_loader.rs:534-553 | libs/resolver/loader/module_loader.rs:562-581 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–10 lines × 2) cli/standalone/binary.rs:1739— cli/standalone/binary.rs:1739-1747 | libs/eszip/v2.rs:1213-1222 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (9–10 lines × 2) cli/tools/bundle/esbuild.rs:71— cli/tools/bundle/esbuild.rs:71-79 | cli/tsc/native.rs:118-127 — before extracting anything, compare `cli/tools/bundle/esbuild.rs` and `cli/tsc/native.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 42 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (9–10 lines × 2) libs/config/workspace/discovery.rs:827— libs/config/workspace/discovery.rs:827-836 | libs/config/workspace/discovery.rs:903-911 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–10 lines × 2) libs/core/runtime/bindings.rs:436— libs/core/runtime/bindings.rs:436-445 | libs/core/runtime/bindings.rs:735-743 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–10 lines × 2) libs/core/uv_compat/stream.rs:497— libs/core/uv_compat/stream.rs:497-505 | libs/core/uv_compat/stream.rs:601-610 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–10 lines × 2) libs/core_testing/checkin/runner/ops_worker.rs:165— libs/core_testing/checkin/runner/ops_worker.rs:165-174 | libs/core_testing/checkin/runner/ops_worker.rs:176-184 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–10 lines × 2) libs/npm_cache/fs_util.rs:32— libs/npm_cache/fs_util.rs:32-41 | libs/npm_installer/fs.rs:86-94 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
deno_subprocess_windows::process::search_path (cognitive 60) runtime/subprocess_windows/src/process.rs:975— deno_subprocess_windows::process::search_path has cognitive complexity 60 (threshold 15). Drivers by points: if/else 16 (40 pts), boolean chains 10, loops 4 (10 pts) (nesting depth added 30). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::uv__kill (cognitive 56) runtime/subprocess_windows/src/process.rs:1115— deno_subprocess_windows::process::uv__kill has cognitive complexity 56 (threshold 15). Drivers by points: if/else 15 (35 pts), loops 4 (14 pts), boolean chains 4, match/switch 2 (3 pts) (nesting depth added 31). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::spawn (cognitive 40) runtime/subprocess_windows/src/process.rs:525— deno_subprocess_windows::process::spawn has cognitive complexity 40 (threshold 15). Drivers by points: if/else 26 (35 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 10). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::search_path_join_test (cognitive 34) runtime/subprocess_windows/src/process.rs:841— deno_subprocess_windows::process::search_path_join_test has cognitive complexity 34 (threshold 15). Drivers by points: if/else 14 (18 pts), boolean chains 16 (nesting depth added 4). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::append_bat_arg (cognitive 22) runtime/subprocess_windows/src/process.rs:1520— deno_subprocess_windows::process::append_bat_arg has cognitive complexity 22 (threshold 15). Drivers by points: if/else 9 (15 pts), boolean chains 5, loops 2 (nesting depth added 6). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process_stdio::uv_stdio_create (cognitive 19) runtime/subprocess_windows/src/process_stdio.rs:248— deno_subprocess_windows::process_stdio::uv_stdio_create has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (13 pts), match/switch 2 (5 pts), loops 1 (nesting depth added 9). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
NodeResolver::resolve_package_target_string (cognitive 47) libs/node_resolver/resolution.rs:1399— NodeResolver::resolve_package_target_string has cognitive complexity 47 (threshold 15). Drivers by points: if/else 17 (29 pts), match/switch 4 (16 pts), boolean chains 2 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeResolver::finalize_resolution (cognitive 32) libs/node_resolver/resolution.rs:802— NodeResolver::finalize_resolution has cognitive complexity 32 (threshold 15). Drivers by points: if/else 11 (20 pts), match/switch 5 (6 pts), boolean chains 3, loops 1 (3 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeResolver::resolve_package_target_inner (cognitive 28) libs/node_resolver/resolution.rs:1642— NodeResolver::resolve_package_target_inner has cognitive complexity 28 (threshold 15). Drivers by points: if/else 8 (15 pts), match/switch 2 (7 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeResolver::legacy_main_resolve (cognitive 28) libs/node_resolver/resolution.rs:2239— NodeResolver::legacy_main_resolve has cognitive complexity 28 (threshold 15). Drivers by points: if/else 10 (20 pts), match/switch 2 (5 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeResolver::path_to_declaration_path (cognitive 20) libs/node_resolver/resolution.rs:1223— NodeResolver::path_to_declaration_path has cognitive complexity 20 (threshold 15). Drivers by points: if/else 13 (17 pts), boolean chains 2, match/switch 1 (nesting depth added 4). Most of this is not in the body itself: 9 of the 20 points are its own statements and the rest belongs to one function item inside it that branches (probe_extensions). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
NodeResolver::package_exports_resolve_internal (cognitive 18) libs/node_resolver/resolution.rs:1788— NodeResolver::package_exports_resolve_internal has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 2, match/switch 1 (2 pts), loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::drain_dyn_imports (cognitive 35) libs/core/modules/map/dynamic.rs:511— ModuleMap::drain_dyn_imports has cognitive complexity 35 (threshold 15). Drivers by points: if/else 5 (18 pts), match/switch 5 (16 pts), loops 1 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::new_module_from_js_source_with_pending (cognitive 35) libs/core/modules/map.rs:819— ModuleMap::new_module_from_js_source_with_pending has cognitive complexity 35 (threshold 15). Drivers by points: if/else 17 (26 pts), match/switch 3 (5 pts), boolean chains 3, loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::resolve_callback (cognitive 23) libs/core/modules/map.rs:1559— ModuleMap::resolve_callback has cognitive complexity 23 (threshold 15). Drivers by points: if/else 9 (15 pts), match/switch 3 (5 pts), boolean chains 3 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::mod_evaluate (cognitive 22) libs/core/modules/map/evaluation.rs:47— ModuleMap::mod_evaluate has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11 (17 pts), match/switch 1 (3 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::drop_instantiated_requests (cognitive 18) libs/core/modules/map.rs:1250— ModuleMap::drop_instantiated_requests has cognitive complexity 18 (threshold 15). Drivers by points: if/else 7 (13 pts), loops 2 (3 pts), match/switch 1 (2 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleMap::new_module_with_pending (cognitive 17) libs/core/modules/map.rs:404— ModuleMap::new_module_with_pending has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (14 pts), match/switch 2 (3 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
D30 · Dependency Vulnerabilities· Medium advisory (unsound) · ×6
Duplicated block (23 lines × 2) cli/tools/compile.rs:660— cli/tools/compile.rs:660-682 | cli/tools/compile.rs:931-953 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23 lines × 2) cli/tools/lint/ast_buffer/swc.rs:393— cli/tools/lint/ast_buffer/swc.rs:393-415 | cli/tools/lint/ast_buffer/swc.rs:1493-1515 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23 lines × 2) ext/fs/ops.rs:1337— ext/fs/ops.rs:1337-1359 | ext/fs/ops.rs:1367-1389 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23 lines × 2) ext/node/ops/ipc.rs:282— ext/node/ops/ipc.rs:282-304 | ext/node/ops/ipc.rs:486-508 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23 lines × 2) ext/node/ops/zlib/mod.rs:1473— ext/node/ops/zlib/mod.rs:1473-1495 | ext/node/ops/zlib/mod.rs:1521-1543 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23 lines × 2) ext/node_sqlite/sql_tag_store.rs:703— ext/node_sqlite/sql_tag_store.rs:703-725 | ext/node_sqlite/statement.rs:914-936 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (11–12 lines × 2) cli/tools/desktop.rs:4184— cli/tools/desktop.rs:4184-4194 | cli/tools/desktop.rs:4204-4215 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11–12 lines × 2) cli/tools/repl/mod.rs:335— cli/tools/repl/mod.rs:335-345 | cli/tools/repl/mod.rs:393-404 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11–12 lines × 2) ext/fs/ops.rs:1236— ext/fs/ops.rs:1236-1246 | ext/fs/ops.rs:1281-1292 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11–12 lines × 2) ext/node/ops/vm.rs:91— ext/node/ops/vm.rs:91-102 | ext/node/ops/vm.rs:190-200 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11–12 lines × 2) libs/http_h1/conn.rs:1099— libs/http_h1/conn.rs:1099-1109 | libs/http_h1/conn.rs:1257-1268 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11–12 lines × 2) libs/npm/resolution/snapshot.rs:622— libs/npm/resolution/snapshot.rs:622-633 | libs/npm/resolution/snapshot.rs:860-870 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8 lines × 4) ext/node/ops/llhttp/binding.rs:331— ext/node/ops/llhttp/binding.rs:331-338 | ext/node/ops/llhttp/binding.rs:578-585 | ext/node/ops/llhttp/binding.rs:620-627 | ext/node/ops/llhttp/binding.rs:673-680 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 4) ext/web/console/mod.rs:1108— ext/web/console/mod.rs:1108-1115 | ext/web/console/mod.rs:1231-1238 | ext/web/console/mod.rs:1262-1269 | ext/web/console/mod.rs:1350-1357 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 4) REDACTED:1022— REDACTED:1022-1029 | REDACTED:1048-1055 | libs/core/uv_compat/stream.rs:503-510 | libs/core/uv_compat/stream.rs:608-615 — there are 4 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 4 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (8 lines × 4) libs/resolver/bun_lockfile_import.rs:340— libs/resolver/bun_lockfile_import.rs:340-347 | libs/resolver/npm_lockfile_import.rs:288-295 | libs/resolver/pnpm_lockfile_import.rs:743-750 | libs/resolver/yarn_lockfile_import.rs:181-188 — before extracting anything, compare `libs/resolver/bun_lockfile_import.rs` and `libs/resolver/npm_lockfile_import.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8 lines × 4) ext/fs/ops.rs:608— ext/fs/ops.rs:608-615 | ext/fs/ops.rs:651-658 | ext/fs/ops.rs:741-749 | ext/fs/ops.rs:998-1006 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 4) ext/web/css_value.rs:1221— ext/web/css_value.rs:1221-1228 | ext/web/css_value.rs:1230-1237 | ext/web/css_value.rs:1239-1246 | ext/web/css_value.rs:1342-1349 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
deno_http::http_next::serve_http11_raw (cyclomatic 68) ext/http/http_next.rs:4532— deno_http::http_next::serve_http11_raw has cyclomatic complexity 68 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_http::http_next::write_h1_stream_response_shared (cyclomatic 29) ext/http/http_next.rs:4338— deno_http::http_next::write_h1_stream_response_shared has cyclomatic complexity 29 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_http::http_next::write_h1_stream_response (cyclomatic 23) ext/http/http_next.rs:4184— deno_http::http_next::write_h1_stream_response has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_http::handle_error_otel (cyclomatic 18) ext/http/lib.rs:632— deno_http::handle_error_otel has cyclomatic complexity 18 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_http::http_next::write_h1_flat_response (cyclomatic 16) ext/http/http_next.rs:3561— deno_http::http_next::write_h1_flat_response has cyclomatic complexity 16 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
deno_runtime::cpu_profiler::cpuprof::generate_markdown_report (cyclomatic 34) runtime/cpu_profiler/cpuprof.rs:59— deno_runtime::cpu_profiler::cpuprof::generate_markdown_report has cyclomatic complexity 34 (threshold 15). Of this number, 23 points are the body's own statements and 11 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_runtime::fmt_errors::get_message_suggestions_inner (cyclomatic 33) runtime/fmt_errors.rs:472— deno_runtime::fmt_errors::get_message_suggestions_inner has cyclomatic complexity 33 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_runtime::fmt_errors::format_js_error_inner (cyclomatic 24) runtime/fmt_errors.rs:271— deno_runtime::fmt_errors::format_js_error_inner has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_runtime::cpu_profiler::flamegraph::generate_flamegraph_svg (cyclomatic 21) runtime/cpu_profiler/flamegraph.rs:15— deno_runtime::cpu_profiler::flamegraph::generate_flamegraph_svg has cyclomatic complexity 21 (threshold 15). Of this number, 16 points are the body's own statements and 5 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_runtime::web_worker::run_web_worker (cyclomatic 21) runtime/web_worker.rs:1137— deno_runtime::web_worker::run_web_worker has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Inner::code_action (cyclomatic 30) cli/lsp/language_server.rs:2151— Inner::code_action has cyclomatic complexity 30 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Inner::walk_workspace (cyclomatic 27) cli/lsp/language_server.rs:1066— Inner::walk_workspace has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Inner::did_change_watched_files (cyclomatic 22) cli/lsp/language_server.rs:1670— Inner::did_change_watched_files has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Inner::code_action_resolve (cyclomatic 19) cli/lsp/language_server.rs:2451— Inner::code_action_resolve has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Inner::initialize (cyclomatic 16) cli/lsp/language_server.rs:933— Inner::initialize has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_subprocess_windows::process::search_path_join_test (cyclomatic 29) runtime/subprocess_windows/src/process.rs:841— deno_subprocess_windows::process::search_path_join_test has cyclomatic complexity 29 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::search_path (cyclomatic 29) runtime/subprocess_windows/src/process.rs:975— deno_subprocess_windows::process::search_path has cyclomatic complexity 29 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::uv__kill (cyclomatic 28) runtime/subprocess_windows/src/process.rs:1115— deno_subprocess_windows::process::uv__kill has cyclomatic complexity 28 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::spawn (cyclomatic 25) runtime/subprocess_windows/src/process.rs:525— deno_subprocess_windows::process::spawn has cyclomatic complexity 25 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_subprocess_windows::process::append_bat_arg (cyclomatic 16) runtime/subprocess_windows/src/process.rs:1520— deno_subprocess_windows::process::append_bat_arg has cyclomatic complexity 16 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_runtime::cpu_profiler::cpuprof::generate_markdown_report (cognitive 62) runtime/cpu_profiler/cpuprof.rs:59— deno_runtime::cpu_profiler::cpuprof::generate_markdown_report has cognitive complexity 62 (threshold 15). Drivers by points: if/else 25 (41 pts), loops 13 (18 pts), boolean chains 2, match/switch 1 (nesting depth added 21). Of this number, 48 points are the body's own statements and 14 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_runtime::fmt_errors::format_js_error_inner (cognitive 51) runtime/fmt_errors.rs:271— deno_runtime::fmt_errors::format_js_error_inner has cognitive complexity 51 (threshold 15). Drivers by points: if/else 17 (31 pts), loops 4 (11 pts), match/switch 2 (6 pts), boolean chains 3 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_runtime::cpu_profiler::flamegraph::generate_flamegraph_svg (cognitive 48) runtime/cpu_profiler/flamegraph.rs:15— deno_runtime::cpu_profiler::flamegraph::generate_flamegraph_svg has cognitive complexity 48 (threshold 15). Drivers by points: if/else 17 (38 pts), loops 6 (8 pts), boolean chains 1, match/switch 1 (nesting depth added 23). Of this number, 37 points are the body's own statements and 11 belong to one function item inside it that branches. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_runtime::fmt_errors::get_message_suggestions_inner (cognitive 37) runtime/fmt_errors.rs:472— deno_runtime::fmt_errors::get_message_suggestions_inner has cognitive complexity 37 (threshold 15). Drivers by points: if/else 22 (27 pts), boolean chains 10 (nesting depth added 5). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
deno_runtime::web_worker::run_web_worker (cognitive 36) runtime/web_worker.rs:1137— deno_runtime::web_worker::run_web_worker has cognitive complexity 36 (threshold 15). Drivers by points: if/else 22 (32 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Workspace::split_cli_args_by_deno_json_folder (cognitive 59) libs/config/workspace/mod.rs:1625— Workspace::split_cli_args_by_deno_json_folder has cognitive complexity 59 (threshold 15). Drivers by points: if/else 9 (32 pts), loops 6 (15 pts), match/switch 2 (7 pts), boolean chains 5 (nesting depth added 37). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Workspace::diagnostics::check_all_configs (cognitive 49) libs/config/workspace/mod.rs:1320— Workspace::diagnostics::check_all_configs has cognitive complexity 49 (threshold 15). Drivers by points: if/else 18 (33 pts), loops 4 (9 pts), boolean chains 7 (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 2 other methods here (Workspace::diagnostics, Workspace::diagnostics::check_member_diagnostics) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 3 times rather than 3 independent problems. Splitting this body alone leaves the other 2 exactly as they are. Where these are variations on one operation, the change that clears all 3 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Workspace::config_folders_sorted_by_dependencies (cognitive 27) libs/config/workspace/mod.rs:713— Workspace::config_folders_sorted_by_dependencies has cognitive complexity 27 (threshold 15). Drivers by points: if/else 5 (9 pts), loops 5 (7 pts), match/switch 3 (6 pts), boolean chains 5 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Workspace::diagnostics (cognitive 24) libs/config/workspace/mod.rs:1203— Workspace::diagnostics has cognitive complexity 24 (threshold 15). Drivers by points: if/else 43 (69 pts), boolean chains 13, loops 6 (11 pts) (nesting depth added 31). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 2 other methods here (Workspace::diagnostics::check_member_diagnostics, Workspace::diagnostics::check_all_configs) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 3 times rather than 3 independent problems. Splitting this body alone leaves the other 2 exactly as they are. Where these are variations on one operation, the change that clears all 3 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Workspace::diagnostics::check_member_diagnostics (cognitive 18) libs/config/workspace/mod.rs:1204— Workspace::diagnostics::check_member_diagnostics has cognitive complexity 18 (threshold 15). Drivers by points: if/else 15, boolean chains 3. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: 2 other methods here (Workspace::diagnostics, Workspace::diagnostics::check_all_configs) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 3 times rather than 3 independent problems. Splitting this body alone leaves the other 2 exactly as they are. Where these are variations on one operation, the change that clears all 3 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Inner::code_action (cognitive 56) cli/lsp/language_server.rs:2151— Inner::code_action has cognitive complexity 56 (threshold 15). Drivers by points: if/else 25 (42 pts), match/switch 3 (8 pts), boolean chains 5, loops 1 (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Inner::walk_workspace (cognitive 55) cli/lsp/language_server.rs:1066— Inner::walk_workspace has cognitive complexity 55 (threshold 15). Drivers by points: if/else 15 (38 pts), loops 6 (9 pts), boolean chains 4, match/switch 1 (4 pts) (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Inner::code_action_resolve (cognitive 46) cli/lsp/language_server.rs:2451— Inner::code_action_resolve has cognitive complexity 46 (threshold 15). Drivers by points: if/else 24 (43 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Inner::did_change_watched_files (cognitive 26) cli/lsp/language_server.rs:1670— Inner::did_change_watched_files has cognitive complexity 26 (threshold 15). Drivers by points: if/else 8 (14 pts), boolean chains 6, match/switch 3 (5 pts), loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Inner::initialize (cognitive 17) cli/lsp/language_server.rs:933— Inner::initialize has cognitive complexity 17 (threshold 15). Drivers by points: if/else 11 (13 pts), boolean chains 4 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
ByonmNpmResolver::resolve_folder_in_root_node_modules (cognitive 42) libs/resolver/npm/byonm.rs:347— ByonmNpmResolver::resolve_folder_in_root_node_modules has cognitive complexity 42 (threshold 15). Drivers by points: if/else 17 (41 pts), loops 1 (nesting depth added 24). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
ByonmNpmResolver::resolve_pkg_json_and_alias_for_req (cognitive 25) libs/resolver/npm/byonm.rs:213— ByonmNpmResolver::resolve_pkg_json_and_alias_for_req has cognitive complexity 25 (threshold 15). Drivers by points: if/else 15 (32 pts), boolean chains 5, loops 3 (5 pts), match/switch 1 (3 pts) (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (ByonmNpmResolver::resolve_pkg_json_and_alias_for_req::resolve_alias_from_pkg_json) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
ByonmNpmResolver::resolve_pkg_json_and_alias_for_req::resolve_alias_from_pkg_json (cognitive 20) libs/resolver/npm/byonm.rs:221— ByonmNpmResolver::resolve_pkg_json_and_alias_for_req::resolve_alias_from_pkg_json has cognitive complexity 20 (threshold 15). Drivers by points: if/else 4 (14 pts), match/switch 1 (3 pts), boolean chains 2, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (ByonmNpmResolver::resolve_pkg_json_and_alias_for_req) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
ByonmNpmResolver::resolve_package_folder_from_package::inner (cognitive 18) libs/resolver/npm/byonm.rs:443— ByonmNpmResolver::resolve_package_folder_from_package::inner has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ByonmNpmResolver::resolve_pkg_folder_from_deno_module_req (cognitive 16) libs/resolver/npm/byonm.rs:132— ByonmNpmResolver::resolve_pkg_folder_from_deno_module_req has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (12 pts), boolean chains 2, loops 1, match/switch 1 (nesting depth added 6). Of this number, 9 points are the body's own statements and 7 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
REPLServer.constructor::_doComplete (cognitive 38) ext/node/polyfills/repl.ts:877— REPLServer.constructor::_doComplete has cognitive complexity 38 (threshold 15). Drivers by points: if/else 16 (22 pts), error handling 3 (10 pts), loops 1 (3 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor, REPLServer.constructor::defaultEval, REPLServer.constructor::_doComplete::completionGroupsLoaded, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::defaultEval (cognitive 32) ext/node/polyfills/repl.ts:774— REPLServer.constructor::defaultEval has cognitive complexity 32 (threshold 15). Drivers by points: if/else 10 (24 pts), boolean chains 3, error handling 1 (3 pts), loops 1 (2 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor, REPLServer.constructor::_doComplete, REPLServer.constructor::_doComplete::completionGroupsLoaded, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::clearPreview (cognitive 27) ext/node/polyfills/repl.ts:1341— REPLServer.constructor::clearPreview has cognitive complexity 27 (threshold 15). Drivers by points: if/else 12 (21 pts), boolean chains 6 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor, REPLServer.constructor::defaultEval, REPLServer.constructor::_doComplete, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::showPreview (cognitive 22) ext/node/polyfills/repl.ts:1236— REPLServer.constructor::showPreview has cognitive complexity 22 (threshold 15). Drivers by points: if/else 15, boolean chains 5, error handling 1, ternaries 1. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor, REPLServer.constructor::defaultEval, REPLServer.constructor::_doComplete, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::_doComplete::completionGroupsLoaded (cognitive 17) ext/node/polyfills/repl.ts:1117— REPLServer.constructor::_doComplete::completionGroupsLoaded has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (10 pts), loops 3 (5 pts), boolean chains 2 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor, REPLServer.constructor::defaultEval, REPLServer.constructor::_doComplete, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_node_sqlite::database::resolve_sqlite_system_path_alias (cognitive 18) ext/node_sqlite/database.rs:51— deno_node_sqlite::database::resolve_sqlite_system_path_alias has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 2 (3 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node_sqlite::database::custom_aggregate_step_base (cognitive 18) ext/node_sqlite/database.rs:2352— deno_node_sqlite::database::custom_aggregate_step_base has cognitive complexity 18 (threshold 15). Drivers by points: if/else 13 (16 pts), loops 1, match/switch 1 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node_sqlite::database::custom_aggregate_value_base (cognitive 18) ext/node_sqlite/database.rs:2461— deno_node_sqlite::database::custom_aggregate_value_base has cognitive complexity 18 (threshold 15). Drivers by points: if/else 14 (18 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_node_sqlite::backup::op_node_database_backup (cognitive 16) ext/node_sqlite/backup.rs:129— deno_node_sqlite::backup::op_node_database_backup has cognitive complexity 16 (threshold 15). Drivers by points: if/else 5 (12 pts), match/switch 2 (3 pts), loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node_sqlite::database::open_db (cognitive 16) ext/node_sqlite/database.rs:776— deno_node_sqlite::database::open_db has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11 (15 pts), match/switch 1 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Duplicated block (22 lines × 2) cli/tools/desktop.rs:1629— cli/tools/desktop.rs:1629-1650 | cli/tools/desktop.rs:1762-1783 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22 lines × 2) ext/crypto/mldsa.rs:205— ext/crypto/mldsa.rs:205-226 | ext/crypto/mlkem.rs:343-364 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (22 lines × 2) ext/http/http_next.rs:2821— ext/http/http_next.rs:2821-2842 | ext/http/http_next.rs:2885-2906 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22 lines × 2) ext/node/ops/wasi.rs:870— ext/node/ops/wasi.rs:870-891 | ext/node/ops/wasi.rs:893-914 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22 lines × 2) ext/node_sqlite/sql_tag_store.rs:316— ext/node_sqlite/sql_tag_store.rs:316-337 | ext/node_sqlite/sql_tag_store.rs:519-540 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18–19 lines × 2) cli/lib/worker.rs:208— cli/lib/worker.rs:208-225 | ext/node/ops/process.rs:674-692 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (18–19 lines × 2) cli/tools/bundle/mod.rs:440— cli/tools/bundle/mod.rs:440-458 | cli/tools/transpile.rs:250-267 — before extracting anything, compare `cli/tools/bundle/mod.rs` and `cli/tools/transpile.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 40 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (18–19 lines × 2) cli/tools/pack/unfurl.rs:239— cli/tools/pack/unfurl.rs:239-257 | cli/tools/pack/unfurl.rs:292-309 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18–19 lines × 2) ext/node/ops/stream_wrap.rs:1346— ext/node/ops/stream_wrap.rs:1346-1363 | ext/node/ops/stream_wrap.rs:2031-2049 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18–19 lines × 2) ext/node_crypto/cipher.rs:399— ext/node_crypto/cipher.rs:399-417 | ext/node_crypto/cipher.rs:423-440 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19 lines × 2) cli/util/extract.rs:1086— cli/util/extract.rs:1086-1104 | cli/util/extract.rs:1124-1142 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19 lines × 2) ext/http/http_next.rs:4281— ext/http/http_next.rs:4281-4299 | ext/http/http_next.rs:4452-4470 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19 lines × 2) ext/node/ops/fs.rs:3181— ext/node/ops/fs.rs:3181-3199 | ext/node/ops/fs.rs:3425-3443 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19 lines × 2) ext/node/ops/fs.rs:3408— ext/node/ops/fs.rs:3408-3426 | ext/node/ops/fs.rs:3458-3476 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19 lines × 2) ext/web/lib.rs:683— ext/web/lib.rs:683-701 | libs/core/ops_builtin_v8.rs:601-619 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (13–14 lines × 2) cli/lsp/registries.rs:834— cli/lsp/registries.rs:834-847 | cli/lsp/registries.rs:972-984 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–14 lines × 2) ext/crypto/subtle_decrypt.rs:262— ext/crypto/subtle_decrypt.rs:262-274 | ext/crypto/subtle_encrypt.rs:317-330 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (13–14 lines × 2) ext/crypto/subtle_wrap_key.rs:387— ext/crypto/subtle_wrap_key.rs:387-400 | libs/core/modules/import_graph.rs:186-198 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (13–14 lines × 2) libs/npm_installer/global.rs:256— libs/npm_installer/global.rs:256-269 | libs/npm_installer/local.rs:1459-1471 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (13–14 lines × 2) libs/npm_installer/hoisted.rs:754— libs/npm_installer/hoisted.rs:754-767 | libs/npm_installer/local.rs:1112-1124 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8–9 lines × 2) cli/tools/pack/package_json.rs:199— cli/tools/pack/package_json.rs:199-207 | cli/tools/pack/package_json.rs:212-219 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8–9 lines × 2) cli/tsc/tsconfig_gen.rs:332— cli/tsc/tsconfig_gen.rs:332-340 | cli/tsc/tsconfig_gen.rs:471-478 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8–9 lines × 2) ext/http/http_next.rs:3956— ext/http/http_next.rs:3956-3963 | ext/http/http_next.rs:4489-4497 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8–9 lines × 2) ext/node_crypto/lib.rs:417— ext/node_crypto/lib.rs:417-425 | ext/node_crypto/lib.rs:466-473 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8–9 lines × 2) runtime/ops/desktop.rs:1788— runtime/ops/desktop.rs:1788-1796 | runtime/ops/desktop.rs:1814-1821 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–8 lines × 2) ext/napi/js_native_api.rs:3055— ext/napi/js_native_api.rs:3055-3062 | ext/napi/js_native_api.rs:3113-3119 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–8 lines × 2) ext/node_crypto/x509.rs:1103— ext/node_crypto/x509.rs:1103-1109 | ext/node_crypto/x509.rs:1150-1157 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–8 lines × 2) ext/node_crypto/x509.rs:1111— ext/node_crypto/x509.rs:1111-1117 | ext/node_crypto/x509.rs:1159-1166 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–8 lines × 2) ext/node_crypto/x509.rs:1119— ext/node_crypto/x509.rs:1119-1125 | ext/node_crypto/x509.rs:1168-1175 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–8 lines × 2) ext/web/geometry.rs:2797— ext/web/geometry.rs:2797-2803 | ext/web/geometry.rs:2821-2828 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6 lines × 4) ext/signals/dict.rs:67— ext/signals/dict.rs:67-72 | ext/signals/dict.rs:102-107 | ext/signals/dict.rs:138-143 | ext/signals/dict.rs:173-178 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 4) ext/telemetry/lib.rs:2908— ext/telemetry/lib.rs:2908-2913 | ext/telemetry/lib.rs:2950-2955 | ext/telemetry/lib.rs:3001-3006 | ext/telemetry/lib.rs:3062-3067 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 4) ext/web/console/inspect.rs:1300— ext/web/console/inspect.rs:1300-1305 | ext/web/console/inspect.rs:1425-1430 | ext/web/console/inspect.rs:1567-1572 | ext/web/console/inspect.rs:3051-3056 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 4) runtime/ops/desktop.rs:842— runtime/ops/desktop.rs:842-847 | runtime/ops/desktop.rs:1870-1875 | runtime/ops/desktop.rs:1938-1943 | runtime/ops/desktop.rs:2103-2108 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 4) ext/node_crypto/lib.rs:1276— ext/node_crypto/lib.rs:1276-1281 | ext/node_crypto/lib.rs:1284-1289 | ext/node_crypto/lib.rs:1292-1297 | ext/node_crypto/lib.rs:1300-1305 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
GraphDependencyResolver::resolve_peers_of_node (cyclomatic 56) libs/npm/resolution/graph.rs:1864— GraphDependencyResolver::resolve_peers_of_node has cyclomatic complexity 56 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDependencyResolver::run_dedup_pass (cyclomatic 50) libs/npm/resolution/graph.rs:3047— GraphDependencyResolver::run_dedup_pass has cyclomatic complexity 50 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDependencyResolver::find_peers_cache_hit_inner (cyclomatic 20) libs/npm/resolution/graph.rs:2350— GraphDependencyResolver::find_peers_cache_hit_inner has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDependencyResolver::drain_pending_parallel (cyclomatic 18) libs/npm/resolution/graph.rs:2469— GraphDependencyResolver::drain_pending_parallel has cyclomatic complexity 18 (threshold 15). Of this number, 13 points are the body's own statements and 5 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Flags::to_permission_args (cyclomatic 40) cli/args/flags.rs:189— Flags::to_permission_args has cyclomatic complexity 40 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
Flags::parse (cyclomatic 22) libs/ops/op2/config.rs:236— Flags::parse has cyclomatic complexity 22 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Flags::otel_config (cyclomatic 18) cli/args/flags.rs:419— Flags::otel_config has cyclomatic complexity 18 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
Flags::config_path_args (cyclomatic 16) cli/args/flags.rs:492— Flags::config_path_args has cyclomatic complexity 16 (threshold 15). Of this number, 10 points are the body's own statements and 6 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
KeyObjectHandle::new_asymmetric_private_key_from_js (cyclomatic 39) ext/node_crypto/keys.rs:989— KeyObjectHandle::new_asymmetric_private_key_from_js has cyclomatic complexity 39 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
KeyObjectHandle::verify_prehashed (cyclomatic 31) ext/node_crypto/sign.rs:496— KeyObjectHandle::verify_prehashed has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
KeyObjectHandle::new_asymmetric_public_key_from_js (cyclomatic 29) ext/node_crypto/keys.rs:1543— KeyObjectHandle::new_asymmetric_public_key_from_js has cyclomatic complexity 29 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
KeyObjectHandle::sign_prehashed (cyclomatic 20) ext/node_crypto/sign.rs:302— KeyObjectHandle::sign_prehashed has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Workspace::diagnostics::check_all_configs (cyclomatic 28) libs/config/workspace/mod.rs:1320— Workspace::diagnostics::check_all_configs has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (Workspace::diagnostics::check_member_diagnostics) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Workspace::split_cli_args_by_deno_json_folder (cyclomatic 22) libs/config/workspace/mod.rs:1625— Workspace::split_cli_args_by_deno_json_folder has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Workspace::config_folders_sorted_by_dependencies (cyclomatic 21) libs/config/workspace/mod.rs:713— Workspace::config_folders_sorted_by_dependencies has cyclomatic complexity 21 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
Workspace::diagnostics::check_member_diagnostics (cyclomatic 19) libs/config/workspace/mod.rs:1204— Workspace::diagnostics::check_member_diagnostics has cyclomatic complexity 19 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: one other method here (Workspace::diagnostics::check_all_configs) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
WasiContext::poll_oneoff (cyclomatic 26) ext/node/ops/wasi.rs:1919— WasiContext::poll_oneoff has cyclomatic complexity 26 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
WasiContext::fd_read (cyclomatic 22) ext/node/ops/wasi.rs:829— WasiContext::fd_read has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
WasiContext::path_open (cyclomatic 21) ext/node/ops/wasi.rs:1378— WasiContext::path_open has cyclomatic complexity 21 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
WasiContext::fd_write (cyclomatic 18) ext/node/ops/wasi.rs:762— WasiContext::fd_write has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DenoCompileBinaryWriter::write_standalone_binary (cognitive 115) cli/standalone/binary.rs:634— DenoCompileBinaryWriter::write_standalone_binary has cognitive complexity 115 (threshold 15). Drivers by points: if/else 34 (69 pts), match/switch 14 (31 pts), loops 11 (13 pts), boolean chains 2 (nesting depth added 54). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoCompileBinaryWriter::build_vfs_consolidating_global_npm_cache (cognitive 39) cli/standalone/binary.rs:1491— DenoCompileBinaryWriter::build_vfs_consolidating_global_npm_cache has cognitive complexity 39 (threshold 15). Drivers by points: if/else 10 (25 pts), loops 4 (9 pts), match/switch 2 (4 pts), boolean chains 1 (nesting depth added 22). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
DenoCompileBinaryWriter::fill_npm_vfs (cognitive 31) cli/standalone/binary.rs:1397— DenoCompileBinaryWriter::fill_npm_vfs has cognitive complexity 31 (threshold 15). Drivers by points: if/else 9 (21 pts), loops 3 (8 pts), boolean chains 1, match/switch 1 (nesting depth added 17). Of this number, 30 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoCompileBinaryWriter::fill_bundle_native_addon_vfs (cognitive 18) cli/standalone/binary.rs:1311— DenoCompileBinaryWriter::fill_bundle_native_addon_vfs has cognitive complexity 18 (threshold 15). Drivers by points: if/else 5 (12 pts), boolean chains 3, loops 1 (2 pts), match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_process::create_command (cognitive 74) ext/process/lib.rs:685— deno_process::create_command has cognitive complexity 74 (threshold 15). Drivers by points: if/else 28 (51 pts), match/switch 7 (12 pts), loops 4 (6 pts), boolean chains 5 (nesting depth added 30). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_process::op_spawn_sync (cognitive 27) ext/process/lib.rs:1690— deno_process::op_spawn_sync has cognitive complexity 27 (threshold 15). Drivers by points: if/else 17 (32 pts), match/switch 4 (5 pts), boolean chains 3, loops 2 (3 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_process::op_spawn_sync::read_with_limit) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_process::deprecated::kill (cognitive 17) ext/process/lib.rs:2302— deno_process::deprecated::kill has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (10 pts), match/switch 3 (7 pts) (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_process::op_spawn_sync::read_with_limit (cognitive 16) ext/process/lib.rs:1847— deno_process::op_spawn_sync::read_with_limit has cognitive complexity 16 (threshold 15). Drivers by points: if/else 4 (13 pts), match/switch 1 (2 pts), loops 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_process::op_spawn_sync) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_ffi::callback::do_ffi_callback (cognitive 67) ext/ffi/callback.rs:212— deno_ffi::callback::do_ffi_callback has cognitive complexity 67 (threshold 15). Drivers by points: if/else 41 (61 pts), match/switch 3 (5 pts), loops 1 (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_ffi::turbocall::compile_trampoline (cognitive 21) ext/ffi/turbocall.rs:62— deno_ffi::turbocall::compile_trampoline has cognitive complexity 21 (threshold 15). Drivers by points: if/else 20 (28 pts), loops 5, match/switch 3 (4 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_ffi::turbocall::compile_trampoline::convert) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_ffi::dlfcn::op_ffi_load (cognitive 18) ext/ffi/dlfcn.rs:145— deno_ffi::dlfcn::op_ffi_load has cognitive complexity 18 (threshold 15). Drivers by points: match/switch 5 (12 pts), if/else 2 (5 pts), loops 1 (nesting depth added 10). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_ffi::turbocall::compile_trampoline::convert (cognitive 16) ext/ffi/turbocall.rs:107— deno_ffi::turbocall::compile_trampoline::convert has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10 (15 pts), match/switch 1 (nesting depth added 5). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident. This shape REPEATS in the file: one other method here (deno_ffi::turbocall::compile_trampoline) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
KeyObjectHandle::verify_prehashed (cognitive 67) ext/node_crypto/sign.rs:496— KeyObjectHandle::verify_prehashed has cognitive complexity 67 (threshold 15). Drivers by points: if/else 27 (60 pts), match/switch 3 (7 pts) (nesting depth added 37). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
KeyObjectHandle::new_asymmetric_private_key_from_js (cognitive 43) ext/node_crypto/keys.rs:989— KeyObjectHandle::new_asymmetric_private_key_from_js has cognitive complexity 43 (threshold 15). Drivers by points: if/else 13 (26 pts), match/switch 7 (17 pts) (nesting depth added 23). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
KeyObjectHandle::sign_prehashed (cognitive 23) ext/node_crypto/sign.rs:302— KeyObjectHandle::sign_prehashed has cognitive complexity 23 (threshold 15). Drivers by points: if/else 11 (19 pts), match/switch 2 (3 pts), boolean chains 1 (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
KeyObjectHandle::new_asymmetric_public_key_from_js (cognitive 20) ext/node_crypto/keys.rs:1543— KeyObjectHandle::new_asymmetric_public_key_from_js has cognitive complexity 20 (threshold 15). Drivers by points: match/switch 7 (12 pts), if/else 4 (8 pts) (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
EszipV2::parse_with_version (cognitive 57) libs/eszip/v2.rs:734— EszipV2::parse_with_version has cognitive complexity 57 (threshold 15). Drivers by points: if/else 19 (30 pts), match/switch 7 (16 pts), loops 6 (9 pts), boolean chains 2 (nesting depth added 23). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EszipV2::from_graph::visit_module (cognitive 29) libs/eszip/v2.rs:1349— EszipV2::from_graph::visit_module has cognitive complexity 29 (threshold 15). Drivers by points: if/else 8 (15 pts), loops 2 (7 pts), match/switch 4 (7 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (EszipV2::from_graph) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
EszipV2::into_bytes (cognitive 19) libs/eszip/v2.rs:1109— EszipV2::into_bytes has cognitive complexity 19 (threshold 15). Drivers by points: if/else 5 (9 pts), loops 4 (8 pts), match/switch 1 (2 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EszipV2::from_graph (cognitive 17) libs/eszip/v2.rs:1281— EszipV2::from_graph has cognitive complexity 17 (threshold 15). Drivers by points: if/else 16 (27 pts), loops 6 (14 pts), match/switch 4 (7 pts) (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (EszipV2::from_graph::visit_module) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
DatabaseSync::prepare (cognitive 43) ext/node_sqlite/database.rs:1095— DatabaseSync::prepare has cognitive complexity 43 (threshold 15). Drivers by points: if/else 11 (42 pts), boolean chains 1 (nesting depth added 31). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
DatabaseSync::function (cognitive 34) ext/node_sqlite/database.rs:1212— DatabaseSync::function has cognitive complexity 34 (threshold 15). Drivers by points: if/else 19 (32 pts), boolean chains 2 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DatabaseSync::deserialize (cognitive 26) ext/node_sqlite/database.rs:2129— DatabaseSync::deserialize has cognitive complexity 26 (threshold 15). Drivers by points: if/else 15 (23 pts), boolean chains 2, loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DatabaseSync::apply_changeset (cognitive 16) ext/node_sqlite/database.rs:1416— DatabaseSync::apply_changeset has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11 (16 pts) (nesting depth added 5). Most of this is not in the body itself: 7 of the 16 points are its own statements and the rest belongs to 2 function items inside it that branch (conflict_handler, filter_handler). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
SpecifierUnfurler::unfurl_specifier (cognitive 41) cli/tools/publish/unfurl.rs:421— SpecifierUnfurler::unfurl_specifier has cognitive complexity 41 (threshold 15). Drivers by points: match/switch 10 (33 pts), if/else 4 (8 pts) (nesting depth added 27). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
SpecifierUnfurler::unfurl_to_changes (cognitive 35) cli/tools/publish/unfurl.rs:905— SpecifierUnfurler::unfurl_to_changes has cognitive complexity 35 (threshold 15). Drivers by points: if/else 9 (19 pts), match/switch 4 (10 pts), loops 5, boolean chains 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SpecifierUnfurler::try_unfurl_dynamic_dep (cognitive 26) cli/tools/publish/unfurl.rs:814— SpecifierUnfurler::try_unfurl_dynamic_dep has cognitive complexity 26 (threshold 15). Drivers by points: if/else 8 (23 pts), match/switch 2 (3 pts) (nesting depth added 16). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
SpecifierUnfurler::find_types_package_version_req (cognitive 18) cli/tools/publish/unfurl.rs:688— SpecifierUnfurler::find_types_package_version_req has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (11 pts), loops 4 (6 pts), boolean chains 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrap::writev (cognitive 35) ext/node/ops/tls_wrap.rs:2593— TLSWrap::writev has cognitive complexity 35 (threshold 15). Drivers by points: if/else 11 (31 pts), loops 2 (4 pts) (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrap::read_start (cognitive 20) ext/node/ops/tls_wrap.rs:2482— TLSWrap::read_start has cognitive complexity 20 (threshold 15). Drivers by points: if/else 11 (16 pts), boolean chains 4 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrap::start (cognitive 19) ext/node/ops/tls_wrap.rs:2386— TLSWrap::start has cognitive complexity 19 (threshold 15). Drivers by points: if/else 6 (11 pts), match/switch 4 (8 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrap::set_alpn_protocols (cognitive 16) ext/node/ops/tls_wrap.rs:3056— TLSWrap::set_alpn_protocols has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (11 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node_crypto::cipher::aes_unwrap_key (cognitive 32) ext/node_crypto/cipher.rs:198— deno_node_crypto::cipher::aes_unwrap_key has cognitive complexity 32 (threshold 15). Drivers by points: if/else 15 (24 pts), boolean chains 4, loops 1 (3 pts), match/switch 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node_crypto::op_node_ecdh_compute_secret (cognitive 26) ext/node_crypto/lib.rs:1338— deno_node_crypto::op_node_ecdh_compute_secret has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (25 pts), match/switch 1 (nesting depth added 15). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_node_crypto::cipher::aes_wrap_key (cognitive 23) ext/node_crypto/cipher.rs:52— deno_node_crypto::cipher::aes_wrap_key has cognitive complexity 23 (threshold 15). Drivers by points: if/else 12 (20 pts), boolean chains 2, match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_node_crypto::keys::dsa_generate_components (cognitive 20) ext/node_crypto/keys.rs:3117— deno_node_crypto::keys::dsa_generate_components has cognitive complexity 20 (threshold 15). Drivers by points: if/else 4 (11 pts), loops 4 (7 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Flags::parse (cognitive 25) libs/ops/op2/config.rs:236— Flags::parse has cognitive complexity 25 (threshold 15). Drivers by points: if/else 21 (22 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 2). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Flags::config_path_args (cognitive 23) cli/args/flags.rs:492— Flags::config_path_args has cognitive complexity 23 (threshold 15). Drivers by points: if/else 14 (19 pts), match/switch 2 (3 pts), boolean chains 1 (nesting depth added 6). Most of this is not in the body itself: 9 of the 23 points are its own statements and the rest belongs to 2 function items inside it that branch (resolve_single_folder_path, resolve_multiple_files). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
Flags::to_permission_args (cognitive 20) cli/args/flags.rs:189— Flags::to_permission_args has cognitive complexity 20 (threshold 15). Drivers by points: match/switch 19, if/else 1. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
Flags::otel_config (cognitive 19) cli/args/flags.rs:419— Flags::otel_config has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (10 pts), match/switch 4 (6 pts), boolean chains 3 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_inspector_server::parse_host_authority (cognitive 19) libs/inspector_server/lib.rs:112— deno_inspector_server::parse_host_authority has cognitive complexity 19 (threshold 15). Drivers by points: if/else 12 (17 pts), boolean chains 1, match/switch 1 (nesting depth added 5). Of this number, 17 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_inspector_server::server (cognitive 19) libs/inspector_server/lib.rs:646— deno_inspector_server::server has cognitive complexity 19 (threshold 15). Drivers by points: match/switch 7 (14 pts), if/else 2 (4 pts), loops 1 (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_inspector_server::pump_websocket_messages (cognitive 18) libs/inspector_server/lib.rs:845— deno_inspector_server::pump_websocket_messages has cognitive complexity 18 (threshold 15). Drivers by points: match/switch 4 (12 pts), if/else 1 (5 pts), loops 1 (nesting depth added 12). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_inspector_server::pump_event_notifications (cognitive 17) libs/inspector_server/lib.rs:596— deno_inspector_server::pump_event_notifications has cognitive complexity 17 (threshold 15). Drivers by points: if/else 2 (8 pts), match/switch 3 (8 pts), loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
D4 · Code Duplication· Members sharing a duplicated core (5 members, 50+ identical tokens) · ×4
Members sharing a duplicated core (5 members, 50+ identical tokens) ext/crypto/node_interop.rs:337— ext/crypto/node_interop.rs:337-348 | ext/crypto/node_interop.rs:354-365 | ext/crypto/subtle_crypto.rs:840-851 | ext/crypto/subtle_generate_key.rs:782-793 | ext/crypto/subtle_import_key.rs:1926-1937 — These 5 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 5 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 5 times.
Members sharing a duplicated core (5 members, 50+ identical tokens) ext/net/ops.rs:302— ext/net/ops.rs:302-315 | ext/net/ops.rs:384-409 | ext/net/ops.rs:417-441 | ext/net/ops.rs:449-463 | ext/net/ops.rs:471-484 — These 5 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 5 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 5 times.
Members sharing a duplicated core (5 members, 50+ identical tokens) ext/node/ops/wasi.rs:1510— ext/node/ops/wasi.rs:1510-1528 | ext/node/ops/wasi.rs:1537-1555 | ext/node/ops/wasi.rs:1564-1582 | ext/node/ops/wasi.rs:1594-1624 | ext/node/ops/wasi.rs:1738-1793 — These 5 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 5 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 5 times.
Members sharing a duplicated core (5 members, 50+ identical tokens) ext/webgpu/adapter.rs:119— ext/webgpu/adapter.rs:119-247 | runtime/ops/desktop.rs:757-847 | runtime/ops/desktop.rs:1856-1875 | runtime/ops/desktop.rs:1923-1943 | runtime/ops/desktop.rs:2050-2108 — These 5 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 5 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 5 times.
Duplicated block (26 lines × 2) ext/crypto/subtle_generate_key.rs:821— ext/crypto/subtle_generate_key.rs:821-846 | ext/crypto/subtle_import_key.rs:147-172 — before extracting anything, compare `ext/crypto/subtle_generate_key.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 118 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (26 lines × 2) ext/crypto/subtle_sign.rs:194— ext/crypto/subtle_sign.rs:194-219 | ext/crypto/subtle_verify.rs:188-213 — before extracting anything, compare `ext/crypto/subtle_sign.rs` and `ext/crypto/subtle_verify.rs` as WHOLE FILES: this scan already matched 6 separate duplicated blocks between them, totalling at least 160 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (26 lines × 2) ext/node/ops/fs.rs:1605— ext/node/ops/fs.rs:1605-1630 | ext/node/ops/fs.rs:1932-1957 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (26 lines × 2) ext/node/ops/perf_hooks.rs:297— ext/node/ops/perf_hooks.rs:297-322 | ext/node/ops/perf_hooks.rs:328-353 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–16 lines × 2) cli/ops/bench.rs:58— cli/ops/bench.rs:58-73 | cli/ops/testing.rs:88-102 — before extracting anything, compare `cli/ops/bench.rs` and `cli/ops/testing.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 39 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (15–16 lines × 2) ext/crypto/subtle_import_key.rs:404— ext/crypto/subtle_import_key.rs:404-419 | ext/crypto/subtle_import_key.rs:559-573 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–16 lines × 2) ext/http/http_next.rs:2413— ext/http/http_next.rs:2413-2428 | ext/http/http_next.rs:2477-2491 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–16 lines × 2) ext/http/http_next.rs:4216— ext/http/http_next.rs:4216-4231 | ext/http/http_next.rs:4373-4387 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12–13 lines × 2) ext/http/http_next.rs:4599— ext/http/http_next.rs:4599-4611 | ext/http/http_next.rs:4974-4985 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12–13 lines × 2) ext/node/ops/http2/session.rs:1043— ext/node/ops/http2/session.rs:1043-1054 | ext/node/ops/http2/session.rs:1119-1131 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12–13 lines × 2) libs/core/uv_compat/stream.rs:304— libs/core/uv_compat/stream.rs:304-315 | libs/core/uv_compat/stream.rs:346-358 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12–13 lines × 2) libs/npmrc/lib.rs:273— libs/npmrc/lib.rs:273-284 | libs/npmrc/lib.rs:298-310 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10–11 lines × 2) cli/lsp/completions.rs:625— cli/lsp/completions.rs:625-635 | cli/lsp/completions.rs:785-794 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10–11 lines × 2) ext/crypto/subtle_derive_bits.rs:368— ext/crypto/subtle_derive_bits.rs:368-377 | ext/crypto/subtle_key.rs:95-105 — before extracting anything, compare `ext/crypto/subtle_derive_bits.rs` and `ext/crypto/subtle_key.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10–11 lines × 2) libs/core/ops.rs:222— libs/core/ops.rs:222-231 | libs/core/ops.rs:239-249 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10–11 lines × 2) REDACTED:724— REDACTED:724-734 | REDACTED:936-945 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7 lines × 4) ext/crypto/crypto_key.rs:182— ext/crypto/crypto_key.rs:182-188 | ext/crypto/subtle_generate_key.rs:864-870 | ext/crypto/subtle_import_key.rs:1997-2003 | ext/crypto/subtle_key.rs:184-190 — before extracting anything, compare `ext/crypto/subtle_generate_key.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 118 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 4) ext/crypto/digest.rs:407— ext/crypto/digest.rs:407-413 | ext/crypto/subtle_decrypt.rs:284-290 | ext/crypto/subtle_encrypt.rs:340-346 | ext/crypto/subtle_sign.rs:343-349 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_decrypt.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7 lines × 4) ext/node_sqlite/database.rs:1279— ext/node_sqlite/database.rs:1279-1285 | ext/node_sqlite/database.rs:1296-1302 | ext/node_sqlite/database.rs:1312-1318 | ext/node_sqlite/database.rs:1329-1335 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 4) ext/node/ops/fs.rs:573— ext/node/ops/fs.rs:573-579 | ext/node/ops/fs.rs:619-625 | ext/node/ops/fs.rs:654-660 | ext/node/ops/fs.rs:766-772 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
deno_ffi::callback::do_ffi_callback (cyclomatic 61) ext/ffi/callback.rs:212— deno_ffi::callback::do_ffi_callback has cyclomatic complexity 61 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_ffi::turbocall::compile_trampoline::convert (cyclomatic 23) ext/ffi/turbocall.rs:107— deno_ffi::turbocall::compile_trampoline::convert has cyclomatic complexity 23 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This shape REPEATS in the file: one other method here (deno_ffi::turbocall::compile_trampoline) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_ffi::turbocall::compile_trampoline (cyclomatic 18) ext/ffi/turbocall.rs:62— deno_ffi::turbocall::compile_trampoline has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (deno_ffi::turbocall::compile_trampoline::convert) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Decipher::new (cyclomatic 46) ext/node_crypto/cipher.rs:1282— Decipher::new has cyclomatic complexity 46 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (Cipher::new) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Decipher::r#final (cyclomatic 33) ext/node_crypto/cipher.rs:1558— Decipher::r#final has cyclomatic complexity 33 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Decipher::decrypt (cyclomatic 19) ext/node_crypto/cipher.rs:1492— Decipher::decrypt has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This shape REPEATS in the file: one other method here (Cipher::encrypt) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_config::util::parse_iso8601_duration (cyclomatic 35) libs/config/util.rs:168— deno_config::util::parse_iso8601_duration has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_config::workspace::discovery::discover_workspace_config_files_for_single_dir (cyclomatic 29) libs/config/workspace/discovery.rs:235— deno_config::workspace::discovery::discover_workspace_config_files_for_single_dir has cyclomatic complexity 29 (threshold 15). Of this number, 28 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_config::workspace::discovery::resolve_workspace_for_config_folder (cyclomatic 27) libs/config/workspace/discovery.rs:682— deno_config::workspace::discovery::resolve_workspace_for_config_folder has cyclomatic complexity 27 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
EmbeddedModuleLoader::load_default (cyclomatic 25) cli/rt/run.rs:469— EmbeddedModuleLoader::load_default has cyclomatic complexity 25 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
EmbeddedModuleLoader::resolve_inner (cyclomatic 19) cli/rt/run.rs:231— EmbeddedModuleLoader::resolve_inner has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
EmbeddedModuleLoader::load (cyclomatic 16) cli/rt/run.rs:802— EmbeddedModuleLoader::load has cyclomatic complexity 16 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
REPLServer.constructor::showPreview (cyclomatic 23) ext/node/polyfills/repl.ts:1236— REPLServer.constructor::showPreview has cyclomatic complexity 23 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: 3 other methods here (REPLServer.constructor, REPLServer.constructor::_doComplete, REPLServer.constructor::clearPreview) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 4 times rather than 4 independent problems. Splitting this body alone leaves the other 3 exactly as they are. Where these are variations on one operation, the change that clears all 4 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::clearPreview (cyclomatic 21) ext/node/polyfills/repl.ts:1341— REPLServer.constructor::clearPreview has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: 3 other methods here (REPLServer.constructor, REPLServer.constructor::_doComplete, REPLServer.constructor::showPreview) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 4 times rather than 4 independent problems. Splitting this body alone leaves the other 3 exactly as they are. Where these are variations on one operation, the change that clears all 4 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
REPLServer.constructor::_doComplete (cyclomatic 20) ext/node/polyfills/repl.ts:877— REPLServer.constructor::_doComplete has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: 3 other methods here (REPLServer.constructor, REPLServer.constructor::showPreview, REPLServer.constructor::clearPreview) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 4 times rather than 4 independent problems. Splitting this body alone leaves the other 3 exactly as they are. Where these are variations on one operation, the change that clears all 4 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
NodeResolver::resolve_package_target_string (cyclomatic 20) libs/node_resolver/resolution.rs:1399— NodeResolver::resolve_package_target_string has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
NodeResolver::finalize_resolution (cyclomatic 18) libs/node_resolver/resolution.rs:802— NodeResolver::finalize_resolution has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
NodeResolver::path_to_declaration_path (cyclomatic 18) libs/node_resolver/resolution.rs:1223— NodeResolver::path_to_declaration_path has cyclomatic complexity 18 (threshold 15). Most of this is not in the body itself: 8 of the 18 points are its own statements and the rest belongs to one function item inside it that branches (probe_extensions). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
deno_napi::js_native_api::napi_get_typedarray_info (cyclomatic 19) ext/napi/js_native_api.rs:3875— deno_napi::js_native_api::napi_get_typedarray_info has cyclomatic complexity 19 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_napi::js_native_api::napi_define_class (cyclomatic 16) ext/napi/js_native_api.rs:311— deno_napi::js_native_api::napi_define_class has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_napi::js_native_api::napi_create_typedarray (cyclomatic 18) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_napi::js_native_api::napi_define_properties (cyclomatic 16) ext/napi/js_native_api.rs:842— deno_napi::js_native_api::napi_define_properties has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_napi::js_native_api::napi_create_typedarray (cyclomatic 18) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
deno_lockfile::transforms::transform3_to_4 (cognitive 103) libs/lockfile/transforms.rs:83— deno_lockfile::transforms::transform3_to_4 has cognitive complexity 103 (threshold 15). Drivers by points: if/else 21 (77 pts), loops 8 (26 pts) (nesting depth added 74). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_lockfile::transforms::transform4_to_5 (cognitive 50) libs/lockfile/transforms.rs:239— deno_lockfile::transforms::transform4_to_5 has cognitive complexity 50 (threshold 15). Drivers by points: if/else 17 (38 pts), loops 4 (12 pts) (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_lockfile::split_git_conflict_sides (cognitive 16) libs/lockfile/lib.rs:1277— deno_lockfile::split_git_conflict_sides has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (10 pts), boolean chains 3, match/switch 1 (2 pts), loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WorkspaceResolver::resolve (cognitive 76) libs/resolver/workspace.rs:1354— WorkspaceResolver::resolve has cognitive complexity 76 (threshold 15). Drivers by points: if/else 21 (49 pts), loops 4 (10 pts), match/switch 4 (10 pts), boolean chains 7 (nesting depth added 40). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
WorkspaceResolver::from_workspace (cognitive 38) libs/resolver/workspace.rs:856— WorkspaceResolver::from_workspace has cognitive complexity 38 (threshold 15). Drivers by points: if/else 16 (23 pts), match/switch 5 (8 pts), boolean chains 4, loops 2 (3 pts) (nesting depth added 11). None of this is in the body itself: all 38 points belong to 4 function items inside it that branch (resolve_import_map, resolve_import_map::expand_catalog_specifiers::expand_entries, resolve_import_map::expand_catalog_specifiers, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
WorkspaceResolver::maybe_resolve_specifier_to_workspace_jsr_pkg (cognitive 20) libs/resolver/workspace.rs:1585— WorkspaceResolver::maybe_resolve_specifier_to_workspace_jsr_pkg has cognitive complexity 20 (threshold 15). Drivers by points: if/else 7 (16 pts), loops 1 (2 pts), match/switch 2 (nesting depth added 10). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
GraphWalker::resolve_pending (cognitive 64) cli/type_checker.rs:1129— GraphWalker::resolve_pending has cognitive complexity 64 (threshold 15). Drivers by points: if/else 15 (42 pts), match/switch 3 (9 pts), loops 3 (8 pts), boolean chains 5 (nesting depth added 38). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphWalker::add_unresolved_dts_entrypoint_imports (cognitive 20) cli/type_checker.rs:1402— GraphWalker::add_unresolved_dts_entrypoint_imports has cognitive complexity 20 (threshold 15). Drivers by points: if/else 4 (13 pts), loops 2 (3 pts), match/switch 1 (3 pts), boolean chains 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphWalker::maybe_get_check_entry (cognitive 17) cli/type_checker.rs:1275— GraphWalker::maybe_get_check_entry has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (12 pts), match/switch 2 (3 pts), boolean chains 2 (nesting depth added 7). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
DepManager::commit_changes (cognitive 52) cli/tools/pm/deps.rs:1088— DepManager::commit_changes has cognitive complexity 52 (threshold 15). Drivers by points: if/else 12 (40 pts), match/switch 3 (9 pts), loops 2, boolean chains 1 (nesting depth added 34). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DepManager::run_dependency_resolution (cognitive 40) cli/tools/pm/deps.rs:723— DepManager::run_dependency_resolution has cognitive complexity 40 (threshold 15). Drivers by points: if/else 11 (26 pts), loops 4 (9 pts), match/switch 2 (4 pts), boolean chains 1 (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DepManager::load_latest_versions (cognitive 26) cli/tools/pm/deps.rs:886— DepManager::load_latest_versions has cognitive complexity 26 (threshold 15). Drivers by points: if/else 7 (17 pts), loops 3 (5 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EmbeddedModuleLoader::load_default (cognitive 51) cli/rt/run.rs:469— EmbeddedModuleLoader::load_default has cognitive complexity 51 (threshold 15). Drivers by points: match/switch 10 (28 pts), if/else 13 (22 pts), boolean chains 1 (nesting depth added 27). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
EmbeddedModuleLoader::load (cognitive 27) cli/rt/run.rs:802— EmbeddedModuleLoader::load has cognitive complexity 27 (threshold 15). Drivers by points: match/switch 7 (15 pts), if/else 8 (11 pts), boolean chains 1 (nesting depth added 11). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
EmbeddedModuleLoader::resolve_inner (cognitive 19) cli/rt/run.rs:231— EmbeddedModuleLoader::resolve_inner has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (11 pts), match/switch 3 (6 pts), boolean chains 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SharedConn::poll_read_body_chunk_limited_inner (cognitive 39) libs/http_h1/conn.rs:928— SharedConn::poll_read_body_chunk_limited_inner has cognitive complexity 39 (threshold 15). Drivers by points: if/else 10 (27 pts), match/switch 4 (10 pts), boolean chains 1, loops 1 (nesting depth added 23). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SharedConn::poll_next_request_with (cognitive 29) libs/http_h1/conn.rs:814— SharedConn::poll_next_request_with has cognitive complexity 29 (threshold 15). Drivers by points: if/else 10 (27 pts), boolean chains 1, loops 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SharedConn::poll_write_response_chunk_with (cognitive 19) libs/http_h1/conn.rs:1309— SharedConn::poll_write_response_chunk_with has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (14 pts), loops 2 (4 pts), match/switch 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TsServer::provide_code_actions (cognitive 37) cli/lsp/ts_server.rs:325— TsServer::provide_code_actions has cognitive complexity 37 (threshold 15). Drivers by points: if/else 6 (19 pts), match/switch 4 (10 pts), loops 2 (5 pts), boolean chains 3 (nesting depth added 22). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
TsServer::provide_references (cognitive 25) cli/lsp/ts_server.rs:147— TsServer::provide_references has cognitive complexity 25 (threshold 15). Drivers by points: if/else 5 (18 pts), loops 2 (5 pts), boolean chains 1, match/switch 1 (nesting depth added 16). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
TsServer::provide_will_rename_files (cognitive 21) cli/lsp/ts_server.rs:1131— TsServer::provide_will_rename_files has cognitive complexity 21 (threshold 15). Drivers by points: if/else 4 (15 pts), loops 2 (5 pts), match/switch 1 (nesting depth added 14). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
deno_npm_cache::write_slim_version (cognitive 20) libs/npm_cache/lib.rs:579— deno_npm_cache::write_slim_version has cognitive complexity 20 (threshold 15). Drivers by points: if/else 11 (17 pts), boolean chains 1, loops 1, match/switch 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npm_cache::fs_util::hard_link_file (cognitive 20) libs/npm_cache/fs_util.rs:89— deno_npm_cache::fs_util::hard_link_file has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (20 pts) (nesting depth added 11). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_npm_cache::tarball_extract::extract_tarball (cognitive 17) libs/npm_cache/tarball_extract.rs:361— deno_npm_cache::tarball_extract::extract_tarball has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (14 pts), match/switch 1 (2 pts), loops 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Duplicated block (31 lines × 2) ext/crypto/subtle_decrypt.rs:285— ext/crypto/subtle_decrypt.rs:285-315 | ext/crypto/subtle_encrypt.rs:341-371 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (31 lines × 2) ext/node/ops/fs.rs:3242— ext/node/ops/fs.rs:3242-3272 | ext/node/ops/fs.rs:3503-3533 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (31 lines × 2) runtime/web_worker.rs:915— runtime/web_worker.rs:915-945 | runtime/worker.rs:876-906 — before extracting anything, compare `runtime/web_worker.rs` and `runtime/worker.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 83 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (24 lines × 2) cli/lsp/code_lens.rs:542— cli/lsp/code_lens.rs:542-565 | cli/lsp/code_lens.rs:596-619 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (24 lines × 2) cli/tools/installer/local.rs:72— cli/tools/installer/local.rs:72-95 | cli/tools/installer/local.rs:98-121 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (24 lines × 2) libs/http_h1/protocol.rs:380— libs/http_h1/protocol.rs:380-403 | libs/http_h1/write.rs:364-387 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (22–23 lines × 3) cli/tools/lint/ast_buffer/swc.rs:337— cli/tools/lint/ast_buffer/swc.rs:337-359 | cli/tools/lint/ast_buffer/swc.rs:693-714 | cli/tools/lint/ast_buffer/swc.rs:2369-2390 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (22–23 lines × 3) ext/node/ops/fs.rs:1446— ext/node/ops/fs.rs:1446-1468 | ext/node/ops/fs.rs:1643-1665 | ext/node/ops/fs.rs:1814-1835 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (22–23 lines × 3) ext/node/ops/http2/session.rs:2598— ext/node/ops/http2/session.rs:2598-2620 | ext/node/ops/http2/session.rs:2631-2652 | ext/node/ops/http2/session.rs:2663-2685 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (19–20 lines × 2) ext/fs/std_fs.rs:1022— ext/fs/std_fs.rs:1022-1040 | ext/fs/std_fs.rs:1043-1062 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (19–20 lines × 2) ext/net/ops_tls.rs:339— ext/net/ops_tls.rs:339-358 | ext/node/ops/tls.rs:717-735 — before extracting anything, compare `ext/net/ops_tls.rs` and `ext/node/ops/tls.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 42 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (19–20 lines × 2) libs/npm_installer/hoisted.rs:713— libs/npm_installer/hoisted.rs:713-732 | libs/npm_installer/local.rs:1074-1092 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (15 lines × 3) cli/tools/lint/ast_buffer/swc.rs:293— cli/tools/lint/ast_buffer/swc.rs:293-307 | cli/tools/lint/ast_buffer/swc.rs:1038-1052 | cli/tools/lint/ast_buffer/swc.rs:1363-1377 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (15 lines × 3) ext/crypto/export_key.rs:390— ext/crypto/export_key.rs:390-404 | ext/crypto/export_key.rs:408-422 | ext/crypto/export_key.rs:425-439 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (15 lines × 3) ext/node/ops/fs.rs:3351— ext/node/ops/fs.rs:3351-3365 | ext/node/ops/fs.rs:3403-3417 | ext/node/ops/fs.rs:3453-3467 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (14–15 lines × 2) ext/fs/ops.rs:1254— ext/fs/ops.rs:1254-1268 | ext/fs/ops.rs:1300-1313 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14–15 lines × 2) libs/http_h1/write.rs:91— libs/http_h1/write.rs:91-105 | libs/http_h1/write.rs:121-134 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14–15 lines × 2) runtime/cpu_profiler/cpuprof.rs:206— runtime/cpu_profiler/cpuprof.rs:206-220 | runtime/cpu_profiler/cpuprof.rs:381-394 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–14 lines × 3) ext/net/ops_tls.rs:390— ext/net/ops_tls.rs:390-402 | ext/net/ops_tls.rs:533-546 | ext/node/ops/tls.rs:754-766 — before extracting anything, compare `ext/net/ops_tls.rs` and `ext/node/ops/tls.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 42 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (13–14 lines × 3) ext/node/ops/zlib/mod.rs:747— ext/node/ops/zlib/mod.rs:747-760 | ext/node/ops/zlib/mod.rs:1280-1292 | ext/node/ops/zlib/mod.rs:1492-1504 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13–14 lines × 3) ext/web/console/inspect.rs:1300— ext/web/console/inspect.rs:1300-1312 | ext/web/console/inspect.rs:1425-1438 | ext/web/console/inspect.rs:1567-1579 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13 lines × 3) ext/node/ops/tls_wrap.rs:4922— ext/node/ops/tls_wrap.rs:4922-4934 | ext/node/ops/tls_wrap.rs:5447-5459 | ext/node/ops/tls_wrap.rs:5490-5502 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13 lines × 3) ext/node_sqlite/database.rs:2367— ext/node_sqlite/database.rs:2367-2379 | ext/node_sqlite/database.rs:2473-2485 | ext/node_sqlite/database.rs:2675-2687 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13 lines × 3) libs/ops/conversion/from_v8/enum.rs:175— libs/ops/conversion/from_v8/enum.rs:175-187 | libs/ops/conversion/to_v8/enum.rs:345-357 | libs/ops/conversion/to_v8/enum.rs:361-373 — `libs/ops/conversion/from_v8/enum.rs` and `libs/ops/conversion/to_v8/enum.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 4 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
Duplicated block (10–12 lines × 2) ext/napi/js_native_api.rs:3884— ext/napi/js_native_api.rs:3884-3893 | ext/napi/node_api.rs:633-644 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10–12 lines × 2) ext/node/ops/v8.rs:1027— ext/node/ops/v8.rs:1027-1038 | ext/node/ops/v8.rs:1053-1062 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10–12 lines × 2) REDACTED:1488— REDACTED:1488-1497 | REDACTED:1836-1847 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (11 lines × 4) cli/lsp/tsc.rs:651— cli/lsp/tsc.rs:651-661 | cli/lsp/tsc.rs:1053-1063 | cli/lsp/tsc.rs:1186-1196 | cli/lsp/tsc.rs:1357-1367 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 4) cli/tools/publish/unfurl.rs:190— cli/tools/publish/unfurl.rs:190-200 | cli/tools/publish/unfurl.rs:205-215 | cli/tools/publish/unfurl.rs:220-230 | cli/tools/publish/unfurl.rs:235-245 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11 lines × 4) ext/node/ops/stream_wrap.rs:1399— ext/node/ops/stream_wrap.rs:1399-1409 | ext/node/ops/stream_wrap.rs:1686-1696 | ext/node/ops/stream_wrap.rs:1870-1880 | ext/node/ops/tls_wrap.rs:2129-2139 — before extracting anything, compare `ext/node/ops/stream_wrap.rs` and `ext/node/ops/tls_wrap.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9–10 lines × 3) ext/crypto/digest.rs:458— ext/crypto/digest.rs:458-466 | ext/crypto/subtle_decrypt.rs:336-345 | ext/crypto/subtle_encrypt.rs:392-401 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_decrypt.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9–10 lines × 3) ext/napi/js_native_api.rs:657— ext/napi/js_native_api.rs:657-665 | ext/napi/js_native_api.rs:687-696 | ext/napi/js_native_api.rs:717-725 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9–10 lines × 3) ext/node/ops/vm.rs:1092— ext/node/ops/vm.rs:1092-1100 | ext/node/ops/vm.rs:1202-1211 | ext/node/ops/vm.rs:1359-1368 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 5) ext/crypto/node_interop.rs:338— ext/crypto/node_interop.rs:338-346 | ext/crypto/node_interop.rs:355-363 | ext/crypto/subtle_crypto.rs:841-849 | ext/crypto/subtle_generate_key.rs:783-791 | ext/crypto/subtle_import_key.rs:1927-1935 — before extracting anything, compare `ext/crypto/node_interop.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9 lines × 5) REDACTED:700— REDACTED:700-708 | REDACTED:856-864 | REDACTED:912-920 | REDACTED:1311-1319 | REDACTED:1349-1357 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 5) libs/config/deno_json/mod.rs:2207— libs/config/deno_json/mod.rs:2207-2216 | libs/config/deno_json/mod.rs:2310-2318 | libs/config/deno_json/mod.rs:2338-2346 | libs/config/deno_json/mod.rs:2369-2378 | libs/config/deno_json/mod.rs:2612-2621 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 5) cli/lsp/diagnostics.rs:818— cli/lsp/diagnostics.rs:818-823 | cli/lsp/diagnostics.rs:835-840 | cli/lsp/diagnostics.rs:886-891 | cli/lsp/diagnostics.rs:912-917 | cli/lsp/diagnostics.rs:938-943 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 5) ext/net/ops.rs:303— ext/net/ops.rs:303-308 | ext/net/ops.rs:385-390 | ext/net/ops.rs:418-423 | ext/net/ops.rs:450-455 | ext/net/ops.rs:472-477 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 5) ext/crypto/crypto_key.rs:183— ext/crypto/crypto_key.rs:183-188 | ext/crypto/crypto_key.rs:253-258 | ext/crypto/subtle_generate_key.rs:865-870 | ext/crypto/subtle_import_key.rs:1998-2003 | ext/crypto/subtle_key.rs:185-190 — before extracting anything, compare `ext/crypto/subtle_generate_key.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 118 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (5 lines × 6) ext/crypto/subtle_import_key.rs:758— ext/crypto/subtle_import_key.rs:758-762 | ext/crypto/subtle_import_key.rs:768-772 | ext/crypto/subtle_import_key.rs:884-888 | ext/crypto/subtle_import_key.rs:894-898 | ext/crypto/subtle_import_key.rs:997-1001 | ext/crypto/subtle_import_key.rs:1007-1011 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 6) ext/node_crypto/cipher.rs:1010— ext/node_crypto/cipher.rs:1010-1014 | ext/node_crypto/cipher.rs:1016-1020 | ext/node_crypto/cipher.rs:1022-1026 | ext/node_crypto/cipher.rs:1028-1032 | ext/node_crypto/cipher.rs:1042-1046 | ext/node_crypto/cipher.rs:1057-1061 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 6) ext/node_crypto/cipher.rs:1496— ext/node_crypto/cipher.rs:1496-1500 | ext/node_crypto/cipher.rs:1502-1506 | ext/node_crypto/cipher.rs:1508-1512 | ext/node_crypto/cipher.rs:1514-1518 | ext/node_crypto/cipher.rs:1528-1532 | ext/node_crypto/cipher.rs:1543-1547 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 5) ext/crypto/digest.rs:407— ext/crypto/digest.rs:407-411 | ext/crypto/digest.rs:495-499 | ext/crypto/subtle_decrypt.rs:284-288 | ext/crypto/subtle_encrypt.rs:340-344 | ext/crypto/subtle_sign.rs:343-347 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_decrypt.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (5 lines × 5) ext/webgpu/adapter.rs:220— ext/webgpu/adapter.rs:220-224 | runtime/ops/desktop.rs:838-842 | runtime/ops/desktop.rs:1866-1870 | runtime/ops/desktop.rs:1934-1938 | runtime/ops/desktop.rs:2099-2103 — there are 5 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 5 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (5 lines × 5) ext/node/ops/http2/stream.rs:425— ext/node/ops/http2/stream.rs:425-429 | ext/node/ops/tls_wrap.rs:559-563 | ext/node/ops/tls_wrap.rs:592-597 | ext/node/ops/tls_wrap.rs:627-631 | ext/node/ops/tls_wrap.rs:859-863 — there are 5 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 5 sites; resolving a subset leaves the remainder to drift apart.
DenoCompileBinaryWriter::write_standalone_binary (cyclomatic 59) cli/standalone/binary.rs:634— DenoCompileBinaryWriter::write_standalone_binary has cyclomatic complexity 59 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DenoCompileBinaryWriter::build_vfs_consolidating_global_npm_cache (cyclomatic 17) cli/standalone/binary.rs:1491— DenoCompileBinaryWriter::build_vfs_consolidating_global_npm_cache has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
JsRuntime::poll_event_loop_inner (cyclomatic 52) libs/core/runtime/jsruntime.rs:2436— JsRuntime::poll_event_loop_inner has cyclomatic complexity 52 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
JsRuntime::new_inner (cyclomatic 18) libs/core/runtime/jsruntime.rs:815— JsRuntime::new_inner has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
PackumentIndexer::on_string (cyclomatic 49) libs/npm/fast_registry_json.rs:1053— PackumentIndexer::on_string has cyclomatic complexity 49 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
PackumentIndexer::on_operator (cyclomatic 17) libs/npm/fast_registry_json.rs:1180— PackumentIndexer::on_operator has cyclomatic complexity 17 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
Cipher::new (cyclomatic 46) ext/node_crypto/cipher.rs:826— Cipher::new has cyclomatic complexity 46 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (Decipher::new) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Cipher::encrypt (cyclomatic 19) ext/node_crypto/cipher.rs:1006— Cipher::encrypt has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing. This shape REPEATS in the file: one other method here (Decipher::decrypt) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_process::create_command (cyclomatic 42) ext/process/lib.rs:685— deno_process::create_command has cyclomatic complexity 42 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_process::op_spawn_sync (cyclomatic 27) ext/process/lib.rs:1690— deno_process::op_spawn_sync has cyclomatic complexity 27 (threshold 15). Of this number, 20 points are the body's own statements and 7 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
EszipV2::parse_with_version (cyclomatic 37) libs/eszip/v2.rs:734— EszipV2::parse_with_version has cyclomatic complexity 37 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
EszipV2::from_graph::visit_module (cyclomatic 19) libs/eszip/v2.rs:1349— EszipV2::from_graph::visit_module has cyclomatic complexity 19 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
WorkspaceResolver::resolve (cyclomatic 34) libs/resolver/workspace.rs:1354— WorkspaceResolver::resolve has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
WorkspaceResolver::from_workspace (cyclomatic 25) libs/resolver/workspace.rs:856— WorkspaceResolver::from_workspace has cyclomatic complexity 25 (threshold 15). Most of this is not in the body itself: 1 of the 25 points is its own statement and the rest belongs to 4 function items inside it that branch (resolve_import_map, resolve_import_map::expand_catalog_specifiers::expand_entries, resolve_import_map::expand_catalog_specifiers, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
jupyter_kernel.startJupyterKernel::checkIsComplete (cyclomatic 30) cli/js/jupyter_kernel.js:624— jupyter_kernel.startJupyterKernel::checkIsComplete has cyclomatic complexity 30 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (jupyter_kernel.startJupyterKernel::handleExecute) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
jupyter_kernel.startJupyterKernel::handleExecute (cyclomatic 24) cli/js/jupyter_kernel.js:682— jupyter_kernel.startJupyterKernel::handleExecute has cyclomatic complexity 24 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (jupyter_kernel.startJupyterKernel::checkIsComplete) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_lockfile::transforms::transform3_to_4 (cyclomatic 28) libs/lockfile/transforms.rs:83— deno_lockfile::transforms::transform3_to_4 has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_lockfile::transforms::transform4_to_5 (cyclomatic 21) libs/lockfile/transforms.rs:239— deno_lockfile::transforms::transform4_to_5 has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ByonmNpmResolver::resolve_pkg_json_and_alias_for_req (cyclomatic 27) libs/resolver/npm/byonm.rs:213— ByonmNpmResolver::resolve_pkg_json_and_alias_for_req has cyclomatic complexity 27 (threshold 15). Of this number, 17 points are the body's own statements and 10 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ByonmNpmResolver::resolve_folder_in_root_node_modules (cyclomatic 17) libs/resolver/npm/byonm.rs:347— ByonmNpmResolver::resolve_folder_in_root_node_modules has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ModuleMap::new_module_from_js_source_with_pending (cyclomatic 22) libs/core/modules/map.rs:819— ModuleMap::new_module_from_js_source_with_pending has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ModuleMap::drain_dyn_imports (cyclomatic 16) libs/core/modules/map/dynamic.rs:511— ModuleMap::drain_dyn_imports has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
SpecifierUnfurler::unfurl_specifier (cyclomatic 20) cli/tools/publish/unfurl.rs:421— SpecifierUnfurler::unfurl_specifier has cyclomatic complexity 20 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
SpecifierUnfurler::unfurl_to_changes (cyclomatic 19) cli/tools/publish/unfurl.rs:905— SpecifierUnfurler::unfurl_to_changes has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_fetch::op_fetch (cyclomatic 20) ext/fetch/lib.rs:436— deno_fetch::op_fetch has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_fetch::create_http_client (cyclomatic 17) ext/fetch/lib.rs:1045— deno_fetch::create_http_client has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
TLSWrapInner::clear_out_process (cyclomatic 20) ext/node/ops/tls_wrap.rs:1516— TLSWrapInner::clear_out_process has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_node::ops::tls_wrap::rustls_error_to_node_error (cyclomatic 26) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
TLSWrapInner::dispatch_clear_out_callbacks (cyclomatic 18) ext/node/ops/tls_wrap.rs:1708— TLSWrapInner::dispatch_clear_out_callbacks has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_node::ops::tls_wrap::rustls_error_to_node_error (cyclomatic 26) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
DatabaseSync::function (cyclomatic 20) ext/node_sqlite/database.rs:1212— DatabaseSync::function has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DatabaseSync::deserialize (cyclomatic 18) ext/node_sqlite/database.rs:2129— DatabaseSync::deserialize has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
CliModuleLoader::prepare_load (cyclomatic 19) cli/module_loader.rs:1611— CliModuleLoader::prepare_load has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
CliModuleLoader::load (cyclomatic 16) cli/module_loader.rs:1428— CliModuleLoader::load has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DepManager::run_dependency_resolution (cyclomatic 18) cli/tools/pm/deps.rs:723— DepManager::run_dependency_resolution has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DepManager::commit_changes (cyclomatic 17) cli/tools/pm/deps.rs:1088— DepManager::commit_changes has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DesktopHmrRunner::handle_change (cyclomatic 18) cli/rt/hmr.rs:471— DesktopHmrRunner::handle_change has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DesktopHmrRunner::run (cyclomatic 16) cli/rt/hmr.rs:398— DesktopHmrRunner::run has cyclomatic complexity 16 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
deno_telemetry::op_otel_metric_record3 (cyclomatic 17) ext/telemetry/lib.rs:3010— deno_telemetry::op_otel_metric_record3 has cyclomatic complexity 17 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
deno_telemetry::console_exporter::format_span (cyclomatic 16) ext/telemetry/console_exporter.rs:55— deno_telemetry::console_exporter::format_span has cyclomatic complexity 16 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
XxxComment ext/node/polyfills/net.ts:1211— // XXX it would be great if we could cancel the promise returned by — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
XxxComment ext/node/polyfills/net.ts:1285— // XXX it would be great if we could cancel the promise returned by — source code is not a task system: move the work to your tracker and leave a reference instead (e.g. `// REF: #123`), so the task is planned where tasks live and the ticket links back to the code.
deno_dotenv::parse_env_content_hook_impl (cognitive 104) libs/dotenv/lib.rs:151— deno_dotenv::parse_env_content_hook_impl has cognitive complexity 104 (threshold 15). Drivers by points: if/else 36 (80 pts), loops 6 (14 pts), boolean chains 8, match/switch 1 (2 pts) (nesting depth added 53). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_dotenv::apply_value_substitution (cognitive 32) libs/dotenv/lib.rs:419— deno_dotenv::apply_value_substitution has cognitive complexity 32 (threshold 15). Drivers by points: if/else 9 (23 pts), loops 3 (8 pts), boolean chains 1 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
JsRuntime::poll_event_loop_inner (cognitive 87) libs/core/runtime/jsruntime.rs:2436— JsRuntime::poll_event_loop_inner has cognitive complexity 87 (threshold 15). Drivers by points: if/else 41 (72 pts), boolean chains 11, loops 2, match/switch 1 (2 pts) (nesting depth added 32). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
JsRuntime::new_inner (cognitive 21) libs/core/runtime/jsruntime.rs:815— JsRuntime::new_inner has cognitive complexity 21 (threshold 15). Drivers by points: if/else 16 (17 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 2). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
denort_desktop::run_desktop (cognitive 70) cli/rt_desktop/lib.rs:1695— denort_desktop::run_desktop has cognitive complexity 70 (threshold 15). Drivers by points: if/else 22 (51 pts), boolean chains 7, loops 3 (6 pts), match/switch 4 (6 pts) (nesting depth added 34). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
denort_desktop::v8_to_laufey_value (cognitive 28) cli/rt_desktop/lib.rs:976— denort_desktop::v8_to_laufey_value has cognitive complexity 28 (threshold 15). Drivers by points: if/else 13 (23 pts), loops 2 (5 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CompletionEntry::as_completion_item (cognitive 63) cli/lsp/tsc.rs:4422— CompletionEntry::as_completion_item has cognitive complexity 63 (threshold 15). Drivers by points: if/else 26 (54 pts), boolean chains 5, loops 1 (3 pts), match/switch 1 (nesting depth added 30). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
CompletionEntry::get_filter_text (cognitive 33) cli/lsp/tsc.rs:4367— CompletionEntry::get_filter_text has cognitive complexity 33 (threshold 15). Drivers by points: if/else 12 (28 pts), loops 1 (4 pts), boolean chains 1 (nesting depth added 19). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
deno_npm::fast_registry_json::pluck_versions_from_tokens (cognitive 63) libs/npm/fast_registry_json.rs:796— deno_npm::fast_registry_json::pluck_versions_from_tokens has cognitive complexity 63 (threshold 15). Drivers by points: if/else 20 (52 pts), boolean chains 8, match/switch 1 (2 pts), loops 1 (nesting depth added 33). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
deno_npm::resolution::graph::tarjan_scc::strongconnect (cognitive 21) libs/npm/resolution/graph.rs:315— deno_npm::resolution::graph::tarjan_scc::strongconnect has cognitive complexity 21 (threshold 15). Drivers by points: if/else 7 (17 pts), loops 2 (4 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
PackumentIndexer::on_string (cognitive 61) libs/npm/fast_registry_json.rs:1053— PackumentIndexer::on_string has cognitive complexity 61 (threshold 15). Drivers by points: if/else 28 (41 pts), boolean chains 16, match/switch 2 (4 pts) (nesting depth added 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
PackumentIndexer::on_operator (cognitive 26) libs/npm/fast_registry_json.rs:1180— PackumentIndexer::on_operator has cognitive complexity 26 (threshold 15). Drivers by points: if/else 13 (21 pts), match/switch 1 (3 pts), boolean chains 2 (nesting depth added 10). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
Decipher::new (cognitive 59) ext/node_crypto/cipher.rs:1282— Decipher::new has cognitive complexity 59 (threshold 15). Drivers by points: if/else 29 (54 pts), match/switch 2 (3 pts), boolean chains 2 (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (Cipher::new) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
Decipher::r#final (cognitive 32) ext/node_crypto/cipher.rs:1558— Decipher::r#final has cognitive complexity 32 (threshold 15). Drivers by points: if/else 18 (30 pts), boolean chains 1, match/switch 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
jupyter_kernel.startJupyterKernel::checkIsComplete (cognitive 59) cli/js/jupyter_kernel.js:624— jupyter_kernel.startJupyterKernel::checkIsComplete has cognitive complexity 59 (threshold 15). Drivers by points: if/else 16 (42 pts), loops 4 (10 pts), boolean chains 7 (nesting depth added 32). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (jupyter_kernel.startJupyterKernel::handleExecute) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
jupyter_kernel.startJupyterKernel::handleExecute (cognitive 41) cli/js/jupyter_kernel.js:682— jupyter_kernel.startJupyterKernel::handleExecute has cognitive complexity 41 (threshold 15). Drivers by points: if/else 9 (17 pts), boolean chains 14, error handling 2 (6 pts), ternaries 1 (4 pts) (nesting depth added 15). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function. This shape REPEATS in the file: one other method here (jupyter_kernel.startJupyterKernel::checkIsComplete) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
StatementSync::bind_params (cognitive 54) ext/node_sqlite/statement.rs:495— StatementSync::bind_params has cognitive complexity 54 (threshold 15). Drivers by points: if/else 10 (40 pts), loops 4 (12 pts), boolean chains 2 (nesting depth added 38). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
StatementSync::columns (cognitive 16) ext/node_sqlite/statement.rs:1065— StatementSync::columns has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10 (15 pts), loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrapInner::clear_out_process (cognitive 40) ext/node/ops/tls_wrap.rs:1516— TLSWrapInner::clear_out_process has cognitive complexity 40 (threshold 15). Drivers by points: if/else 9 (23 pts), match/switch 3 (10 pts), loops 2 (5 pts), boolean chains 2 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSWrapInner::dispatch_clear_out_callbacks (cognitive 29) ext/node/ops/tls_wrap.rs:1708— TLSWrapInner::dispatch_clear_out_callbacks has cognitive complexity 29 (threshold 15). Drivers by points: if/else 17 (28 pts), boolean chains 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Graph::compute_all_npm_pkg_ids (cognitive 36) libs/npm/resolution/graph.rs:541— Graph::compute_all_npm_pkg_ids has cognitive complexity 36 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 8 (13 pts), boolean chains 5, match/switch 1 (3 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Graph::resolve_packages_for_snapshot_with_maybe_restart (cognitive 16) libs/npm/resolution/graph.rs:820— Graph::resolve_packages_for_snapshot_with_maybe_restart has cognitive complexity 16 (threshold 15). Drivers by points: if/else 3 (8 pts), loops 4 (5 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DesktopHmrRunner::run (cognitive 35) cli/rt/hmr.rs:398— DesktopHmrRunner::run has cognitive complexity 35 (threshold 15). Drivers by points: if/else 4 (13 pts), loops 4 (10 pts), match/switch 3 (10 pts), boolean chains 2 (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DesktopHmrRunner::handle_change (cognitive 23) cli/rt/hmr.rs:471— DesktopHmrRunner::handle_change has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (14 pts), match/switch 5 (7 pts), boolean chains 1, loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmPackageVersionResolver::strongest_trust_evidence_before (cognitive 35) libs/npm/resolution/common.rs:322— NpmPackageVersionResolver::strongest_trust_evidence_before has cognitive complexity 35 (threshold 15). Drivers by points: if/else 12 (30 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmPackageVersionResolver::resolve_best_package_version_info (cognitive 16) libs/npm/resolution/common.rs:419— NpmPackageVersionResolver::resolve_best_package_version_info has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (12 pts), loops 1 (2 pts), match/switch 1 (2 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleGraphBuilder::build_graph_with_npm_resolution_and_build_options (cognitive 34) cli/graph_util.rs:1003— ModuleGraphBuilder::build_graph_with_npm_resolution_and_build_options has cognitive complexity 34 (threshold 15). Drivers by points: if/else 11 (18 pts), loops 3 (9 pts), boolean chains 6, match/switch 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleGraphBuilder::npm_peer_dep_importers (cognitive 23) cli/graph_util.rs:1121— ModuleGraphBuilder::npm_peer_dep_importers has cognitive complexity 23 (threshold 15). Drivers by points: if/else 5 (17 pts), loops 3 (6 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_fetch::op_fetch (cognitive 34) ext/fetch/lib.rs:436— deno_fetch::op_fetch has cognitive complexity 34 (threshold 15). Drivers by points: if/else 10 (19 pts), match/switch 4 (10 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_fetch::proxy::tunnel (cognitive 19) ext/fetch/proxy.rs:761— deno_fetch::proxy::tunnel has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (14 pts), match/switch 2 (3 pts), boolean chains 1, loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TestRun::exec (cognitive 32) cli/lsp/testing/execution.rs:235— TestRun::exec has cognitive complexity 32 (threshold 15). Drivers by points: if/else 11 (17 pts), match/switch 3 (10 pts), loops 3 (5 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TestRun::get_args (cognitive 16) cli/lsp/testing/execution.rs:528— TestRun::get_args has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (9 pts), boolean chains 4, loops 2 (3 pts) (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RuntimeActivityStats::diff (cognitive 32) libs/core/runtime/stats.rs:418— RuntimeActivityStats::diff has cognitive complexity 32 (threshold 15). Drivers by points: if/else 13 (23 pts), loops 9 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RuntimeActivityStats::dump (cognitive 21) libs/core/runtime/stats.rs:359— RuntimeActivityStats::dump has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (12 pts), loops 5 (9 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CjsModuleExportAnalyzer::resolve (cognitive 30) libs/node_resolver/analyze.rs:517— CjsModuleExportAnalyzer::resolve has cognitive complexity 30 (threshold 15). Drivers by points: if/else 15 (26 pts), boolean chains 2, loops 1, match/switch 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CjsModuleExportAnalyzer::analyze_reexports (cognitive 20) libs/node_resolver/analyze.rs:355— CjsModuleExportAnalyzer::analyze_reexports has cognitive complexity 20 (threshold 15). Drivers by points: if/else 4 (12 pts), match/switch 3 (6 pts), loops 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TaskRunner::run_tasks_in_parallel (cognitive 29) cli/tools/task.rs:483— TaskRunner::run_tasks_in_parallel has cognitive complexity 29 (threshold 15). Drivers by points: if/else 10 (17 pts), loops 4 (5 pts), match/switch 2 (5 pts), boolean chains 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TaskRunner::run_all_tasks (cognitive 22) cli/tools/task.rs:421— TaskRunner::run_all_tasks has cognitive complexity 22 (threshold 15). Drivers by points: if/else 7 (17 pts), match/switch 1 (3 pts), boolean chains 1, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(computed) (cognitive 29) ext/websocket/01_websocket.js:754— (computed) has cognitive complexity 29 (threshold 15). Drivers by points: if/else 7 (18 pts), error handling 1 (4 pts), ternaries 1 (3 pts), match/switch 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(computed) (cognitive 29) ext/node/polyfills/internal/event_target.mjs:716— (computed) has cognitive complexity 29 (threshold 15). Drivers by points: if/else 12 (20 pts), boolean chains 4, error handling 1 (2 pts), ternaries 1 (2 pts), loops 1 (nesting depth added 10). Of this number, 28 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CliModuleLoader::prepare_load (cognitive 28) cli/module_loader.rs:1611— CliModuleLoader::prepare_load has cognitive complexity 28 (threshold 15). Drivers by points: if/else 17 (23 pts), boolean chains 5 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CliModuleLoader::load (cognitive 20) cli/module_loader.rs:1428— CliModuleLoader::load has cognitive complexity 20 (threshold 15). Drivers by points: if/else 8 (12 pts), boolean chains 4, match/switch 2 (4 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ConfigFile::to_exports_config (cognitive 25) libs/config/deno_json/mod.rs:2022— ConfigFile::to_exports_config has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (17 pts), match/switch 2 (4 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 6). Most of this is not in the body itself: 6 of the 25 points are its own statements and the rest belongs to 2 function items inside it that branch (validate_key, validate_value). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
ConfigFile::dependencies (cognitive 22) libs/config/deno_json/mod.rs:2766— ConfigFile::dependencies has cognitive complexity 22 (threshold 15). Drivers by points: if/else 9 (16 pts), boolean chains 3, loops 1 (3 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
IsCjsResolver::check_based_on_pkg_json (cognitive 25) libs/resolver/cjs/mod.rs:311— IsCjsResolver::check_based_on_pkg_json has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (22 pts), boolean chains 3 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
IsCjsResolver::get_known_mode_with_is_script (cognitive 19) libs/resolver/cjs/mod.rs:245— IsCjsResolver::get_known_mode_with_is_script has cognitive complexity 19 (threshold 15). Drivers by points: if/else 10 (17 pts), boolean chains 1, match/switch 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DocumentModules::workspace_file_modules_by_scope (cognitive 23) cli/lsp/documents.rs:1556— DocumentModules::workspace_file_modules_by_scope has cognitive complexity 23 (threshold 15). Drivers by points: if/else 8 (16 pts), boolean chains 4, loops 3 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DocumentModules::resolve (cognitive 19) cli/lsp/documents.rs:1851— DocumentModules::resolve has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (13 pts), match/switch 2 (5 pts), loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
VfsBuilder::ensure_canonical_dir_inner (cognitive 23) cli/lib/standalone/virtual_fs.rs:836— VfsBuilder::ensure_canonical_dir_inner has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (20 pts), match/switch 1 (2 pts), loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
VfsBuilder::build (cognitive 17) cli/lib/standalone/virtual_fs.rs:1254— VfsBuilder::build has cognitive complexity 17 (threshold 15). Drivers by points: if/else 4 (8 pts), match/switch 3 (7 pts), loops 2 (nesting depth added 8). Of this number, 14 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmOverrides::get_override_for (cognitive 21) libs/npm/resolution/overrides.rs:197— NpmOverrides::get_override_for has cognitive complexity 21 (threshold 15). Drivers by points: if/else 3 (10 pts), match/switch 3 (8 pts), boolean chains 2, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmOverrides::for_child (cognitive 19) libs/npm/resolution/overrides.rs:134— NpmOverrides::for_child has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (12 pts), boolean chains 3, match/switch 1 (3 pts), loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
primary.init::createWorkerProcess (cognitive 19) ext/node/polyfills/internal/cluster/primary.ts:128— primary.init::createWorkerProcess has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (11 pts), ternaries 2 (7 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (primary.init::queryServer) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
primary.init::queryServer (cognitive 16) ext/node/polyfills/internal/cluster/primary.ts:310— primary.init::queryServer has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 3 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (primary.init::createWorkerProcess) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
DenoTaskLifeCycleScriptsExecutor::resolve_custom_commands_from_packages (cognitive 18) cli/npm.rs:776— DenoTaskLifeCycleScriptsExecutor::resolve_custom_commands_from_packages has cognitive complexity 18 (threshold 15). Drivers by points: if/else 4 (8 pts), match/switch 3 (8 pts), loops 2 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoTaskLifeCycleScriptsExecutor::run_single_package_scripts (cognitive 17) cli/npm.rs:605— DenoTaskLifeCycleScriptsExecutor::run_single_package_scripts has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (13 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_image::bitmap::parse_args (cognitive 18) ext/image/bitmap.rs:283— deno_image::bitmap::parse_args has cognitive complexity 18 (threshold 15). Drivers by points: if/else 12, match/switch 6. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_image::bitmap::op_create_image_bitmap (cognitive 16) ext/image/bitmap.rs:371— deno_image::bitmap::op_create_image_bitmap has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10, match/switch 4 (5 pts), boolean chains 1 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_http_h1::write::write_response_head_inner (cognitive 17) libs/http_h1/write.rs:213— deno_http_h1::write::write_response_head_inner has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 5, loops 1 (nesting depth added 3). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_http_h1::write::write_response_head_to_inner) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
deno_http_h1::write::write_response_head_to_inner (cognitive 17) libs/http_h1/write.rs:282— deno_http_h1::write::write_response_head_to_inner has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 5, loops 1 (nesting depth added 3). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (deno_http_h1::write::write_response_head_inner) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
(computed) (cognitive 17) ext/node/polyfills/internal/readline/interface.mjs:710— (computed) has cognitive complexity 17 (threshold 15). Drivers by points: if/else 10 (12 pts), boolean chains 4, loops 1 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
(computed) (cognitive 17) ext/websocket/01_websocket.js:912— (computed) has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (17 pts) (nesting depth added 9). Most of this is not in the body itself: 3 of the 17 points are its own statements and the rest belongs to 4 function literals inside it that branch (lines 918, 922, 920, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
ConfigData::load (cognitive 16) cli/lsp/config.rs:1443— ConfigData::load has cognitive complexity 16 (threshold 15). Drivers by points: if/else 3 (10 pts), match/switch 3 (4 pts), loops 1 (2 pts) (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
ConfigData::load_inner (cognitive 16) cli/lsp/config.rs:1550— ConfigData::load_inner has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10, boolean chains 3, match/switch 2 (3 pts) (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Change-coupling hub: lib.rs → _next_tick.ts, promises.ts, tty.js, mod.ts ext/node/lib.rs— `ext/node/lib.rs` changes together with 4 other files — `ext/node/polyfills/_next_tick.ts`, `ext/node/polyfills/internal/fs/promises.ts`, `ext/node/polyfills/internal/tty.js`, `ext/node/polyfills/internal_binding/mod.ts` — none of which declares a dependency on it: one file is the hub of 4 separate couplings, not 4 unrelated pairs. Read the hub first: if the others each duplicate a part of what it does, the shared concern belongs in ONE unit and extracting it clears every edge at once; if the hub is a registry, dispatcher or barrel that must name each of them, the coupling is structural and the question is whether that list can be discovered instead of enumerated. Fixing the hub is one change; breaking the couplings one pair at a time is 4.
Change-coupling hub: worker.rs → js.rs, snapshot.rs, snapshot_info.rs runtime/worker.rs— `runtime/worker.rs` changes together with 3 other files — `runtime/js.rs`, `runtime/snapshot.rs`, `runtime/snapshot_info.rs` — none of which declares a dependency on it: one file is the hub of 3 separate couplings, not 3 unrelated pairs. Read the hub first: if the others each duplicate a part of what it does, the shared concern belongs in ONE unit and extracting it clears every edge at once; if the hub is a registry, dispatcher or barrel that must name each of them, the coupling is structural and the question is whether that list can be discovered instead of enumerated. Fixing the hub is one change; breaking the couplings one pair at a time is 3.
Near-duplicate member pair (50 shared lines) cli/tools/desktop.rs:1626— cli/tools/desktop.rs:1626-1731 | cli/tools/desktop.rs:1753-1900 — These two members are variants of one another: 50 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (50 shared lines) ext/http/http_next.rs:4194— ext/http/http_next.rs:4194-4336 | ext/http/http_next.rs:4347-4530 — These two members are variants of one another: 50 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
D4 · Code Duplication· Members sharing a duplicated core (8 members, 50+ identical tokens) · ×2
Members sharing a duplicated core (8 members, 50+ identical tokens) ext/crypto/digest.rs:339— ext/crypto/digest.rs:339-358 | ext/crypto/subtle_decrypt.rs:239-252 | ext/crypto/subtle_decrypt.rs:372-393 | ext/crypto/subtle_derive_bits.rs:275-311 | ext/crypto/subtle_encrypt.rs:294-307 | ext/crypto/subtle_encrypt.rs:428-449 | ext/crypto/subtle_sign.rs:238-270 | ext/crypto/subtle_sign.rs:286-322 — These 8 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 8 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 8 times.
Members sharing a duplicated core (8 members, 50+ identical tokens) ext/node/ops/http2/session.rs:905— ext/node/ops/http2/session.rs:905-987 | ext/node/ops/http2/session.rs:1009-1027 | ext/node/ops/http2/session.rs:1033-1069 | ext/node/ops/http2/session.rs:1076-1095 | ext/node/ops/http2/session.rs:1097-1153 | ext/node/ops/http2/session.rs:1155-1192 | ext/node/ops/http2/session.rs:1194-1239 | ext/node/ops/http2/session.rs:1241-1285 — These 8 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 8 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 8 times.
D4 · Code Duplication· Members sharing a duplicated core (6 members, 50+ identical tokens) · ×2
Members sharing a duplicated core (6 members, 50+ identical tokens) ext/fs/ops.rs:284— ext/fs/ops.rs:284-304 | ext/fs/ops.rs:350-366 | ext/fs/ops.rs:374-390 | ext/fs/ops.rs:418-434 | ext/fs/ops.rs:1065-1083 | ext/fs/ops.rs:1117-1141 — These 6 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 6 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 6 times.
Members sharing a duplicated core (6 members, 50+ identical tokens) ext/napi/js_native_api.rs:1259— ext/napi/js_native_api.rs:1259-1298 | ext/napi/js_native_api.rs:1306-1345 | ext/napi/js_native_api.rs:1353-1396 | ext/napi/js_native_api.rs:1843-1886 | ext/napi/js_native_api.rs:1894-1933 | ext/napi/js_native_api.rs:1941-1985 — These 6 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 6 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 6 times.
Duplicated block (37 lines × 2) ext/node/ops/fs.rs:2586— ext/node/ops/fs.rs:2586-2622 | ext/node/ops/fs.rs:2681-2717 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (37 lines × 2) libs/dcore/src/inspector_server.rs:195— libs/dcore/src/inspector_server.rs:195-231 | libs/inspector_server/lib.rs:424-460 — before extracting anything, compare `libs/dcore/src/inspector_server.rs` and `libs/inspector_server/lib.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 128 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (30–31 lines × 2) ext/net/ops_tls.rs:385— ext/net/ops_tls.rs:385-414 | ext/net/ops_tls.rs:528-558 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (30–31 lines × 2) ext/node_sqlite/database.rs:2359— ext/node_sqlite/database.rs:2359-2389 | ext/node_sqlite/database.rs:2466-2495 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (29–30 lines × 2) ext/node_sqlite/database.rs:788— ext/node_sqlite/database.rs:788-816 | ext/node_sqlite/database.rs:837-866 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (29–30 lines × 2) libs/eszip/v2.rs:931— libs/eszip/v2.rs:931-960 | libs/eszip/v2.rs:972-1000 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (28 lines × 2) cli/lsp/registries.rs:1086— cli/lsp/registries.rs:1086-1113 | cli/lsp/registries.rs:1125-1152 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (28 lines × 2) cli/tools/lint/ast_buffer/swc.rs:287— cli/tools/lint/ast_buffer/swc.rs:287-314 | cli/tools/lint/ast_buffer/swc.rs:1357-1384 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (27 lines × 2) ext/http/http_next.rs:5186— ext/http/http_next.rs:5186-5212 | ext/http/http_next.rs:5264-5290 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (27 lines × 2) ext/node_crypto/x509.rs:742— ext/node_crypto/x509.rs:742-768 | ext/node_crypto/x509.rs:1304-1330 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22–25 lines × 2) cli/tools/bundle/mod.rs:638— cli/tools/bundle/mod.rs:638-662 | cli/tools/bundle/mod.rs:801-822 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22–25 lines × 2) libs/core/uv_compat/tty.rs:1765— libs/core/uv_compat/tty.rs:1765-1789 | libs/core/uv_compat/tty.rs:1994-2015 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23–24 lines × 2) ext/node/ops/stream_wrap.rs:1466— ext/node/ops/stream_wrap.rs:1466-1488 | ext/node/ops/stream_wrap.rs:1946-1969 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (23–24 lines × 2) libs/node_resolver/analyze.rs:295— libs/node_resolver/analyze.rs:295-318 | libs/node_resolver/analyze.rs:391-413 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18–23 lines × 2) ext/node/ops/fs.rs:96— ext/node/ops/fs.rs:96-118 | ext/node/ops/wasi.rs:2377-2394 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (18–23 lines × 2) ext/node/ops/zlib/mod.rs:475— ext/node/ops/zlib/mod.rs:475-492 | ext/node/ops/zlib/mod.rs:509-531 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–20 lines × 2) ext/node/ops/inspector.rs:358— ext/node/ops/inspector.rs:358-377 | ext/node/ops/inspector.rs:415-429 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–20 lines × 2) ext/node/ops/llhttp/binding.rs:809— ext/node/ops/llhttp/binding.rs:809-823 | ext/node/ops/llhttp/binding.rs:968-987 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (18 lines × 3) cli/tools/fmt.rs:1330— cli/tools/fmt.rs:1330-1347 | cli/tools/fmt.rs:1527-1544 | cli/tools/fmt.rs:1580-1597 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (18 lines × 3) ext/telemetry/lib.rs:2436— ext/telemetry/lib.rs:2436-2453 | ext/telemetry/lib.rs:2467-2484 | ext/telemetry/lib.rs:2512-2529 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (14–17 lines × 2) cli/util/path.rs:96— cli/util/path.rs:96-112 | libs/core/error.rs:1512-1525 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (14–17 lines × 2) ext/canvas/bitmaprenderer.rs:670— ext/canvas/bitmaprenderer.rs:670-686 | ext/canvas/bitmaprenderer.rs:704-717 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–17 lines × 2) ext/node/ops/zlib/alloc.rs:30— ext/node/ops/zlib/alloc.rs:30-46 | ext/node/ops/zlib/alloc.rs:75-87 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–17 lines × 2) libs/core/uv_compat/stream.rs:673— libs/core/uv_compat/stream.rs:673-685 | libs/core/uv_compat/stream.rs:706-722 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–16 lines × 3) ext/node/ops/llhttp/binding.rs:421— ext/node/ops/llhttp/binding.rs:421-435 | ext/node/ops/llhttp/binding.rs:466-481 | ext/node/ops/llhttp/binding.rs:646-660 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (15–16 lines × 3) ext/node_sqlite/database.rs:1108— ext/node_sqlite/database.rs:1108-1123 | ext/node_sqlite/sql_tag_store.rs:311-325 | ext/node_sqlite/sql_tag_store.rs:514-528 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (14 lines × 6) cli/lsp/language_server.rs:2754— cli/lsp/language_server.rs:2754-2767 | cli/lsp/language_server.rs:2841-2854 | cli/lsp/language_server.rs:2883-2896 | cli/lsp/language_server.rs:3220-3233 | cli/lsp/language_server.rs:3385-3398 | cli/lsp/language_server.rs:3594-3607 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (14 lines × 6) ext/napi/js_native_api.rs:1260— ext/napi/js_native_api.rs:1260-1273 | ext/napi/js_native_api.rs:1307-1320 | ext/napi/js_native_api.rs:1354-1367 | ext/napi/js_native_api.rs:1844-1857 | ext/napi/js_native_api.rs:1895-1908 | ext/napi/js_native_api.rs:1942-1955 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (4–14 lines × 4) ext/crypto/lib.rs:390— ext/crypto/lib.rs:390-393 | ext/crypto/lib.rs:406-409 | ext/crypto/lib.rs:423-436 | ext/crypto/lib.rs:694-707 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (4–14 lines × 4) ext/node/ops/llhttp/binding.rs:751— ext/node/ops/llhttp/binding.rs:751-754 | ext/node/ops/stream_wrap.rs:698-701 | ext/node/ops/stream_wrap.rs:953-966 | ext/node/ops/stream_wrap.rs:1021-1034 — there are 4 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 4 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (13 lines × 4) cli/lsp/lint.rs:254— cli/lsp/lint.rs:254-266 | cli/lsp/lint.rs:308-320 | cli/lsp/lint.rs:381-393 | cli/lsp/lint.rs:405-417 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13 lines × 4) ext/node/ops/wasi.rs:1511— ext/node/ops/wasi.rs:1511-1523 | ext/node/ops/wasi.rs:1538-1550 | ext/node/ops/wasi.rs:1565-1577 | ext/node/ops/wasi.rs:1742-1754 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11–13 lines × 2) cli/tools/bundle/mod.rs:526— cli/tools/bundle/mod.rs:526-538 | cli/tools/transpile.rs:198-208 — before extracting anything, compare `cli/tools/bundle/mod.rs` and `cli/tools/transpile.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 40 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (11–13 lines × 2) cli/tools/fmt.rs:1295— cli/tools/fmt.rs:1295-1307 | cli/tools/fmt.rs:1568-1578 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12 lines × 4) ext/node/ops/stream_wrap.rs:1487— ext/node/ops/stream_wrap.rs:1487-1498 | ext/node/ops/stream_wrap.rs:1968-1979 | ext/node/ops/stream_wrap.rs:2054-2065 | ext/node/ops/tls_wrap.rs:2187-2198 — before extracting anything, compare `ext/node/ops/stream_wrap.rs` and `ext/node/ops/tls_wrap.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 4) runtime/permissions/lib.rs:2524— runtime/permissions/lib.rs:2524-2535 | runtime/permissions/lib.rs:2543-2554 | runtime/permissions/lib.rs:2562-2573 | runtime/permissions/lib.rs:2581-2592 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9–11 lines × 2) ext/fs/ops.rs:1203— ext/fs/ops.rs:1203-1213 | ext/fs/ops.rs:1296-1304 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–11 lines × 2) REDACTED:1680— REDACTED:1680-1690 | libs/core/uv_compat/tty.rs:2595-2603 — before extracting anything, compare `REDACTED` and `libs/core/uv_compat/tty.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 52 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 4) ext/node/ops/stream_wrap.rs:710— ext/node/ops/stream_wrap.rs:710-719 | ext/node/ops/stream_wrap.rs:739-748 | ext/node/ops/tls_wrap.rs:434-443 | ext/node/ops/tls_wrap.rs:488-497 — before extracting anything, compare `ext/node/ops/stream_wrap.rs` and `ext/node/ops/tls_wrap.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 4) libs/ops/conversion/from_v8/enum.rs:174— libs/ops/conversion/from_v8/enum.rs:174-183 | libs/ops/conversion/to_v8/enum.rs:344-353 | libs/ops/conversion/to_v8/enum.rs:360-369 | libs/ops/webidl/enum.rs:70-79 — `libs/ops/conversion/from_v8/enum.rs` and `libs/ops/conversion/to_v8/enum.rs` are one unit implemented once per sibling directory, so they are most likely parallel implementations of one contract rather than a copy of each other — this scan matched 4 separate duplicated blocks between them, totalling at least 54 lines. If both are selected at run time, neither can be retired in favour of the other, and the lines that DIFFER between them are the reason both exist. The move that pays here is to hoist the identical part into a shared location the whole family can reach and give what differs a parameter or a seam, so a change lands once instead of once per sibling; extracting one helper per block leaves every sibling to drift on its own.
Duplicated block (8–10 lines × 3) cli/tools/desktop.rs:4185— cli/tools/desktop.rs:4185-4194 | cli/tools/desktop.rs:4205-4214 | cli/tools/desktop.rs:4245-4252 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8–10 lines × 3) ext/fs/ops.rs:1587— ext/fs/ops.rs:1587-1594 | ext/fs/ops.rs:1653-1660 | ext/net/ops.rs:1201-1210 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (8–9 lines × 3) ext/crypto/subtle_get_public_key.rs:76— ext/crypto/subtle_get_public_key.rs:76-84 | ext/crypto/subtle_get_public_key.rs:101-108 | ext/crypto/subtle_get_public_key.rs:119-127 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8–9 lines × 3) cli/tools/desktop_devtools.rs:1024— cli/tools/desktop_devtools.rs:1024-1031 | cli/tools/desktop_devtools.rs:1034-1042 | cli/tools/desktop_devtools.rs:1046-1054 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7–8 lines × 3) ext/crypto/subtle_export_key.rs:749— ext/crypto/subtle_export_key.rs:749-755 | ext/crypto/subtle_export_key.rs:829-835 | ext/crypto/subtle_export_key.rs:908-915 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7–8 lines × 3) libs/eszip/v2.rs:108— libs/eszip/v2.rs:108-115 | libs/eszip/v2.rs:164-171 | libs/eszip/v2.rs:189-195 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6–8 lines × 2) cli/tools/desktop_devtools.rs:824— cli/tools/desktop_devtools.rs:824-831 | cli/tools/desktop_devtools.rs:847-852 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6–8 lines × 2) libs/npm/resolution/graph.rs:1801— libs/npm/resolution/graph.rs:1801-1806 | libs/npm/resolution/graph.rs:2100-2107 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6–7 lines × 2) cli/lsp/testing/execution.rs:798— cli/lsp/testing/execution.rs:798-803 | cli/lsp/testing/execution.rs:986-992 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (6–7 lines × 2) REDACTED:1298— REDACTED:1298-1303 | libs/core/uv_compat/stream.rs:876-882 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (4–5 lines × 3) cli/tools/desktop_devtools.rs:1069— cli/tools/desktop_devtools.rs:1069-1073 | cli/tools/desktop_devtools.rs:1117-1120 | cli/tools/desktop_devtools.rs:1148-1152 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (4–5 lines × 3) cli/tools/lint/ast_buffer/ts_estree.rs:910— cli/tools/lint/ast_buffer/ts_estree.rs:910-914 | cli/tools/lint/ast_buffer/ts_estree.rs:942-947 | cli/tools/lint/ast_buffer/ts_estree.rs:976-979 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (59 lines × 2 locations) ext/node/polyfills/_fs/_fs_constants.ts:9— ext/node/polyfills/_fs/_fs_constants.ts:9 · ext/node/polyfills/_fs/_fs_constants.ts:69 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
Duplicated block (59 lines × 2 locations) ext/node/polyfills/internal_binding/udp_wrap.ts:169— ext/node/polyfills/internal_binding/udp_wrap.ts:169 · ext/node/polyfills/internal_binding/udp_wrap.ts:300 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (49 lines × 2 locations) ext/web/14_compression.js:59— ext/web/14_compression.js:59 · ext/web/14_compression.js:121 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (49 lines × 2 locations) tools/lint.js:100— tools/lint.js:100 · tools/lint.js:179 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (41 lines × 2 locations) ext/node/polyfills/internal/crypto/keygen.ts:221— ext/node/polyfills/internal/crypto/keygen.ts:221 · ext/node/polyfills/internal/crypto/keys.ts:535 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (41 lines × 2 locations) ext/node/polyfills/internal/errors.ts:3612— ext/node/polyfills/internal/errors.ts:3612 · ext/node/polyfills/internal/errors.ts:3926 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
Duplicated block (38 lines × 2 locations) ext/node/polyfills/_fs/_fs_glob.ts:758— ext/node/polyfills/_fs/_fs_glob.ts:758 · ext/node/polyfills/_fs/_fs_glob.ts:1034 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (38 lines × 2 locations) ext/node/polyfills/inspector.js:59— ext/node/polyfills/inspector.js:59 · ext/node/polyfills/inspector_network_bridge.js:19 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Dead file (~28 LoC) libs/core_testing/integration/dyn_import_pending_tla/dyn_import_pending_tla.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~28 LoC) tools/release/create_symcache.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~25 LoC) ext/node/polyfills/stream/web_esm.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~25 LoC) tools/release/version_greater_latest.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~21 LoC) libs/core_testing/integration/error_source_maps_with_prepare_stack_trace/error_source_maps_with_prepare_stack_trace.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~21 LoC) libs/core_testing/integration/import_sync_throw/import_sync_throw.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Url.resolveObject (cyclomatic 117) ext/node/polyfills/url.ts:262— Url.resolveObject has cyclomatic complexity 117 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
utils.emitKeys (cyclomatic 112) ext/node/polyfills/internal/readline/utils.mjs:121— utils.emitKeys has cyclomatic complexity 112 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
Glob.#iterateSubpatterns (cyclomatic 106) ext/node/polyfills/_fs/_fs_glob.ts:880— Glob.#iterateSubpatterns has cyclomatic complexity 106 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Url.urlParse (cyclomatic 106) ext/node/polyfills/url.ts:666— Url.urlParse has cyclomatic complexity 106 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
comparisons.objectComparisonStart (cyclomatic 91) ext/node/polyfills/internal/util/comparisons.ts:302— comparisons.objectComparisonStart has cyclomatic complexity 91 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_incoming.matchKnownFields (cyclomatic 90) ext/node/polyfills/_http_incoming.js:259— _http_incoming.matchKnownFields has cyclomatic complexity 90 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
LocalNpmPackageInstaller::sync_resolution_with_fs (cyclomatic 89) libs/npm_installer/local.rs:199— LocalNpmPackageInstaller::sync_resolution_with_fs has cyclomatic complexity 89 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_client.ClientRequest (cyclomatic 87) REDACTED:505— _http_client.ClientRequest has cyclomatic complexity 87 (threshold 15). Of this number, 86 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Glob.#addSubpatterns (cyclomatic 82) ext/node/polyfills/_fs/_fs_glob.ts:618— Glob.#addSubpatterns has cyclomatic complexity 82 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Interface.[kTtyWrite] (cyclomatic 72) ext/node/polyfills/internal/readline/interface.mjs:1093— Interface.[kTtyWrite] has cyclomatic complexity 72 (threshold 15). Of this number, 71 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
(computed) (cyclomatic 72) ext/node/polyfills/internal/readline/interface.mjs:1093— (computed) has cyclomatic complexity 72 (threshold 15). Of this number, 71 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
D1 · Cyclomatic Complexity· eos (cyclomatic 70) · ×1
eos (cyclomatic 70) ext/node/polyfills/internal/streams/end-of-stream.js:67— eos has cyclomatic complexity 70 (threshold 15). Of this number, 43 points are the body's own statements and 27 belong to 11 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ChildProcess.#spawnInternal (cyclomatic 67) ext/node/polyfills/internal/child_process.ts:369— ChildProcess.#spawnInternal has cyclomatic complexity 67 (threshold 15). Of this number, 58 points are the body's own statements and 9 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
mainFetch (cyclomatic 62) ext/fetch/26_fetch.js:386— mainFetch has cyclomatic complexity 62 (threshold 15). Of this number, 59 points are the body's own statements and 3 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
pipeline.pipelineImpl (cyclomatic 61) ext/node/polyfills/internal/streams/pipeline.js:210— pipeline.pipelineImpl has cyclomatic complexity 61 (threshold 15). Of this number, 48 points are the body's own statements and 13 belong to 3 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
01_require.Module._load (cyclomatic 59) ext/node/polyfills/01_require.js:1412— 01_require.Module._load has cyclomatic complexity 59 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
OptionsParser::parse (cyclomatic 58) libs/node_shim/lib.rs:2801— OptionsParser::parse has cyclomatic complexity 58 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: OptionsParser::set_boolean_field (cyclomatic 111) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
NodeWorker.constructor (cyclomatic 58) ext/node/polyfills/worker_threads.ts:291— NodeWorker.constructor has cyclomatic complexity 58 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
keygen.createJob (cyclomatic 54) ext/node/polyfills/internal/crypto/keygen.ts:390— keygen.createJob has cyclomatic complexity 54 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
update_node_stream.transform (cyclomatic 52) ext/node/update_node_stream.ts:122— update_node_stream.transform has cyclomatic complexity 52 (threshold 15). Most of this is not in the body itself: 5 of the 52 points are its own statements and the rest belongs to 11 function items inside it that branch (a function literal at line 158, a function literal at line 418, a function literal at line 353, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
06_streams.readableByteStreamTee (cyclomatic 52) ext/web/06_streams.js:3913— 06_streams.readableByteStreamTee has cyclomatic complexity 52 (threshold 15). Of this number, 20 points are the body's own statements and 32 belong to 10 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_resolveFilename (cyclomatic 52) ext/node/polyfills/01_require.js:1657— _resolveFilename has cyclomatic complexity 52 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
compose (cyclomatic 52) ext/node/polyfills/internal/streams/compose.js:39— compose has cyclomatic complexity 52 (threshold 15). Of this number, 29 points are the body's own statements and 23 belong to 14 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
primary.init (cyclomatic 51) ext/node/polyfills/internal/cluster/primary.ts:59— primary.init has cyclomatic complexity 51 (threshold 15). Most of this is not in the body itself: 7 of the 51 points are its own statements and the rest belongs to 11 function items inside it that branch (queryServer, createWorkerProcess, a function literal at line 262, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
node_shim::translate_to_deno_args (cyclomatic 50) libs/node_shim/lib.rs:3470— node_shim::translate_to_deno_args has cyclomatic complexity 50 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: OptionsParser::set_boolean_field (cyclomatic 111) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
readableStreamPipeTo (cyclomatic 48) ext/web/06_streams.js:3247— readableStreamPipeTo has cyclomatic complexity 48 (threshold 15). Of this number, 17 points are the body's own statements and 31 belong to 27 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Console::table_impl (cyclomatic 47) ext/web/console/mod.rs:1421— Console::table_impl has cyclomatic complexity 47 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_server.parserOnIncoming (cyclomatic 47) ext/node/polyfills/_http_server.js:950— _http_server.parserOnIncoming has cyclomatic complexity 47 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_tls_wrap.TLSSocket._init (cyclomatic 47) ext/node/polyfills/_tls_wrap.js:717— _tls_wrap.TLSSocket._init has cyclomatic complexity 47 (threshold 15). Of this number, 23 points are the body's own statements and 24 belong to 8 function literals inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_win32.resolve (cyclomatic 47) ext/node/polyfills/path/_win32.ts:91— _win32.resolve has cyclomatic complexity 47 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
constructor (cyclomatic 47) ext/fetch/23_request.js:370— constructor has cyclomatic complexity 47 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_win32.normalize (cyclomatic 46) ext/node/polyfills/path/_win32.ts:275— _win32.normalize has cyclomatic complexity 46 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
JsError::inner_from_v8_exception (cyclomatic 45) libs/core/error.rs:1016— JsError::inner_from_v8_exception has cyclomatic complexity 45 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
constructor (cyclomatic 45) ext/websocket/01_websocket.js:253— constructor has cyclomatic complexity 45 (threshold 15). Of this number, 38 points are the body's own statements and 7 belong to 5 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Lockfile::set_workspace_config (cyclomatic 44) libs/lockfile/lib.rs:835— Lockfile::set_workspace_config has cyclomatic complexity 44 (threshold 15). Of this number, 42 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
prefer_primordials.buildScopeTreeFixed::visit (cyclomatic 44) tools/lint_plugins/prefer_primordials.ts:388— prefer_primordials.buildScopeTreeFixed::visit has cyclomatic complexity 44 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_lint_selector.parseSelector (cyclomatic 43) REDACTED:475— 40_lint_selector.parseSelector has cyclomatic complexity 43 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
normalize_encoding.slowCases (cyclomatic 43) ext/node/polyfills/internal/normalize_encoding.ts:13— normalize_encoding.slowCases has cyclomatic complexity 43 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
worker_threads.webMessagePortToNodeMessagePort (cyclomatic 43) ext/node/polyfills/worker_threads.ts:1938— worker_threads.webMessagePortToNodeMessagePort has cyclomatic complexity 43 (threshold 15). Most of this is not in the body itself: 10 of the 43 points are its own statements and the rest belongs to 7 function items inside it that branch (a function literal at line 2110, a function literal at line 1983, a function literal at line 2027, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
JsRuntimeInspectorState::poll_sessions (cyclomatic 42) libs/core/inspector.rs:522— JsRuntimeInspectorState::poll_sessions has cyclomatic complexity 42 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_bench.benchMeasure (cyclomatic 42) cli/js/40_bench.js:244— 40_bench.benchMeasure has cyclomatic complexity 42 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ClientHttp2Session.request (cyclomatic 42) ext/node/polyfills/http2.ts:4684— ClientHttp2Session.request has cyclomatic complexity 42 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_win32.relative (cyclomatic 42) ext/node/polyfills/path/_win32.ts:565— _win32.relative has cyclomatic complexity 42 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
setUpAsyncStub (cyclomatic 42) libs/core/00_infra.js:211— setUpAsyncStub has cyclomatic complexity 42 (threshold 15). Most of this is not in the body itself: 12 of the 42 points are its own statements and the rest belongs to 10 function items inside it that branch (async_op_0, async_op_1, async_op_2, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
deno_dotenv::parse_env_content_hook_impl (cyclomatic 41) libs/dotenv/lib.rs:151— deno_dotenv::parse_env_content_hook_impl has cyclomatic complexity 41 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
inspect.isFullWidthCodePoint (cyclomatic 41) ext/node/polyfills/internal/util/inspect.mjs:325— inspect.isFullWidthCodePoint has cyclomatic complexity 41 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
_win32.parse (cyclomatic 41) ext/node/polyfills/path/_win32.ts:1040— _win32.parse has cyclomatic complexity 41 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
querystring.parse (cyclomatic 41) ext/node/polyfills/querystring.js:111— querystring.parse has cyclomatic complexity 41 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_outgoing.tryDirectEnd (cyclomatic 40) ext/node/polyfills/_http_outgoing.ts:1480— _http_outgoing.tryDirectEnd has cyclomatic complexity 40 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
tty.getColorDepth (cyclomatic 40) ext/node/polyfills/internal/tty.js:132— tty.getColorDepth has cyclomatic complexity 40 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Url.format (cyclomatic 40) ext/node/polyfills/url.ts:565— Url.format has cyclomatic complexity 40 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
worker_threads.internals.__initWorkerThreads (cyclomatic 40) ext/node/polyfills/worker_threads.ts:986— worker_threads.internals.__initWorkerThreads has cyclomatic complexity 40 (threshold 15). Of this number, 25 points are the body's own statements and 15 belong to 9 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
createRespondWith::respondWith (cyclomatic 40) ext/http/01_http.js:197— createRespondWith::respondWith has cyclomatic complexity 40 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
HoistedNpmPackageInstaller::sync_resolution_with_fs (cyclomatic 39) libs/npm_installer/hoisted.rs:349— HoistedNpmPackageInstaller::sync_resolution_with_fs has cyclomatic complexity 39 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
01_http.createRespondWith (cyclomatic 39) ext/http/01_http.js:191— 01_http.createRespondWith has cyclomatic complexity 39 (threshold 15). Most of this is not in the body itself: 1 of the 39 points is its own statement and the rest belongs to one function literal inside it that branches (line 197). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
http2.onSessionHeaders (cyclomatic 39) ext/node/polyfills/http2.ts:1517— http2.onSessionHeaders has cyclomatic complexity 39 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child.init (cyclomatic 39) ext/node/polyfills/internal/cluster/child.ts:39— child.init has cyclomatic complexity 39 (threshold 15). Most of this is not in the body itself: 5 of the 39 points are its own statements and the rest belongs to 18 function items inside it that branch (onconnection, a function literal at line 97, a function literal at line 88, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
ModuleRegistry::get_completions (cyclomatic 38) cli/lsp/registries.rs:662— ModuleRegistry::get_completions has cyclomatic complexity 38 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
NpmInstallDepsProvider::from_workspace (cyclomatic 38) libs/npm_installer/package_json.rs:161— NpmInstallDepsProvider::from_workspace has cyclomatic complexity 38 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
AssertionError.constructor (cyclomatic 38) ext/node/polyfills/internal/assert/assertion_error.js:323— AssertionError.constructor has cyclomatic complexity 38 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_outgoing.tryDirectEmptyEnd (cyclomatic 37) ext/node/polyfills/_http_outgoing.ts:1576— _http_outgoing.tryDirectEmptyEnd has cyclomatic complexity 37 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
child_process.fork (cyclomatic 37) ext/node/polyfills/child_process.ts:99— child_process.fork has cyclomatic complexity 37 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_url.isSimpleSpecialHostCanonical (cyclomatic 37) ext/web/00_url.js:493— 00_url.isSimpleSpecialHostCanonical has cyclomatic complexity 37 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
EnvironmentOptions::check_options (cyclomatic 36) libs/node_shim/lib.rs:422— EnvironmentOptions::check_options has cyclomatic complexity 36 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This is NOT this file's highest cyclomatic complexity: OptionsParser::set_boolean_field (cyclomatic 111) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
SecureContext.constructor (cyclomatic 36) ext/node/polyfills/_tls_common.ts:507— SecureContext.constructor has cyclomatic complexity 36 (threshold 15). Of this number, 31 points are the body's own statements and 5 belong to 2 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
from.from (cyclomatic 36) ext/node/polyfills/internal/streams/from.js:22— from.from has cyclomatic complexity 36 (threshold 15). Most of this is not in the body itself: 6 of the 36 points are its own statements and the rest belongs to 6 function items inside it that branch (nextSyncWithSyncValues, nextSyncWithAsyncValues, close, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
net.Server.listen (cyclomatic 36) ext/node/polyfills/net.ts:2907— net.Server.listen has cyclomatic complexity 36 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_url.parseSimpleSpecialUrl (cyclomatic 36) ext/web/00_url.js:605— 00_url.parseSimpleSpecialUrl has cyclomatic complexity 36 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ZstdCompress::init (cyclomatic 35) ext/node/ops/zlib/mod.rs:1115— ZstdCompress::init has cyclomatic complexity 35 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
NpmRc::parse (cyclomatic 35) libs/npmrc/lib.rs:200— NpmRc::parse has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.normalizeSpawnArguments (cyclomatic 35) ext/node/polyfills/internal/child_process.ts:1214— child_process.normalizeSpawnArguments has cyclomatic complexity 35 (threshold 15). Of this number, 34 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
sig.verifyOneShot (cyclomatic 35) ext/node/polyfills/internal/crypto/sig.ts:468— sig.verifyOneShot has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
util.updateSettingsBuffer (cyclomatic 35) ext/node/polyfills/internal/http2/util.ts:384— util.updateSettingsBuffer has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
net._lookupAndConnect (cyclomatic 35) ext/node/polyfills/net.ts:1052— net._lookupAndConnect has cyclomatic complexity 35 (threshold 15). Of this number, 23 points are the body's own statements and 12 belong to 5 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
serverRequestInner (cyclomatic 35) cli/tsc/98_lsp.js:428— serverRequestInner has cyclomatic complexity 35 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TsResponseImportMapper::check_specifier (cyclomatic 34) cli/lsp/analysis.rs:367— TsResponseImportMapper::check_specifier has cyclomatic complexity 34 (threshold 15). Of this number, 33 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TestRun::exec (cyclomatic 34) cli/lsp/testing/execution.rs:235— TestRun::exec has cyclomatic complexity 34 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
denort_desktop::run_desktop (cyclomatic 34) cli/rt_desktop/lib.rs:1695— denort_desktop::run_desktop has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.spawnSync (cyclomatic 34) ext/node/polyfills/internal/child_process.ts:1926— child_process.spawnSync has cyclomatic complexity 34 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
99_main.bootstrapMainRuntime (cyclomatic 34) runtime/js/99_main.js:936— 99_main.bootstrapMainRuntime has cyclomatic complexity 34 (threshold 15). Of this number, 19 points are the body's own statements and 15 belong to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
dispatch (cyclomatic 34) ext/web/02_event.js:566— dispatch has cyclomatic complexity 34 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
buffer.Buffer.fill (cyclomatic 33) ext/node/polyfills/internal/buffer.mjs:2232— buffer.Buffer.fill has cyclomatic complexity 33 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
interface.InterfaceConstructor (cyclomatic 33) ext/node/polyfills/internal/readline/interface.mjs:171— interface.InterfaceConstructor has cyclomatic complexity 33 (threshold 15). Of this number, 23 points are the body's own statements and 10 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DatabaseSyncOptions::from_v8 (cyclomatic 32) ext/node_sqlite/database.rs:160— DatabaseSyncOptions::from_v8 has cyclomatic complexity 32 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
PackageJson::load_from_value (cyclomatic 32) libs/package_json/lib.rs:510— PackageJson::load_from_value has cyclomatic complexity 32 (threshold 15). Of this number, 23 points are the body's own statements and 9 belong to 5 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
readable.Readable.read (cyclomatic 32) ext/node/polyfills/internal/streams/readable.js:713— readable.Readable.read has cyclomatic complexity 32 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
table (cyclomatic 32) ext/node/polyfills/internal/console/constructor.mjs:607— table has cyclomatic complexity 32 (threshold 15). Of this number, 28 points are the body's own statements and 4 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
constructor (cyclomatic 32) ext/websocket/02_websocketstream.js:106— constructor has cyclomatic complexity 32 (threshold 15). Most of this is not in the body itself: 9 of the 32 points are its own statements and the rest belongs to 18 function items inside it that branch ((anonymous)::pull, a function literal at line 181, a function literal at line 188, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
createImageBitmap (cyclomatic 32) ext/image/01_image.js:136— createImageBitmap has cyclomatic complexity 32 (threshold 15). Most of this is not in the body itself: 9 of the 32 points are its own statements and the rest belongs to one function literal inside it that branches (line 219). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
CompletionEntry::as_completion_item (cyclomatic 31) cli/lsp/tsc.rs:4422— CompletionEntry::as_completion_item has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
denort::run::run_with_options (cyclomatic 31) cli/rt/run.rs:1394— denort::run::run_with_options has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_npm::fast_registry_json::pluck_versions_from_tokens (cyclomatic 31) libs/npm/fast_registry_json.rs:796— deno_npm::fast_registry_json::pluck_versions_from_tokens has cyclomatic complexity 31 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_http_agent.Agent (cyclomatic 31) ext/node/polyfills/_http_agent.js:137— _http_agent.Agent has cyclomatic complexity 31 (threshold 15). Most of this is not in the body itself: 14 of the 31 points are its own statements and the rest belongs to one function literal inside it that branches (line 185). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
https.openCONNECTTunnel (cyclomatic 31) ext/node/polyfills/https.ts:446— https.openCONNECTTunnel has cyclomatic complexity 31 (threshold 15). Most of this is not in the body itself: 11 of the 31 points are its own statements and the rest belongs to 6 function items inside it that branch (onProxyReady::onData, onProxyReady, fail, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
inspect.formatWithOptionsInternal (cyclomatic 31) ext/node/polyfills/internal/util/inspect.mjs:479— inspect.formatWithOptionsInternal has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
REPLServer.constructor (cyclomatic 31) ext/node/polyfills/repl.ts:593— REPLServer.constructor has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: 3 other methods here (REPLServer.constructor::_doComplete, REPLServer.constructor::showPreview, REPLServer.constructor::clearPreview) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 4 times rather than 4 independent problems. Splitting this body alone leaves the other 3 exactly as they are. Where these are variations on one operation, the change that clears all 4 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
string_decoder.decode (cyclomatic 31) ext/node/polyfills/string_decoder.ts:130— string_decoder.decode has cyclomatic complexity 31 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphWalker::resolve_pending (cyclomatic 30) cli/type_checker.rs:1129— GraphWalker::resolve_pending has cyclomatic complexity 30 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_server.resOnFinish (cyclomatic 30) ext/node/polyfills/_http_server.js:1185— _http_server.resOnFinish has cyclomatic complexity 30 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
sig.signOneShot (cyclomatic 30) ext/node/polyfills/internal/crypto/sig.ts:349— sig.signOneShot has cyclomatic complexity 30 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
readable.Readable.pipe (cyclomatic 30) ext/node/polyfills/internal/streams/readable.js:998— readable.Readable.pipe has cyclomatic complexity 30 (threshold 15). Most of this is not in the body itself: 11 of the 30 points are its own statements and the rest belongs to 5 function items inside it that branch (pause, cleanup, onerror, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
FileReader.#readOperation (cyclomatic 30) ext/web/10_filereader.js:73— FileReader.#readOperation has cyclomatic complexity 30 (threshold 15). Most of this is not in the body itself: 2 of the 30 points are its own statements and the rest belongs to 7 function literals inside it that branch (lines 165, 111, 244, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
FilePatterns::split_by_base (cyclomatic 29) libs/config/glob/mod.rs:132— FilePatterns::split_by_base has cyclomatic complexity 29 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
http2.setupHandle (cyclomatic 29) ext/node/polyfills/http2.ts:3510— http2.setupHandle has cyclomatic complexity 29 (threshold 15). Most of this is not in the body itself: 14 of the 29 points are its own statements and the rest belongs to 6 function items inside it that branch (a function literal at line 3641, socketOnData, a function literal at line 3562, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
update_types_node.modifySourceFiles (cyclomatic 29) tools/update_types_node.ts:125— update_types_node.modifySourceFiles has cyclomatic complexity 29 (threshold 15). Of this number, 24 points are the body's own statements and 5 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: update_types_node.isKnownModuleSpecifier (cyclomatic 54) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded method is counted neither in this dimension's figures nor in its score.
deno_image::bitmap::parse_args (cyclomatic 28) ext/image/bitmap.rs:283— deno_image::bitmap::parse_args has cyclomatic complexity 28 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
Prime::generate_with_options (cyclomatic 28) ext/node_crypto/primes.rs:42— Prime::generate_with_options has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
PermissionsContainer::check_special_file (cyclomatic 28) runtime/permissions/lib.rs:4602— PermissionsContainer::check_special_file has cyclomatic complexity 28 (threshold 15). Of this number, 20 points are the body's own statements and 8 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Lexer.next (cyclomatic 28) REDACTED:220— Lexer.next has cyclomatic complexity 28 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
child_process.buildCommand (cyclomatic 28) ext/node/polyfills/internal/child_process.ts:1732— child_process.buildCommand has cyclomatic complexity 28 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
REPLServer._handleError (cyclomatic 28) ext/node/polyfills/repl.ts:1676— REPLServer._handleError has cyclomatic complexity 28 (threshold 15). Of this number, 25 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
extractBody (cyclomatic 28) ext/fetch/22_body.js:485— extractBody has cyclomatic complexity 28 (threshold 15). Of this number, 26 points are the body's own statements and 2 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ConfiguredDepResolutions::new (cyclomatic 27) cli/lsp/resolver.rs:784— ConfiguredDepResolutions::new has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
LockfileContent::from_json (cyclomatic 27) libs/lockfile/lib.rs:384— LockfileContent::from_json has cyclomatic complexity 27 (threshold 15). Of this number, 21 points are the body's own statements and 6 belong to 3 function items inside it that branch. To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
MacroConfig::from_metas (cyclomatic 27) libs/ops/op2/config.rs:96— MacroConfig::from_metas has cyclomatic complexity 27 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
EventSource.#loop (cyclomatic 27) REDACTED:229— EventSource.#loop has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
http2.processRespondWithFD (cyclomatic 27) ext/node/polyfills/http2.ts:2795— http2.processRespondWithFD has cyclomatic complexity 27 (threshold 15). Most of this is not in the body itself: 7 of the 27 points are its own statements and the rest belongs to 6 function items inside it that branch (readAndWrite, a function literal at line 2872, closeOwnedFd, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
duplexify.duplexify (cyclomatic 27) ext/node/polyfills/internal/streams/duplexify.js:50— duplexify.duplexify has cyclomatic complexity 27 (threshold 15). Of this number, 24 points are the body's own statements and 3 belong to 3 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
operators.map (cyclomatic 27) ext/node/polyfills/internal/streams/operators.js:83— operators.map has cyclomatic complexity 27 (threshold 15). Most of this is not in the body itself: 6 of the 27 points are its own statements and the rest belongs to 3 function literals inside it that branch (lines 146, 113, 134). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
comparisons.objEquiv (cyclomatic 27) ext/node/polyfills/internal/util/comparisons.ts:1232— comparisons.objEquiv has cyclomatic complexity 27 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_win32.dirname (cyclomatic 27) ext/node/polyfills/path/_win32.ts:777— _win32.dirname has cyclomatic complexity 27 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
TextDecoder.decode (cyclomatic 27) ext/web/08_text_encoding.js:127— TextDecoder.decode has cyclomatic complexity 27 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
LibUvStreamWrap::writev (cyclomatic 26) ext/node/ops/stream_wrap.rs:1501— LibUvStreamWrap::writev has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
RawDenoResolver::resolve (cyclomatic 26) libs/resolver/lib.rs:321— RawDenoResolver::resolve has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
SloppyImportsResolver::resolve (cyclomatic 26) libs/resolver/workspace.rs:425— SloppyImportsResolver::resolve has cyclomatic complexity 26 (threshold 15). Of this number, 25 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
assert.expectedException (cyclomatic 26) ext/node/polyfills/assert.ts:188— assert.expectedException has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
fs.watch (cyclomatic 26) ext/node/polyfills/fs.ts:3474— fs.watch has cyclomatic complexity 26 (threshold 15). Of this number, 18 points are the body's own statements and 8 belong to 3 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.transformDenoShellCommand (cyclomatic 26) ext/node/polyfills/internal/child_process.ts:1539— child_process.transformDenoShellCommand has cyclomatic complexity 26 (threshold 15). Of this number, 22 points are the body's own statements and 4 belong to 2 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
net.Socket (cyclomatic 26) ext/node/polyfills/net.ts:1466— net.Socket has cyclomatic complexity 26 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
parseArgs (cyclomatic 26) ext/node/polyfills/internal/util/parse_args/parse_args.js:332— parseArgs has cyclomatic complexity 26 (threshold 15). Most of this is not in the body itself: 8 of the 26 points are its own statements and the rest belongs to 3 function literals inside it that branch (lines 411, 356, 457). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
DOMMatrixReadOnly::exec_css_transform (cyclomatic 25) ext/web/geometry.rs:1785— DOMMatrixReadOnly::exec_css_transform has cyclomatic complexity 25 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
_http_outgoing.write_ (cyclomatic 25) ext/node/polyfills/_http_outgoing.ts:1373— _http_outgoing.write_ has cyclomatic complexity 25 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
DiffieHellmanImpl.constructor (cyclomatic 25) ext/node/polyfills/internal/crypto/diffiehellman.ts:117— DiffieHellmanImpl.constructor has cyclomatic complexity 25 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_win32.basename (cyclomatic 25) ext/node/polyfills/path/_win32.ts:872— _win32.basename has cyclomatic complexity 25 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
URLSearchParams.constructor (cyclomatic 25) ext/web/00_url.js:127— URLSearchParams.constructor has cyclomatic complexity 25 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
D1 · Cyclomatic Complexity· on (cyclomatic 25) · ×1
on (cyclomatic 25) ext/node/polyfills/_events.mjs:1045— on has cyclomatic complexity 25 (threshold 15). Of this number, 15 points are the body's own statements and 10 belong to 12 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_http_client.parserOnIncomingClient (cyclomatic 24) REDACTED:1283— _http_client.parserOnIncomingClient has cyclomatic complexity 24 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_posix.parse (cyclomatic 24) ext/node/polyfills/path/_posix.ts:424— _posix.parse has cyclomatic complexity 24 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
UvLoopInner::has_alive_handles (cyclomatic 23) libs/core/uv_compat.rs:359— UvLoopInner::has_alive_handles has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
02_websocket.upgradeWebSocket (cyclomatic 23) ext/http/02_websocket.ts:43— 02_websocket.upgradeWebSocket has cyclomatic complexity 23 (threshold 15). Of this number, 18 points are the body's own statements and 5 belong to 3 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
01_require.Module._findPath (cyclomatic 23) ext/node/polyfills/01_require.js:1261— 01_require.Module._findPath has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Http2Stream._destroy (cyclomatic 23) ext/node/polyfills/http2.ts:2532— Http2Stream._destroy has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
buffer.Buffer.copy (cyclomatic 23) ext/node/polyfills/internal/buffer.mjs:2113— buffer.Buffer.copy has cyclomatic complexity 23 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
util.buildNgHeaderString (cyclomatic 23) ext/node/polyfills/internal/http2/util.ts:811— util.buildNgHeaderString has cyclomatic complexity 23 (threshold 15). Most of this is not in the body itself: 9 of the 23 points are its own statements and the rest belongs to one function item inside it that branches (processHeader). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
comparisons.keyCheck (cyclomatic 23) ext/node/polyfills/internal/util/comparisons.ts:513— comparisons.keyCheck has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
net._lookupAndConnectMultiple (cyclomatic 23) ext/node/polyfills/net.ts:1263— net._lookupAndConnectMultiple has cyclomatic complexity 23 (threshold 15). Most of this is not in the body itself: 1 of the 23 points is its own statement and the rest belongs to 2 function literals inside it that branch (lines 1277, 1276). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
generate_linux_function_orderfile.parseArgs (cyclomatic 23) tools/startup_order/generate_linux_function_orderfile.ts:55— generate_linux_function_orderfile.parseArgs has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
measure (cyclomatic 23) ext/web/15_performance.js:727— measure has cyclomatic complexity 23 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
bench (cyclomatic 23) cli/js/40_bench.js:64— bench has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
request (cyclomatic 23) ext/web/locks.js:99— request has cyclomatic complexity 23 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ModuleGraphBuilder::build_graph_with_npm_resolution_and_build_options (cyclomatic 22) cli/graph_util.rs:1003— ModuleGraphBuilder::build_graph_with_npm_resolution_and_build_options has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
AdvancedIpcDeserializerDelegate::read_host_object (cyclomatic 22) ext/node/ops/ipc.rs:555— AdvancedIpcDeserializerDelegate::read_host_object has cyclomatic complexity 22 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
AsymmetricPrivateKey::export_der (cyclomatic 22) ext/node_crypto/keys.rs:2410— AsymmetricPrivateKey::export_der has cyclomatic complexity 22 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
ImageData::constructor (cyclomatic 22) ext/web/image_data.rs:199— ImageData::constructor has cyclomatic complexity 22 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
deno_npm_installer::hoisted::compute_hoisted_layout (cyclomatic 22) libs/npm_installer/hoisted.rs:98— deno_npm_installer::hoisted::compute_hoisted_layout has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_serve.mapToCallback::mapped (cyclomatic 22) REDACTED:717— 00_serve.mapToCallback::mapped has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
AtomicOperation.[SymbolFor("Deno.privateCustomInspect")] (cyclomatic 22) ext/kv/01_db.ts:604— AtomicOperation.[SymbolFor("Deno.privateCustomInspect")] has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Socket.bind (cyclomatic 22) ext/node/polyfills/dgram.ts:405— Socket.bind has cyclomatic complexity 22 (threshold 15). Of this number, 16 points are the body's own statements and 6 belong to one function literal inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
dns.lookup (cyclomatic 22) ext/node/polyfills/dns.ts:192— dns.lookup has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
https.Agent.getName (cyclomatic 22) ext/node/polyfills/https.ts:255— https.Agent.getName has cyclomatic complexity 22 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
errors.createInvalidArgType (cyclomatic 22) ext/node/polyfills/internal/errors.ts:734— errors.createInvalidArgType has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_posix.basename (cyclomatic 22) ext/node/polyfills/path/_posix.ts:281— _posix.basename has cyclomatic complexity 22 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_win32.join (cyclomatic 22) ext/node/polyfills/path/_win32.ts:460— _win32.join has cyclomatic complexity 22 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
httpRedirectFetch (cyclomatic 22) ext/fetch/26_fetch.js:749— httpRedirectFetch has cyclomatic complexity 22 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
HttpRecordResponse::poll_frame (cyclomatic 21) ext/http/service.rs:1217— HttpRecordResponse::poll_frame has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Http2Options::new (cyclomatic 21) ext/node/ops/http2/session.rs:388— Http2Options::new has cyclomatic complexity 21 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ChainSearch::extend (cyclomatic 21) ext/node/ops/tls_wrap.rs:4386— ChainSearch::extend has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_node::ops::tls_wrap::rustls_error_to_node_error (cyclomatic 26) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
ConfigFile::to_exports_config (cyclomatic 21) libs/config/deno_json/mod.rs:2022— ConfigFile::to_exports_config has cyclomatic complexity 21 (threshold 15). Most of this is not in the body itself: 7 of the 21 points are its own statements and the rest belongs to 2 function items inside it that branch (validate_key, validate_value). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
FileCollector::collect_file_patterns (cyclomatic 21) libs/config/glob/collector.rs:71— FileCollector::collect_file_patterns has cyclomatic complexity 21 (threshold 15). Of this number, 18 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_lint._dump (cyclomatic 21) REDACTED:1455— 40_lint._dump has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TextLineStream.#handle (cyclomatic 21) REDACTED:75— TextLineStream.#handle has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_ffi.getTypeSizeAndAlignment (cyclomatic 21) REDACTED:339— 00_ffi.getTypeSizeAndAlignment has cyclomatic complexity 21 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
_tls_common.validateKeyStrength (cyclomatic 21) ext/node/polyfills/_tls_common.ts:187— _tls_common.validateKeyStrength has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Socket.send (cyclomatic 21) ext/node/polyfills/dgram.ts:922— Socket.send has cyclomatic complexity 21 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
child_process.getValidStdio (cyclomatic 21) ext/node/polyfills/internal/child_process.ts:1128— child_process.getValidStdio has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.getIpcHandleInfo (cyclomatic 21) ext/node/polyfills/internal/child_process.ts:2300— child_process.getIpcHandleInfo has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
SecretKeyObject.toCryptoKey (cyclomatic 21) ext/node/polyfills/internal/crypto/keys.ts:739— SecretKeyObject.toCryptoKey has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Http2ServerResponse.writeHead (cyclomatic 21) ext/node/polyfills/internal/http2/compat.js:763— Http2ServerResponse.writeHead has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
readable.fromList (cyclomatic 21) ext/node/polyfills/internal/streams/readable.js:1689— readable.fromList has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
writable.onwrite (cyclomatic 21) ext/node/polyfills/internal/streams/writable.js:713— writable.onwrite has cyclomatic complexity 21 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
process.internals.__bootstrapNodeProcess (cyclomatic 21) ext/node/polyfills/process.ts:1831— process.internals.__bootstrapNodeProcess has cyclomatic complexity 21 (threshold 15). Of this number, 19 points are the body's own statements and 2 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
testing.run (cyclomatic 21) ext/node/polyfills/testing.ts:448— testing.run has cyclomatic complexity 21 (threshold 15). Of this number, 11 points are the body's own statements and 10 belong to 5 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
testing.mockModule (cyclomatic 21) ext/node/polyfills/testing.ts:3347— testing.mockModule has cyclomatic complexity 21 (threshold 15). Of this number, 18 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
06_streams.readableByteStreamControllerPullInto (cyclomatic 21) ext/web/06_streams.js:2437— 06_streams.readableByteStreamControllerPullInto has cyclomatic complexity 21 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
LspScopedResolver::configured_auto_import_roots (cyclomatic 20) cli/lsp/resolver.rs:394— LspScopedResolver::configured_auto_import_roots has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TestServer::new (cyclomatic 20) cli/lsp/testing/server.rs:63— TestServer::new has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDisplayContext::build_module_info (cyclomatic 20) cli/tools/info.rs:636— GraphDisplayContext::build_module_info has cyclomatic complexity 20 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
JsRuntimeInspector::capture_network_event (cyclomatic 20) libs/core/inspector.rs:1255— JsRuntimeInspector::capture_network_event has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Graph::compute_all_npm_pkg_ids (cyclomatic 20) libs/npm/resolution/graph.rs:541— Graph::compute_all_npm_pkg_ids has cyclomatic complexity 20 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
MatchCtx.getAttrPathValue (cyclomatic 20) REDACTED:981— MatchCtx.getAttrPathValue has cyclomatic complexity 20 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
30_fs.parseFileInfo (cyclomatic 20) ext/fs/30_fs.js:437— 30_fs.parseFileInfo has cyclomatic complexity 20 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_http_agent.Agent.addRequest (cyclomatic 20) ext/node/polyfills/_http_agent.js:350— _http_agent.Agent.addRequest has cyclomatic complexity 20 (threshold 15). Of this number, 19 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
streams.createWritableStdioStream (cyclomatic 20) ext/node/polyfills/_process/streams.mjs:41— streams.createWritableStdioStream has cyclomatic complexity 20 (threshold 15). Of this number, 12 points are the body's own statements and 8 belong to 4 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
streams.initStdin (cyclomatic 20) ext/node/polyfills/_process/streams.mjs:234— streams.initStdin has cyclomatic complexity 20 (threshold 15). Of this number, 15 points are the body's own statements and 5 belong to 2 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
child_process.execFile (cyclomatic 20) ext/node/polyfills/child_process.ts:525— child_process.execFile has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This shape REPEATS in the file: one other method here (child_process.execFile::exithandler) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
http2.doSendFileFD (cyclomatic 20) ext/node/polyfills/http2.ts:2959— http2.doSendFileFD has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
buffer.getEncodingOps (cyclomatic 20) ext/node/polyfills/internal/buffer.mjs:2913— buffer.getEncodingOps has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
util.prepareRequestHeadersArray (cyclomatic 20) ext/node/polyfills/internal/http2/util.ts:632— util.prepareRequestHeadersArray has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
buffer.indexOfBuffer (cyclomatic 20) ext/node/polyfills/internal_binding/buffer.ts:104— buffer.indexOfBuffer has cyclomatic complexity 20 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
net._createServerHandle (cyclomatic 20) ext/node/polyfills/net.ts:2519— net._createServerHandle has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_util.normalizeString (cyclomatic 20) ext/node/polyfills/path/_util.ts:46— _util.normalizeString has cyclomatic complexity 20 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
testing.runTapEntry (cyclomatic 20) ext/node/polyfills/testing.ts:963— testing.runTapEntry has cyclomatic complexity 20 (threshold 15). Of this number, 19 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
MessagePort.postMessage (cyclomatic 20) ext/web/13_message_port.js:294— MessagePort.postMessage has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
constructor (cyclomatic 20) ext/web/02_event.js:1336— constructor has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
styleText (cyclomatic 20) ext/node/polyfills/internal/util/inspect.mjs:654— styleText has cyclomatic complexity 20 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DenoDiagnostic::code (cyclomatic 19) cli/lsp/diagnostics.rs:759— DenoDiagnostic::code has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
TestCollector::visit_var_decl (cyclomatic 19) cli/lsp/testing/collectors.rs:581— TestCollector::visit_var_decl has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
GraphDiagnosticsCollector::collect_diagnostics_for_graph (cyclomatic 19) cli/tools/publish/graph.rs:40— GraphDiagnosticsCollector::collect_diagnostics_for_graph has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DiagnosticsByFolderRealIterator::check_diagnostics_in_folder (cyclomatic 19) cli/type_checker.rs:642— DiagnosticsByFolderRealIterator::check_diagnostics_in_folder has cyclomatic complexity 19 (threshold 15). Of this number, 18 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ZlibInner::do_write (cyclomatic 19) ext/node/ops/zlib/mod.rs:118— ZlibInner::do_write has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: deno_node::ops::zlib::encoder_param (cyclomatic 28) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
Args::parse (cyclomatic 19) libs/dcore/src/main.rs:168— Args::parse has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
SharedConn::poll_read_body_chunk_limited_inner (cyclomatic 19) libs/http_h1/conn.rs:928— SharedConn::poll_read_body_chunk_limited_inner has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
deno_inspector_server::server (cyclomatic 19) libs/inspector_server/lib.rs:646— deno_inspector_server::server has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
SerializedNpmResolutionSnapshot::dedup_equivalent_peer_variants (cyclomatic 19) libs/npm/resolution/snapshot.rs:205— SerializedNpmResolutionSnapshot::dedup_equivalent_peer_variants has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TtyPrompter::prompt (cyclomatic 19) runtime/permissions/prompter.rs:416— TtyPrompter::prompt has cyclomatic complexity 19 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_http_proxy.parseProxyUrl (cyclomatic 19) ext/node/polyfills/_http_proxy.js:104— _http_proxy.parseProxyUrl has cyclomatic complexity 19 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_http_proxy.parseNoProxy (cyclomatic 19) ext/node/polyfills/_http_proxy.js:203— _http_proxy.parseNoProxy has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_proxy.shouldBypassProxy (cyclomatic 19) ext/node/polyfills/_http_proxy.js:282— _http_proxy.shouldBypassProxy has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_server.ServerResponse.writeHead (cyclomatic 19) ext/node/polyfills/_http_server.js:498— _http_server.ServerResponse.writeHead has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
https.Agent.createConnection (cyclomatic 19) ext/node/polyfills/https.ts:370— https.Agent.createConnection has cyclomatic complexity 19 (threshold 15). Of this number, 18 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
EventTarget.[kHybridDispatch] (cyclomatic 19) ext/node/polyfills/internal/event_target.mjs:716— EventTarget.[kHybridDispatch] has cyclomatic complexity 19 (threshold 15). Of this number, 18 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
stream_base_commons.onStreamRead (cyclomatic 19) ext/node/polyfills/internal/stream_base_commons.ts:259— stream_base_commons.onStreamRead has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
duplexify._duplexify (cyclomatic 19) ext/node/polyfills/internal/streams/duplexify.js:281— duplexify._duplexify has cyclomatic complexity 19 (threshold 15). Most of this is not in the body itself: 6 of the 19 points are its own statements and the rest belongs to 9 function items inside it that branch (a function literal at line 380, onfinished, a function literal at line 396, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
comparisons.innerDeepEqual (cyclomatic 19) ext/node/polyfills/internal/util/comparisons.ts:262— comparisons.innerDeepEqual has cyclomatic complexity 19 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
adapters.newWritableStreamFromStreamWritable (cyclomatic 19) ext/node/polyfills/internal/webstreams/adapters.js:619— adapters.newWritableStreamFromStreamWritable has cyclomatic complexity 19 (threshold 15). Of this number, 13 points are the body's own statements and 6 belong to 2 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
prefer_primordials.insideVarDeclLhsOrMemberExprOrPropOrTypeRef (cyclomatic 19) tools/lint_plugins/prefer_primordials.ts:641— prefer_primordials.insideVarDeclLhsOrMemberExprOrPropOrTypeRef has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_wrapHandle (cyclomatic 19) ext/node/polyfills/_tls_wrap.js:575— _wrapHandle has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
onConnectSecure (cyclomatic 19) ext/node/polyfills/_tls_wrap.js:1568— onConnectSecure has cyclomatic complexity 19 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
(computed) (cyclomatic 19) ext/node/polyfills/internal/event_target.mjs:716— (computed) has cyclomatic complexity 19 (threshold 15). Of this number, 18 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
D1 · Cyclomatic Complexity· get (cyclomatic 19) · ×1
get (cyclomatic 19) ext/node/polyfills/internal/http2/compat.js:224— get has cyclomatic complexity 19 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
newStreamDuplexFromReadableWritablePair (cyclomatic 19) ext/node/polyfills/internal/webstreams/adapters.js:288— newStreamDuplexFromReadableWritablePair has cyclomatic complexity 19 (threshold 15). Most of this is not in the body itself: 5 of the 19 points are its own statements and the rest belongs to 23 function items inside it that branch (write, destroy, writev, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
#release (cyclomatic 19) ext/node/polyfills/internal/streams/fast-utf8-stream.js:354— #release has cyclomatic complexity 19 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
DenoTestStepCollector::visit_var_decl (cyclomatic 18) cli/lsp/code_lens.rs:448— DenoTestStepCollector::visit_var_decl has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TestStepCollector::visit_var_decl (cyclomatic 18) cli/lsp/testing/collectors.rs:443— TestStepCollector::visit_var_decl has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Http2Settings::init (cyclomatic 18) ext/node/ops/http2/session.rs:576— Http2Settings::init has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
ContextifyScript::eval_machine (cyclomatic 18) ext/node/ops/vm.rs:216— ContextifyScript::eval_machine has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
RuntimeActivityStats::diff (cyclomatic 18) libs/core/runtime/stats.rs:418— RuntimeActivityStats::diff has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
RegistryInfoProviderInner::create_load_future (cyclomatic 18) libs/npm_cache/registry_info.rs:295— RegistryInfoProviderInner::create_load_future has cyclomatic complexity 18 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
TarballCache::create_setup_future (cyclomatic 18) libs/npm_cache/tarball.rs:162— TarballCache::create_setup_future has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_lint.runPluginsForFile (cyclomatic 18) REDACTED:1224— 40_lint.runPluginsForFile has cyclomatic complexity 18 (threshold 15). Of this number, 14 points are the body's own statements and 4 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_serve.fastSyncResponseOrStream (cyclomatic 18) REDACTED:579— 00_serve.fastSyncResponseOrStream has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
00_serve.mapToNativeResponseCallback::finishOrReturnNative (cyclomatic 18) REDACTED:924— 00_serve.mapToNativeResponseCallback::finishOrReturnNative has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
00_serve.serveInner (cyclomatic 18) REDACTED:1293— 00_serve.serveInner has cyclomatic complexity 18 (threshold 15). Of this number, 10 points are the body's own statements and 8 belong to 4 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
01_require.Module.load (cyclomatic 18) ext/node/polyfills/01_require.js:1908— 01_require.Module.load has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_events.EventEmitter.emit (cyclomatic 18) ext/node/polyfills/_events.mjs:416— _events.EventEmitter.emit has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_server.storeHTTPOptions (cyclomatic 18) ext/node/polyfills/_http_server.js:1434— _http_server.storeHTTPOptions has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_tls_wrap.connect (cyclomatic 18) ext/node/polyfills/_tls_wrap.js:1650— _tls_wrap.connect has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ServerHttp2Stream.respondWithFD (cyclomatic 18) ext/node/polyfills/http2.ts:3275— ServerHttp2Stream.respondWithFD has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
http2.connect (cyclomatic 18) ext/node/polyfills/http2.ts:5345— http2.connect has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
child_process.findFirstNonFlagArg (cyclomatic 18) ext/node/polyfills/internal/child_process.ts:1700— child_process.findFirstNonFlagArg has cyclomatic complexity 18 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
keys.parseKeyEncoding (cyclomatic 18) ext/node/polyfills/internal/crypto/keys.ts:417— keys.parseKeyEncoding has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
parse_args.argsToTokens (cyclomatic 18) ext/node/polyfills/internal/util/parse_args/parse_args.js:179— parse_args.argsToTokens has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
net._afterConnectImpl (cyclomatic 18) ext/node/polyfills/net.ts:503— net._afterConnectImpl has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_posix.relative (cyclomatic 18) ext/node/polyfills/path/_posix.ts:167— _posix.relative has cyclomatic complexity 18 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_win32.extname (cyclomatic 18) ext/node/polyfills/path/_win32.ts:961— _win32.extname has cyclomatic complexity 18 (threshold 15). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
worker_threads.moveMessagePortToContext (cyclomatic 18) ext/node/polyfills/worker_threads.ts:1741— worker_threads.moveMessagePortToContext has cyclomatic complexity 18 (threshold 15). Most of this is not in the body itself: 5 of the 18 points are its own statements and the rest belongs to 6 function items inside it that branch (a function literal at line 1796, dispatchMessageError, dispatchMessage, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
02_event.innerInvokeEventListeners (cyclomatic 18) ext/web/02_event.js:737— 02_event.innerInvokeEventListeners has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
02_structured_clone.structuredClone (cyclomatic 18) ext/web/02_structured_clone.js:65— 02_structured_clone.structuredClone has cyclomatic complexity 18 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
02_timers.listOnTimeout (cyclomatic 18) libs/core/02_timers.js:270— 02_timers.listOnTimeout has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
generate_linux_function_orderfile.generate (cyclomatic 18) tools/startup_order/generate_linux_function_orderfile.ts:398— generate_linux_function_orderfile.generate has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
stripTypeScriptTypes (cyclomatic 18) ext/node/polyfills/01_require.js:3203— stripTypeScriptTypes has cyclomatic complexity 18 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
refresh (cyclomatic 18) libs/npm/resolution/tracing/app.js:71— refresh has cyclomatic complexity 18 (threshold 15). Most of this is not in the body itself: 3 of the 18 points are its own statements and the rest belongs to 26 function items inside it that branch (getNodesAndLinks, getNodesAndLinks::getNodeY, createGraph, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
createHttpClient (cyclomatic 18) ext/fetch/22_http_client.js:23— createHttpClient has cyclomatic complexity 18 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
WorkspaceSettings::from_raw_settings (cyclomatic 17) cli/lsp/config.rs:654— WorkspaceSettings::from_raw_settings has cyclomatic complexity 17 (threshold 15). Of this number, 15 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Compiler::to_path (cyclomatic 17) cli/lsp/path_to_regex.rs:822— Compiler::to_path has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
TsServer::provide_code_actions (cyclomatic 17) cli/lsp/ts_server.rs:325— TsServer::provide_code_actions has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
WorkspaceLinter::lint_files (cyclomatic 17) cli/tools/lint/mod.rs:292— WorkspaceLinter::lint_files has cyclomatic complexity 17 (threshold 15). Of this number, 16 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
TaskRunner::run_tasks_in_parallel (cyclomatic 17) cli/tools/task.rs:483— TaskRunner::run_tasks_in_parallel has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Session::send_pending_data (cyclomatic 17) ext/node/ops/http2/session.rs:2547— Session::send_pending_data has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
StatementSync::bind_params (cyclomatic 17) ext/node_sqlite/statement.rs:495— StatementSync::bind_params has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
CjsModuleExportAnalyzer::resolve (cyclomatic 17) libs/node_resolver/analyze.rs:517— CjsModuleExportAnalyzer::resolve has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
NpmPackageVersionResolver::strongest_trust_evidence_before (cyclomatic 17) libs/npm/resolution/common.rs:322— NpmPackageVersionResolver::strongest_trust_evidence_before has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
PreparedModuleLoader::load_prepared_module_or_defer_emit (cyclomatic 17) libs/resolver/loader/module_loader.rs:514— PreparedModuleLoader::load_prepared_module_or_defer_emit has cyclomatic complexity 17 (threshold 15). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Where every arm is uniform — the same kind of value, with no behaviour of its own — a table keyed by the case is the shorter form; wherever the arms carry different data or different behaviour, keep them as cases, because collapsing those trades an explicit, reviewable set of cases for nothing.
NetDescriptor::parse_inner (cyclomatic 17) runtime/permissions/lib.rs:2153— NetDescriptor::parse_inner has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_lint_selector.matchAttrValue (cyclomatic 17) REDACTED:1211— 40_lint_selector.matchAttrValue has cyclomatic complexity 17 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
97_ts_host.getModuleLiteralImportKind (cyclomatic 17) cli/tsc/97_ts_host.js:873— 97_ts_host.getModuleLiteralImportKind has cyclomatic complexity 17 (threshold 15). Of this number, 15 points are the body's own statements and 2 belong to 2 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
MultipartParser.parse (cyclomatic 17) ext/fetch/21_formdata.js:530— MultipartParser.parse has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_http_client.onSocketNT (cyclomatic 17) REDACTED:1556— _http_client.onSocketNT has cyclomatic complexity 17 (threshold 15). Of this number, 11 points are the body's own statements and 6 belong to 2 function items inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_tls_wrap.Server (cyclomatic 17) ext/node/polyfills/_tls_wrap.js:1384— _tls_wrap.Server has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
child_process.execFile::exithandler (cyclomatic 17) ext/node/polyfills/child_process.ts:626— child_process.execFile::exithandler has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: one other method here (child_process.execFile) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
fs.writeFile (cyclomatic 17) ext/node/polyfills/fs.ts:2765— fs.writeFile has cyclomatic complexity 17 (threshold 15). Of this number, 10 points are the body's own statements and 7 belong to 2 function literals inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ServerHttp2Stream.pushStream (cyclomatic 17) ext/node/polyfills/http2.ts:3085— ServerHttp2Stream.pushStream has cyclomatic complexity 17 (threshold 15). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ServerHttp2Session.altsvc (cyclomatic 17) ext/node/polyfills/http2.ts:4575— ServerHttp2Session.altsvc has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
http2.closeStream (cyclomatic 17) ext/node/polyfills/http2.ts:1855— http2.closeStream has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.createIpcHandle (cyclomatic 17) ext/node/polyfills/internal/child_process.ts:2435— child_process.createIpcHandle has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
scrypt.check (cyclomatic 17) ext/node/polyfills/internal/crypto/scrypt.ts:129— scrypt.check has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
streams.WriteStream (cyclomatic 17) ext/node/polyfills/internal/fs/streams.mjs:392— streams.WriteStream has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
address_override.startOverrideListener (cyclomatic 17) ext/node/polyfills/internal/http/address_override.js:513— address_override.startOverrideListener has cyclomatic complexity 17 (threshold 15). Most of this is not in the body itself: 3 of the 17 points are its own statements and the rest belongs to 4 function literals inside it that branch (lines 534, 552, 574, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
warning.onWarning (cyclomatic 17) ext/node/polyfills/internal/process/warning.ts:18— warning.onWarning has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
destroy.errorOrDestroy (cyclomatic 17) ext/node/polyfills/internal/streams/destroy.js:212— destroy.errorOrDestroy has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Utf8Stream.constructor (cyclomatic 17) ext/node/polyfills/internal/streams/fast-utf8-stream.js:103— Utf8Stream.constructor has cyclomatic complexity 17 (threshold 15). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
writable.WritableState (cyclomatic 17) ext/node/polyfills/internal/streams/writable.js:350— writable.WritableState has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
writable._write (cyclomatic 17) ext/node/polyfills/internal/streams/writable.js:536— writable._write has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
comparisons.mapObjectEquiv (cyclomatic 17) ext/node/polyfills/internal/util/comparisons.ts:1031— comparisons.mapObjectEquiv has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
perf_hooks.timerify (cyclomatic 17) ext/node/polyfills/perf_hooks.js:216— perf_hooks.timerify has cyclomatic complexity 17 (threshold 15). Most of this is not in the body itself: 7 of the 17 points are its own statements and the rest belongs to one function item inside it that branches (timerified). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
WASI.constructor (cyclomatic 17) ext/node/polyfills/wasi.ts:145— WASI.constructor has cyclomatic complexity 17 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
worker_threads.postMessageToThread (cyclomatic 17) ext/node/polyfills/worker_threads.ts:1597— worker_threads.postMessageToThread has cyclomatic complexity 17 (threshold 15). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
01_mimesniff.parseMimeType (cyclomatic 17) ext/web/01_mimesniff.js:50— 01_mimesniff.parseMimeType has cyclomatic complexity 17 (threshold 15). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
Event.composedPath (cyclomatic 17) ext/web/02_event.js:209— Event.composedPath has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
PerformanceObserver.observe (cyclomatic 17) ext/web/15_performance.js:503— PerformanceObserver.observe has cyclomatic complexity 17 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
10_permissions.cache (cyclomatic 17) runtime/js/10_permissions.js:134— 10_permissions.cache has cyclomatic complexity 17 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
fetch (cyclomatic 17) ext/fetch/26_fetch.js:831— fetch has cyclomatic complexity 17 (threshold 15). Most of this is not in the body itself: 5 of the 17 points are its own statements and the rest belongs to 8 function items inside it that branch (a function literal at line 846, a function literal at line 904, a function literal at line 946, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
DocumentModules::workspace_file_modules_by_scope (cyclomatic 16) cli/lsp/documents.rs:1556— DocumentModules::workspace_file_modules_by_scope has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: LanguageId::as_extension (cyclomatic 19) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
CompletionEntryDetails::as_completion_item (cyclomatic 16) cli/lsp/tsc.rs:3992— CompletionEntryDetails::as_completion_item has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: TscRequest::into_server_request (cyclomatic 30) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded function is counted neither in this dimension's figures nor in its score.
RecursiveModuleLoad::register_and_recurse_inner (cyclomatic 16) libs/core/modules/recursive_load.rs:426— RecursiveModuleLoad::register_and_recurse_inner has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
40_lint_selector.getFromRawValue (cyclomatic 16) REDACTED:387— 40_lint_selector.getFromRawValue has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: 40_lint_selector.compileSelector (cyclomatic 17) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded method is counted neither in this dimension's figures nor in its score.
01_cron.cron (cyclomatic 16) ext/cron/01_cron.ts:108— 01_cron.cron has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 7 of the 16 points are its own statements and the rest belongs to one function literal inside it that branches (line 165). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
01_require.parseMappings (cyclomatic 16) ext/node/polyfills/01_require.js:2766— 01_require.parseMappings has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_events.EventEmitter.removeListener (cyclomatic 16) ext/node/polyfills/_events.mjs:646— _events.EventEmitter.removeListener has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_tls_common.getProtocolRange (cyclomatic 16) ext/node/polyfills/_tls_common.ts:290— _tls_common.getProtocolRange has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
_tls_wrap.checkServerIdentity (cyclomatic 16) ext/node/polyfills/_tls_wrap.js:1863— _tls_wrap.checkServerIdentity has cyclomatic complexity 16 (threshold 15). Of this number, 14 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
http2.closeSession (cyclomatic 16) ext/node/polyfills/http2.ts:3819— http2.closeSession has cyclomatic complexity 16 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
buffer.bidirectionalIndexOf (cyclomatic 16) ext/node/polyfills/internal/buffer.mjs:970— buffer.bidirectionalIndexOf has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
buffer.Buffer.hexSlice (cyclomatic 16) ext/node/polyfills/internal/buffer.mjs:1256— buffer.Buffer.hexSlice has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
ChildProcess.kill (cyclomatic 16) ext/node/polyfills/internal/child_process.ts:829— ChildProcess.kill has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
child_process.normalizeStdioOption (cyclomatic 16) ext/node/polyfills/internal/child_process.ts:1070— child_process.normalizeStdioOption has cyclomatic complexity 16 (threshold 15). To reduce it, separate the branches: extract each independent case into its own named function so the top-level body reads as a short sequence of named decisions.
child_process.setupChannel::readLoop (cyclomatic 16) ext/node/polyfills/internal/child_process.ts:2788— child_process.setupChannel::readLoop has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
cipher.Decipheriv (cyclomatic 16) ext/node/polyfills/internal/crypto/cipher.ts:496— cipher.Decipheriv has cyclomatic complexity 16 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
hash.Hash (cyclomatic 16) ext/node/polyfills/internal/crypto/hash.ts:81— hash.Hash has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
random.validateRandomPrimeJob (cyclomatic 16) ext/node/polyfills/internal/crypto/random.ts:261— random.validateRandomPrimeJob has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
MIMEParams.#parse (cyclomatic 16) REDACTED:241— MIMEParams.#parse has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
stream_base_commons.writevGeneric (cyclomatic 16) ext/node/polyfills/internal/stream_base_commons.ts:168— stream_base_commons.writevGeneric has cyclomatic complexity 16 (threshold 15). To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
Utf8Stream.#openFile (cyclomatic 16) ext/node/polyfills/internal/streams/fast-utf8-stream.js:440— Utf8Stream.#openFile has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 6 of the 16 points are its own statements and the rest belongs to 3 function items inside it that branch (fileOpened, a function literal at line 452, a function literal at line 505). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
ChannelWrap.#resolve (cyclomatic 16) ext/node/polyfills/internal_binding/cares_wrap.ts:363— ChannelWrap.#resolve has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top. This is NOT this file's highest cyclomatic complexity: ChannelWrap.queryAny (cyclomatic 17) is higher and carries no row of its own — it was excluded as a flat dispatcher (a long switch/match over independent cases: many branches, almost no nesting), which this dimension does not treat as a refactor obligation. It is named here so the ranking you see in this file is not mistaken for the whole of it; the excluded method is counted neither in this dimension's figures nor in its score.
net._setupListenHandle (cyclomatic 16) ext/node/polyfills/net.ts:2681— net._setupListenHandle has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
repl.isRecoverableError (cyclomatic 16) ext/node/polyfills/repl.ts:375— repl.isRecoverableError has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
MockTimers.enable (cyclomatic 16) ext/node/polyfills/testing.ts:2644— MockTimers.enable has cyclomatic complexity 16 (threshold 15). To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
timers.setIntervalAsync (cyclomatic 16) ext/node/polyfills/timers.ts:278— timers.setIntervalAsync has cyclomatic complexity 16 (threshold 15). Of this number, 14 points are the body's own statements and 2 belong to 2 function items inside it that branch. To reduce it, split the body: these branches sit side by side rather than nested inside one another, so extracting each one on its own would leave a function per branch. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
url.formatWhatwg (cyclomatic 16) ext/node/polyfills/url.ts:1060— url.formatWhatwg has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
url.pathToFileURL (cyclomatic 16) ext/node/polyfills/url.ts:1609— url.pathToFileURL has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
zlib.processCallback (cyclomatic 16) ext/node/polyfills/zlib.js:667— zlib.processCallback has cyclomatic complexity 16 (threshold 15). Of this number, 12 points are the body's own statements and 4 belong to 2 function literals inside it that branch. To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
06_streams.readableStreamDefaultTee (cyclomatic 16) ext/web/06_streams.js:3727— 06_streams.readableStreamDefaultTee has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 5 of the 16 points are its own statements and the rest belongs to 5 function items inside it that branch (chunkStepsMicrotask, a function literal at line 3887, pullAlgorithm, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
WebSocket.[_eventLoop] (cyclomatic 16) ext/websocket/01_websocket.js:754— WebSocket.[_eventLoop] has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
flamegraph.search (cyclomatic 16) REDACTED:294— flamegraph.search has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
lint.ensureNoUnusedOutFiles (cyclomatic 16) tools/lint.js:604— lint.ensureNoUnusedOutFiles has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 5 of the 16 points are its own statements and the rest belongs to one function item inside it that branches (checkObject). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
writableStreamForRid (cyclomatic 16) ext/web/06_streams.js:1486— writableStreamForRid has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 7 of the 16 points are its own statements and the rest belongs to 7 function items inside it that branch (write, tryClose, flushBuffer, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
(computed) (cyclomatic 16) ext/websocket/01_websocket.js:754— (computed) has cyclomatic complexity 16 (threshold 15). To reduce it, separate the cases: extract each independent branch into its own named function, and where the body has guards that only reject input, fold those into early returns at the top.
newReadableStreamFromStreamReadable (cyclomatic 16) ext/node/polyfills/internal/webstreams/adapters.js:488— newReadableStreamFromStreamReadable has cyclomatic complexity 16 (threshold 15). Most of this is not in the body itself: 6 of the 16 points are its own statements and the rest belongs to 8 function items inside it that branch (evaluateStrategyOrFallback, onData, a function literal at line 578, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
HackComment tests/unit/request_test.ts:45— // hack to get a stream — a workaround marked in source: record what it is compensating for and what would allow its removal (the upstream fix, the API it is waiting on, the invariant it restores), so the next reader can judge whether it is still needed rather than rediscovering why it is there.
TodoComment repeated across 17 files ext/webgpu/bind_group.rs:66— The identical TodoComment appears in 17 files (19 occurrences) — almost certainly one boilerplate line from a single migration or decision, not 19 independent debts. Fix the systemic cause once rather than file-by-file. Text: "// TODO(@crowlKats): no-op, needs wpgu to implement changing the label". Source code is not a task system: track the cleanup where tasks live. (Every occurrence still counts toward the score and metrics.)
Glob.#iterateSubpatterns (cognitive 275) ext/node/polyfills/_fs/_fs_glob.ts:880— Glob.#iterateSubpatterns has cognitive complexity 275 (threshold 15). Drivers by points: if/else 53 (177 pts), ternaries 8 (54 pts), boolean chains 37, loops 3 (7 pts) (nesting depth added 174). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
OptionsParser::parse (cognitive 205) libs/node_shim/lib.rs:2801— OptionsParser::parse has cognitive complexity 205 (threshold 15). Drivers by points: if/else 59 (159 pts), loops 7 (34 pts), boolean chains 9, match/switch 1 (3 pts) (nesting depth added 129). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
LocalNpmPackageInstaller::sync_resolution_with_fs (cognitive 188) libs/npm_installer/local.rs:199— LocalNpmPackageInstaller::sync_resolution_with_fs has cognitive complexity 188 (threshold 15). Drivers by points: if/else 53 (128 pts), loops 19 (25 pts), match/switch 8 (18 pts), boolean chains 17 (nesting depth added 91). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleRegistry::get_completions (cognitive 170) cli/lsp/registries.rs:662— ModuleRegistry::get_completions has cognitive complexity 170 (threshold 15). Drivers by points: if/else 31 (132 pts), loops 4 (16 pts), match/switch 4 (15 pts), boolean chains 7 (nesting depth added 124). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Url.resolveObject (cognitive 152) ext/node/polyfills/url.ts:262— Url.resolveObject has cognitive complexity 152 (threshold 15). Drivers by points: if/else 48 (85 pts), boolean chains 53, loops 6 (12 pts), ternaries 1 (2 pts) (nesting depth added 44). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Glob.#addSubpatterns (cognitive 143) ext/node/polyfills/_fs/_fs_glob.ts:618— Glob.#addSubpatterns has cognitive complexity 143 (threshold 15). Drivers by points: if/else 39 (101 pts), boolean chains 35, loops 3 (7 pts) (nesting depth added 66). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
Url.urlParse (cognitive 141) ext/node/polyfills/url.ts:666— Url.urlParse has cognitive complexity 141 (threshold 15). Drivers by points: if/else 56 (107 pts), boolean chains 21, match/switch 2 (6 pts), loops 3 (4 pts), ternaries 2 (3 pts) (nesting depth added 57). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
JsRuntimeInspectorState::poll_sessions (cognitive 137) libs/core/inspector.rs:522— JsRuntimeInspectorState::poll_sessions has cognitive complexity 137 (threshold 15). Drivers by points: if/else 23 (101 pts), match/switch 6 (18 pts), loops 5 (15 pts), boolean chains 3 (nesting depth added 100). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
NpmInstallDepsProvider::from_workspace (cognitive 129) libs/npm_installer/package_json.rs:161— NpmInstallDepsProvider::from_workspace has cognitive complexity 129 (threshold 15). Drivers by points: if/else 28 (100 pts), match/switch 3 (14 pts), loops 4 (9 pts), boolean chains 6 (nesting depth added 88). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
ClientRequest (cognitive 129) REDACTED:505— ClientRequest has cognitive complexity 129 (threshold 15). Drivers by points: if/else 56 (83 pts), boolean chains 27, ternaries 4 (11 pts), error handling 2 (5 pts), loops 1 (3 pts) (nesting depth added 39). Of this number, 125 points are the body's own statements and 4 belong to 2 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Lockfile::set_workspace_config (cognitive 127) libs/lockfile/lib.rs:835— Lockfile::set_workspace_config has cognitive complexity 127 (threshold 15). Drivers by points: if/else 28 (92 pts), loops 10 (25 pts), boolean chains 5, match/switch 1 (5 pts) (nesting depth added 83). Of this number, 125 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
JsError::inner_from_v8_exception (cognitive 124) libs/core/error.rs:1016— JsError::inner_from_v8_exception has cognitive complexity 124 (threshold 15). Drivers by points: if/else 31 (87 pts), match/switch 5 (16 pts), loops 4 (13 pts), boolean chains 8 (nesting depth added 76). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
parse (cognitive 124) ext/node/polyfills/querystring.js:111— parse has cognitive complexity 124 (threshold 15). Drivers by points: if/else 37 (116 pts), ternaries 4 (5 pts), boolean chains 2, loops 1 (nesting depth added 80). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
benchMeasure (cognitive 119) cli/js/40_bench.js:244— benchMeasure has cognitive complexity 119 (threshold 15). Drivers by points: if/else 28 (86 pts), loops 8 (24 pts), boolean chains 6, ternaries 3 (nesting depth added 74). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_incoming.matchKnownFields (cognitive 113) ext/node/polyfills/_http_incoming.js:259— _http_incoming.matchKnownFields has cognitive complexity 113 (threshold 15). Drivers by points: if/else 38 (75 pts), boolean chains 37, match/switch 1 (nesting depth added 37). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
pipeline.pipelineImpl (cognitive 113) ext/node/polyfills/internal/streams/pipeline.js:210— pipeline.pipelineImpl has cognitive complexity 113 (threshold 15). Drivers by points: if/else 44 (91 pts), boolean chains 18, loops 2, ternaries 1 (2 pts) (nesting depth added 48). Of this number, 90 points are the body's own statements and 23 belong to 3 function items inside it that branch. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
_win32.resolve (cognitive 108) ext/node/polyfills/path/_win32.ts:91— _win32.resolve has cognitive complexity 108 (threshold 15). Drivers by points: if/else 27 (72 pts), boolean chains 19, loops 4 (16 pts), ternaries 1 (nesting depth added 57). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
ChildProcess.#spawnInternal (cognitive 106) ext/node/polyfills/internal/child_process.ts:369— ChildProcess.#spawnInternal has cognitive complexity 106 (threshold 15). Drivers by points: if/else 45 (81 pts), boolean chains 13, ternaries 5, loops 3 (4 pts), error handling 2 (3 pts) (nesting depth added 38). Of this number, 88 points are the body's own statements and 18 belong to 4 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.objectComparisonStart (cognitive 105) ext/node/polyfills/internal/util/comparisons.ts:302— comparisons.objectComparisonStart has cognitive complexity 105 (threshold 15). Drivers by points: if/else 45 (72 pts), boolean chains 29, ternaries 2 (4 pts) (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_win32.parse (cognitive 104) ext/node/polyfills/path/_win32.ts:1040— _win32.parse has cognitive complexity 104 (threshold 15). Drivers by points: if/else 31 (83 pts), loops 4 (16 pts), boolean chains 5 (nesting depth added 64). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_load (cognitive 104) ext/node/polyfills/01_require.js:1412— _load has cognitive complexity 104 (threshold 15). Drivers by points: if/else 39 (84 pts), boolean chains 14, loops 1 (3 pts), ternaries 1 (2 pts), error handling 1 (nesting depth added 48). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
NodeWorker.constructor (cognitive 101) ext/node/polyfills/worker_threads.ts:291— NodeWorker.constructor has cognitive complexity 101 (threshold 15). Drivers by points: if/else 31 (68 pts), loops 5 (12 pts), boolean chains 10, ternaries 2 (9 pts), error handling 1 (2 pts) (nesting depth added 52). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
40_lint_selector.parseSelector (cognitive 97) REDACTED:475— 40_lint_selector.parseSelector has cognitive complexity 97 (threshold 15). Drivers by points: if/else 29 (82 pts), loops 3 (7 pts), match/switch 1 (3 pts), ternaries 1 (3 pts), boolean chains 2 (nesting depth added 61). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
mainFetch (cognitive 94) ext/fetch/26_fetch.js:386— mainFetch has cognitive complexity 94 (threshold 15). Drivers by points: if/else 39 (60 pts), boolean chains 14, error handling 3 (8 pts), ternaries 3 (8 pts), match/switch 1 (2 pts), other 2 (nesting depth added 32). Of this number, 90 points are the body's own statements and 4 belong to 4 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
keygen.createJob (cognitive 93) ext/node/polyfills/internal/crypto/keygen.ts:390— keygen.createJob has cognitive complexity 93 (threshold 15). Drivers by points: if/else 44 (86 pts), boolean chains 4, ternaries 1 (2 pts), match/switch 1 (nesting depth added 43). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
compose (cognitive 93) ext/node/polyfills/internal/streams/compose.js:39— compose has cognitive complexity 93 (threshold 15). Drivers by points: if/else 29 (53 pts), error handling 5 (16 pts), boolean chains 9, ternaries 3 (8 pts), loops 3 (7 pts) (nesting depth added 44). Of this number, 34 points are the body's own statements and 59 belong to 14 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_init (cognitive 91) ext/node/polyfills/_tls_wrap.js:717— _init has cognitive complexity 91 (threshold 15). Drivers by points: if/else 34 (74 pts), boolean chains 13, ternaries 2 (4 pts) (nesting depth added 42). Of this number, 19 points are the body's own statements and 72 belong to 11 function items inside it that branch. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
Console::table_impl (cognitive 90) ext/web/console/mod.rs:1421— Console::table_impl has cognitive complexity 90 (threshold 15). Drivers by points: if/else 24 (41 pts), match/switch 11 (27 pts), loops 7 (15 pts), boolean chains 7 (nesting depth added 41). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
http2.onSessionHeaders (cognitive 88) ext/node/polyfills/http2.ts:1517— http2.onSessionHeaders has cognitive complexity 88 (threshold 15). Drivers by points: if/else 34 (78 pts), boolean chains 6, loops 1 (4 pts) (nesting depth added 47). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
_win32.normalize (cognitive 88) ext/node/polyfills/path/_win32.ts:275— _win32.normalize has cognitive complexity 88 (threshold 15). Drivers by points: if/else 24 (54 pts), boolean chains 14, loops 4 (14 pts), ternaries 4 (6 pts) (nesting depth added 42). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_win32.dirname (cognitive 88) ext/node/polyfills/path/_win32.ts:777— _win32.dirname has cognitive complexity 88 (threshold 15). Drivers by points: if/else 22 (70 pts), loops 4 (16 pts), boolean chains 2 (nesting depth added 60). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
_resolveFilename (cognitive 87) ext/node/polyfills/01_require.js:1657— _resolveFilename has cognitive complexity 87 (threshold 15). Drivers by points: if/else 26 (47 pts), loops 5 (17 pts), boolean chains 11, error handling 2 (6 pts), ternaries 3 (5 pts), other 1 (nesting depth added 39). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
createRespondWith::respondWith (cognitive 87) ext/http/01_http.js:197— createRespondWith::respondWith has cognitive complexity 87 (threshold 15). Drivers by points: if/else 29 (63 pts), error handling 5 (12 pts), boolean chains 7, loops 1 (3 pts), other 1, ternaries 1 (nesting depth added 43). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
01_http.createRespondWith (cognitive 86) ext/http/01_http.js:191— 01_http.createRespondWith has cognitive complexity 86 (threshold 15). Drivers by points: if/else 29 (63 pts), error handling 5 (12 pts), boolean chains 7, loops 1 (3 pts), ternaries 1 (nesting depth added 43). None of this is in the body itself: all 86 points belong to one function literal inside it that branches (line 197). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
99_main.bootstrapMainRuntime (cognitive 86) runtime/js/99_main.js:936— 99_main.bootstrapMainRuntime has cognitive complexity 86 (threshold 15). Drivers by points: if/else 24 (60 pts), ternaries 3 (12 pts), boolean chains 7, error handling 1 (5 pts), loops 1 (2 pts) (nesting depth added 50). Of this number, 40 points are the body's own statements and 46 belong to one function literal inside it that branches. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
node_shim::translate_to_deno_args (cognitive 80) libs/node_shim/lib.rs:3470— node_shim::translate_to_deno_args has cognitive complexity 80 (threshold 15). Drivers by points: if/else 45 (70 pts), boolean chains 7, loops 3 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ClientHttp2Session.request (cognitive 80) ext/node/polyfills/http2.ts:4684— ClientHttp2Session.request has cognitive complexity 80 (threshold 15). Drivers by points: if/else 36 (58 pts), loops 5 (16 pts), boolean chains 5, error handling 1 (nesting depth added 33). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
constructor (cognitive 79) ext/node/polyfills/internal/assert/assertion_error.js:323— constructor has cognitive complexity 79 (threshold 15). Drivers by points: if/else 25 (52 pts), boolean chains 17, loops 2 (6 pts), ternaries 1 (4 pts) (nesting depth added 34). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
string_decoder.decode (cognitive 78) ext/node/polyfills/string_decoder.ts:130— string_decoder.decode has cognitive complexity 78 (threshold 15). Drivers by points: if/else 25 (65 pts), loops 2 (8 pts), boolean chains 5 (nesting depth added 46). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
FileReader.#readOperation (cognitive 78) ext/web/10_filereader.js:73— FileReader.#readOperation has cognitive complexity 78 (threshold 15). Drivers by points: if/else 18 (55 pts), error handling 3 (14 pts), loops 2 (4 pts), match/switch 1 (3 pts), boolean chains 2 (nesting depth added 52). Most of this is not in the body itself: 1 of the 78 points is its own statement and the rest belongs to 7 function literals inside it that branch (lines 165, 111, 244, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
emitKeys (cognitive 77) ext/node/polyfills/internal/readline/utils.mjs:121— emitKeys has cognitive complexity 77 (threshold 15). Drivers by points: if/else 25 (55 pts), boolean chains 12, ternaries 2 (6 pts), match/switch 1 (3 pts), loops 1 (nesting depth added 36). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
constructor (cognitive 75) ext/websocket/01_websocket.js:253— constructor has cognitive complexity 75 (threshold 15). Drivers by points: if/else 31 (50 pts), error handling 4 (8 pts), boolean chains 7, loops 2 (6 pts), other 3, ternaries 1 (nesting depth added 27). Of this number, 58 points are the body's own statements and 17 belong to 5 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
HoistedNpmPackageInstaller::sync_resolution_with_fs (cognitive 74) libs/npm_installer/hoisted.rs:349— HoistedNpmPackageInstaller::sync_resolution_with_fs has cognitive complexity 74 (threshold 15). Drivers by points: if/else 20 (48 pts), loops 12 (15 pts), match/switch 3 (6 pts), boolean chains 5 (nesting depth added 34). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
D2 · Cognitive Complexity· eos (cognitive 74) · ×1
eos (cognitive 74) ext/node/polyfills/internal/streams/end-of-stream.js:67— eos has cognitive complexity 74 (threshold 15). Drivers by points: if/else 36 (42 pts), boolean chains 30, other 2 (nesting depth added 6). Of this number, 46 points are the body's own statements and 28 belong to 11 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
TsResponseImportMapper::check_specifier (cognitive 73) cli/lsp/analysis.rs:367— TsResponseImportMapper::check_specifier has cognitive complexity 73 (threshold 15). Drivers by points: if/else 26 (61 pts), boolean chains 6, loops 2 (5 pts), match/switch 1 (nesting depth added 38). Of this number, 72 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
worker_threads.internals.__initWorkerThreads (cognitive 72) ext/node/polyfills/worker_threads.ts:986— worker_threads.internals.__initWorkerThreads has cognitive complexity 72 (threshold 15). Drivers by points: if/else 22 (58 pts), loops 2 (10 pts), boolean chains 3, error handling 1 (nesting depth added 44). Of this number, 64 points are the body's own statements and 8 belong to 9 function items inside it that branch. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
NpmRc::parse (cognitive 71) libs/npmrc/lib.rs:200— NpmRc::parse has cognitive complexity 71 (threshold 15). Drivers by points: if/else 14 (41 pts), match/switch 5 (23 pts), boolean chains 6, loops 1 (nesting depth added 45). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
ConfiguredDepResolutions::new (cognitive 69) cli/lsp/resolver.rs:784— ConfiguredDepResolutions::new has cognitive complexity 69 (threshold 15). Drivers by points: if/else 19 (55 pts), loops 6 (13 pts), boolean chains 1 (nesting depth added 43). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_server.parserOnIncoming (cognitive 66) ext/node/polyfills/_http_server.js:950— _http_server.parserOnIncoming has cognitive complexity 66 (threshold 15). Drivers by points: if/else 28 (41 pts), boolean chains 14, ternaries 4 (8 pts), loops 1 (3 pts) (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Interface.[kTtyWrite] (cognitive 65) ext/node/polyfills/internal/readline/interface.mjs:1093— Interface.[kTtyWrite] has cognitive complexity 65 (threshold 15). Drivers by points: if/else 23 (43 pts), boolean chains 10, match/switch 4 (8 pts), loops 1 (4 pts) (nesting depth added 27). Of this number, 61 points are the body's own statements and 4 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(computed) (cognitive 65) ext/node/polyfills/internal/readline/interface.mjs:1093— (computed) has cognitive complexity 65 (threshold 15). Drivers by points: if/else 23 (43 pts), boolean chains 10, match/switch 4 (8 pts), loops 1 (4 pts) (nesting depth added 27). Of this number, 61 points are the body's own statements and 4 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
formatWithOptionsInternal (cognitive 65) ext/node/polyfills/internal/util/inspect.mjs:479— formatWithOptionsInternal has cognitive complexity 65 (threshold 15). Drivers by points: if/else 20 (53 pts), match/switch 1 (5 pts), loops 2 (3 pts), boolean chains 2, ternaries 1 (2 pts) (nesting depth added 39). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
serverRequestInner (cognitive 65) cli/tsc/98_lsp.js:428— serverRequestInner has cognitive complexity 65 (threshold 15). Drivers by points: if/else 13 (30 pts), loops 6 (16 pts), ternaries 3 (9 pts), error handling 2 (5 pts), boolean chains 2, other 2, match/switch 1 (nesting depth added 36). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Prime::generate_with_options (cognitive 64) ext/node_crypto/primes.rs:42— Prime::generate_with_options has cognitive complexity 64 (threshold 15). Drivers by points: if/else 27 (57 pts), loops 2 (4 pts), boolean chains 3 (nesting depth added 32). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_win32.relative (cognitive 64) ext/node/polyfills/path/_win32.ts:565— _win32.relative has cognitive complexity 64 (threshold 15). Drivers by points: if/else 26 (47 pts), loops 7 (8 pts), boolean chains 6, ternaries 2 (3 pts) (nesting depth added 23). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
update_types_node.modifySourceFiles (cognitive 64) tools/update_types_node.ts:125— update_types_node.modifySourceFiles has cognitive complexity 64 (threshold 15). Drivers by points: if/else 17 (43 pts), loops 8 (18 pts), boolean chains 3 (nesting depth added 36). Of this number, 53 points are the body's own statements and 11 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
util.updateSettingsBuffer (cognitive 63) ext/node/polyfills/internal/http2/util.ts:384— util.updateSettingsBuffer has cognitive complexity 63 (threshold 15). Drivers by points: if/else 18 (47 pts), loops 2 (7 pts), match/switch 1 (5 pts), boolean chains 4 (nesting depth added 38). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
setUpAsyncStub (cognitive 62) libs/core/00_infra.js:211— setUpAsyncStub has cognitive complexity 62 (threshold 15). Drivers by points: if/else 21 (41 pts), error handling 10 (20 pts), match/switch 1 (nesting depth added 30). Most of this is not in the body itself: 2 of the 62 points are its own statements and the rest belongs to 10 function items inside it that branch (async_op_0, async_op_1, async_op_2, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
constructor (cognitive 62) ext/websocket/02_websocketstream.js:106— constructor has cognitive complexity 62 (threshold 15). Drivers by points: if/else 19 (37 pts), error handling 4 (12 pts), boolean chains 3, loops 1 (3 pts), match/switch 1 (3 pts), other 2, ternaries 1 (2 pts) (nesting depth added 31). Most of this is not in the body itself: 10 of the 62 points are its own statements and the rest belongs to 18 function items inside it that branch ((anonymous)::pull, a function literal at line 181, a function literal at line 188, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
dispatch (cognitive 60) ext/web/02_event.js:566— dispatch has cognitive complexity 60 (threshold 15). Drivers by points: if/else 15 (36 pts), boolean chains 13, loops 4 (8 pts), ternaries 1 (2 pts), other 1 (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Cipher::new (cognitive 59) ext/node_crypto/cipher.rs:826— Cipher::new has cognitive complexity 59 (threshold 15). Drivers by points: if/else 29 (54 pts), match/switch 2 (3 pts), boolean chains 2 (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (Decipher::new) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
_win32.basename (cognitive 59) ext/node/polyfills/path/_win32.ts:872— _win32.basename has cognitive complexity 59 (threshold 15). Drivers by points: if/else 21 (52 pts), loops 2 (4 pts), boolean chains 3 (nesting depth added 33). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
constructor (cognitive 59) ext/fetch/23_request.js:370— constructor has cognitive complexity 59 (threshold 15). Drivers by points: if/else 32 (41 pts), boolean chains 11, other 4, error handling 1 (3 pts) (nesting depth added 11). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
TestServer::new (cognitive 58) cli/lsp/testing/server.rs:63— TestServer::new has cognitive complexity 58 (threshold 15). Drivers by points: if/else 11 (40 pts), loops 4 (8 pts), match/switch 3 (8 pts), boolean chains 2 (nesting depth added 38). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
assert.expectedException (cognitive 58) ext/node/polyfills/assert.ts:188— assert.expectedException has cognitive complexity 58 (threshold 15). Drivers by points: if/else 22 (47 pts), boolean chains 4, ternaries 1 (4 pts), loops 1 (3 pts) (nesting depth added 30). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
REPLServer._handleError (cognitive 58) ext/node/polyfills/repl.ts:1676— REPLServer._handleError has cognitive complexity 58 (threshold 15). Drivers by points: if/else 18 (43 pts), loops 2 (8 pts), boolean chains 5, ternaries 1 (2 pts) (nesting depth added 32). Of this number, 55 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
06_streams.readableByteStreamTee (cognitive 58) ext/web/06_streams.js:3913— 06_streams.readableByteStreamTee has cognitive complexity 58 (threshold 15). Drivers by points: if/else 36 (40 pts), ternaries 8, boolean chains 6, error handling 2 (4 pts) (nesting depth added 6). Of this number, 23 points are the body's own statements and 35 belong to 10 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
SerializedNpmResolutionSnapshot::dedup_equivalent_peer_variants (cognitive 56) libs/npm/resolution/snapshot.rs:205— SerializedNpmResolutionSnapshot::dedup_equivalent_peer_variants has cognitive complexity 56 (threshold 15). Drivers by points: if/else 8 (30 pts), loops 10 (26 pts) (nesting depth added 38). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
normalize_encoding.slowCases (cognitive 55) ext/node/polyfills/internal/normalize_encoding.ts:13— normalize_encoding.slowCases has cognitive complexity 55 (threshold 15). Drivers by points: if/else 23 (46 pts), boolean chains 8, match/switch 1 (nesting depth added 23). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
PackageJson::load_from_value (cognitive 54) libs/package_json/lib.rs:510— PackageJson::load_from_value has cognitive complexity 54 (threshold 15). Drivers by points: if/else 20 (33 pts), loops 5 (10 pts), match/switch 8 (10 pts), boolean chains 1 (nesting depth added 20). Of this number, 41 points are the body's own statements and 13 belong to 5 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
prefer_primordials.buildScopeTreeFixed::visit (cognitive 54) tools/lint_plugins/prefer_primordials.ts:388— prefer_primordials.buildScopeTreeFixed::visit has cognitive complexity 54 (threshold 15). Drivers by points: if/else 18 (35 pts), loops 6 (13 pts), boolean chains 3, ternaries 1 (2 pts), match/switch 1 (nesting depth added 25). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LockfileContent::from_json (cognitive 53) libs/lockfile/lib.rs:384— LockfileContent::from_json has cognitive complexity 53 (threshold 15). Drivers by points: loops 10 (23 pts), if/else 10 (22 pts), match/switch 5 (7 pts), boolean chains 1 (nesting depth added 27). Of this number, 45 points are the body's own statements and 8 belong to 3 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
40_lint.runPluginsForFile (cognitive 53) REDACTED:1224— 40_lint.runPluginsForFile has cognitive complexity 53 (threshold 15). Drivers by points: if/else 7 (25 pts), loops 6 (12 pts), error handling 2 (9 pts), ternaries 3 (7 pts) (nesting depth added 35). Of this number, 42 points are the body's own statements and 11 belong to 4 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_posix.basename (cognitive 53) ext/node/polyfills/path/_posix.ts:281— _posix.basename has cognitive complexity 53 (threshold 15). Drivers by points: if/else 18 (46 pts), loops 2 (4 pts), boolean chains 3 (nesting depth added 30). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
D2 · Cognitive Complexity· from (cognitive 53) · ×1
from (cognitive 53) ext/node/polyfills/internal/streams/from.js:22— from has cognitive complexity 53 (threshold 15). Drivers by points: if/else 23 (35 pts), error handling 4 (7 pts), boolean chains 6, loops 3, ternaries 1 (2 pts) (nesting depth added 16). Most of this is not in the body itself: 5 of the 53 points are its own statements and the rest belongs to 10 function items inside it that branch (nextSyncWithSyncValues, nextSyncWithAsyncValues, nextAsync, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
child_process.normalizeSpawnArguments (cognitive 52) ext/node/polyfills/internal/child_process.ts:1214— child_process.normalizeSpawnArguments has cognitive complexity 52 (threshold 15). Drivers by points: if/else 33 (45 pts), boolean chains 4, loops 3 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
update_node_stream.transform (cognitive 52) ext/node/update_node_stream.ts:122— update_node_stream.transform has cognitive complexity 52 (threshold 15). Drivers by points: if/else 26 (35 pts), boolean chains 12, ternaries 2 (4 pts), loops 1 (nesting depth added 11). Most of this is not in the body itself: 4 of the 52 points are its own statements and the rest belongs to 11 function items inside it that branch (a function literal at line 158, a function literal at line 292, a function literal at line 418, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
TestStepCollector::visit_var_decl (cognitive 50) cli/lsp/testing/collectors.rs:443— TestStepCollector::visit_var_decl has cognitive complexity 50 (threshold 15). Drivers by points: if/else 9 (34 pts), match/switch 2 (8 pts), loops 2 (6 pts), boolean chains 2 (nesting depth added 35). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
denort::run::run_with_options (cognitive 50) cli/rt/run.rs:1394— denort::run::run_with_options has cognitive complexity 50 (threshold 15). Drivers by points: if/else 24 (36 pts), match/switch 7 (10 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LibUvStreamWrap::writev (cognitive 50) ext/node/ops/stream_wrap.rs:1501— LibUvStreamWrap::writev has cognitive complexity 50 (threshold 15). Drivers by points: if/else 25 (44 pts), loops 3 (5 pts), boolean chains 1 (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
constructor (cognitive 50) ext/web/00_url.js:127— constructor has cognitive complexity 50 (threshold 15). Drivers by points: if/else 12 (31 pts), loops 4 (11 pts), boolean chains 8 (nesting depth added 26). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Compiler::to_path (cognitive 49) cli/lsp/path_to_regex.rs:822— Compiler::to_path has cognitive complexity 49 (threshold 15). Drivers by points: if/else 9 (34 pts), loops 2 (6 pts), match/switch 2 (5 pts), boolean chains 4 (nesting depth added 32). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TestCollector::visit_var_decl (cognitive 49) cli/lsp/testing/collectors.rs:581— TestCollector::visit_var_decl has cognitive complexity 49 (threshold 15). Drivers by points: if/else 11 (38 pts), match/switch 2 (6 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 33). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
FilePatterns::split_by_base (cognitive 49) libs/config/glob/mod.rs:132— FilePatterns::split_by_base has cognitive complexity 49 (threshold 15). Drivers by points: if/else 20 (34 pts), loops 5 (6 pts), boolean chains 5, match/switch 3 (4 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SecureContext.constructor (cognitive 49) ext/node/polyfills/_tls_common.ts:507— SecureContext.constructor has cognitive complexity 49 (threshold 15). Drivers by points: if/else 17 (33 pts), ternaries 4 (8 pts), boolean chains 4, loops 2 (4 pts) (nesting depth added 22). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.fork (cognitive 49) ext/node/polyfills/child_process.ts:99— child_process.fork has cognitive complexity 49 (threshold 15). Drivers by points: if/else 24 (36 pts), boolean chains 10, loops 2 (3 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
sig.verifyOneShot (cognitive 49) ext/node/polyfills/internal/crypto/sig.ts:468— sig.verifyOneShot has cognitive complexity 49 (threshold 15). Drivers by points: if/else 22 (33 pts), boolean chains 10, ternaries 3 (5 pts), error handling 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.objEquiv (cognitive 49) ext/node/polyfills/internal/util/comparisons.ts:1232— comparisons.objEquiv has cognitive complexity 49 (threshold 15). Drivers by points: if/else 16 (36 pts), loops 3 (7 pts), boolean chains 6 (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
getColorDepth (cognitive 49) ext/node/polyfills/internal/tty.js:132— getColorDepth has cognitive complexity 49 (threshold 15). Drivers by points: if/else 21 (35 pts), boolean chains 7, match/switch 2 (3 pts), loops 1 (2 pts), ternaries 1 (2 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
D2 · Cognitive Complexity· fill (cognitive 48) · ×1
fill (cognitive 48) ext/node/polyfills/internal/buffer.mjs:2232— fill has cognitive complexity 48 (threshold 15). Drivers by points: if/else 20 (30 pts), boolean chains 8, loops 3 (7 pts), ternaries 2 (3 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
table (cognitive 48) ext/node/polyfills/internal/console/constructor.mjs:607— table has cognitive complexity 48 (threshold 15). Drivers by points: if/else 14 (22 pts), loops 5 (12 pts), boolean chains 11, ternaries 2 (3 pts) (nesting depth added 16). Of this number, 45 points are the body's own statements and 3 belong to 4 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parseSimpleSpecialUrl (cognitive 47) ext/web/00_url.js:605— parseSimpleSpecialUrl has cognitive complexity 47 (threshold 15). Drivers by points: if/else 17 (31 pts), boolean chains 11, loops 4 (5 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ContextifyScript::eval_machine (cognitive 46) ext/node/ops/vm.rs:216— ContextifyScript::eval_machine has cognitive complexity 46 (threshold 15). Drivers by points: if/else 21 (44 pts), boolean chains 2 (nesting depth added 23). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
_http_server.resOnFinish (cognitive 46) ext/node/polyfills/_http_server.js:1185— _http_server.resOnFinish has cognitive complexity 46 (threshold 15). Drivers by points: if/else 20 (33 pts), boolean chains 8, ternaries 2 (5 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_win32.join (cognitive 46) ext/node/polyfills/path/_win32.ts:460— _win32.join has cognitive complexity 46 (threshold 15). Drivers by points: if/else 18 (40 pts), loops 3 (4 pts), boolean chains 2 (nesting depth added 23). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
InterfaceConstructor (cognitive 46) ext/node/polyfills/internal/readline/interface.mjs:171— InterfaceConstructor has cognitive complexity 46 (threshold 15). Drivers by points: if/else 25 (35 pts), boolean chains 10, ternaries 1 (nesting depth added 10). Of this number, 34 points are the body's own statements and 12 belong to 10 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.keyCheck (cognitive 45) ext/node/polyfills/internal/util/comparisons.ts:513— comparisons.keyCheck has cognitive complexity 45 (threshold 15). Drivers by points: if/else 15 (35 pts), boolean chains 6, loops 1 (4 pts) (nesting depth added 23). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
sig.signOneShot (cognitive 44) ext/node/polyfills/internal/crypto/sig.ts:349— sig.signOneShot has cognitive complexity 44 (threshold 15). Drivers by points: if/else 20 (31 pts), boolean chains 7, ternaries 3 (5 pts), error handling 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
readable.fromList (cognitive 44) ext/node/polyfills/internal/streams/readable.js:1689— readable.fromList has cognitive complexity 44 (threshold 15). Drivers by points: if/else 22 (33 pts), loops 4 (10 pts), boolean chains 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Url.format (cognitive 44) ext/node/polyfills/url.ts:565— Url.format has cognitive complexity 44 (threshold 15). Drivers by points: if/else 17 (26 pts), boolean chains 15, match/switch 1 (2 pts), loops 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
read (cognitive 44) ext/node/polyfills/internal/streams/readable.js:713— read has cognitive complexity 44 (threshold 15). Drivers by points: if/else 24 (31 pts), boolean chains 7, ternaries 2 (4 pts), error handling 1 (2 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
isSimpleSpecialHostCanonical (cognitive 44) ext/web/00_url.js:493— isSimpleSpecialHostCanonical has cognitive complexity 44 (threshold 15). Drivers by points: if/else 13 (27 pts), boolean chains 13, loops 3 (4 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
removeEventListener (cognitive 44) ext/web/03_abort_signal.js:278— removeEventListener has cognitive complexity 44 (threshold 15). Drivers by points: if/else 9 (33 pts), loops 2 (9 pts), boolean chains 2 (nesting depth added 31). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
SloppyImportsResolver::resolve (cognitive 43) libs/resolver/workspace.rs:425— SloppyImportsResolver::resolve has cognitive complexity 43 (threshold 15). Drivers by points: if/else 17 (31 pts), match/switch 5 (9 pts), boolean chains 2, loops 1 (nesting depth added 18). Of this number, 42 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EventSource.#loop (cognitive 43) REDACTED:229— EventSource.#loop has cognitive complexity 43 (threshold 15). Drivers by points: if/else 15 (33 pts), boolean chains 3, match/switch 1 (3 pts), error handling 2, loops 1, ternaries 1 (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_util.normalizeString (cognitive 43) ext/node/polyfills/path/_util.ts:46— _util.normalizeString has cognitive complexity 43 (threshold 15). Drivers by points: if/else 17 (39 pts), boolean chains 3, loops 1 (nesting depth added 22). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
bench (cognitive 43) cli/js/40_bench.js:64— bench has cognitive complexity 43 (threshold 15). Drivers by points: if/else 21 (39 pts), boolean chains 2, other 2 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoTestCollector::visit_var_decl (cognitive 42) cli/lsp/code_lens.rs:319— DenoTestCollector::visit_var_decl has cognitive complexity 42 (threshold 15). Drivers by points: if/else 5 (24 pts), match/switch 2 (9 pts), loops 2 (6 pts), boolean chains 3 (nesting depth added 30). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
HmrRunner::run (cognitive 42) cli/tools/run/hmr.rs:212— HmrRunner::run has cognitive complexity 42 (threshold 15). Drivers by points: if/else 8 (31 pts), loops 3 (8 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 29). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
PermissionsContainer::check_special_file (cognitive 42) runtime/permissions/lib.rs:4602— PermissionsContainer::check_special_file has cognitive complexity 42 (threshold 15). Drivers by points: if/else 21 (32 pts), boolean chains 10 (nesting depth added 11). Of this number, 28 points are the body's own statements and 14 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net.Server.listen (cognitive 42) ext/node/polyfills/net.ts:2907— net.Server.listen has cognitive complexity 42 (threshold 15). Drivers by points: if/else 18 (27 pts), boolean chains 15 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_findPath (cognitive 42) ext/node/polyfills/01_require.js:1261— _findPath has cognitive complexity 42 (threshold 15). Drivers by points: if/else 16 (33 pts), boolean chains 5, ternaries 1 (3 pts), loops 1 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
extractBody (cognitive 42) ext/fetch/22_body.js:485— extractBody has cognitive complexity 42 (threshold 15). Drivers by points: if/else 22 (33 pts), boolean chains 6, ternaries 1 (2 pts), other 1 (nesting depth added 12). Of this number, 35 points are the body's own statements and 7 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
AtomicOperation.[SymbolFor("Deno.privateCustomInspect")] (cognitive 41) ext/kv/01_db.ts:604— AtomicOperation.[SymbolFor("Deno.privateCustomInspect")] has cognitive complexity 41 (threshold 15). Drivers by points: if/else 12 (24 pts), error handling 2 (5 pts), match/switch 1 (4 pts), boolean chains 3, loops 3, ternaries 1 (2 pts) (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.buildCommand (cognitive 41) ext/node/polyfills/internal/child_process.ts:1732— child_process.buildCommand has cognitive complexity 41 (threshold 15). Drivers by points: if/else 18 (31 pts), boolean chains 4, error handling 1 (4 pts), ternaries 1 (2 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
writable.onwrite (cognitive 41) ext/node/polyfills/internal/streams/writable.js:713— writable.onwrite has cognitive complexity 41 (threshold 15). Drivers by points: if/else 18 (35 pts), boolean chains 5, ternaries 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LspScopedResolver::configured_auto_import_roots (cognitive 40) cli/lsp/resolver.rs:394— LspScopedResolver::configured_auto_import_roots has cognitive complexity 40 (threshold 15). Drivers by points: if/else 9 (29 pts), boolean chains 4, loops 2 (4 pts), match/switch 1 (3 pts) (nesting depth added 24). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
HttpRecordResponse::poll_frame (cognitive 40) ext/http/service.rs:1217— HttpRecordResponse::poll_frame has cognitive complexity 40 (threshold 15). Drivers by points: if/else 10 (30 pts), match/switch 3 (6 pts), boolean chains 2, loops 1 (2 pts) (nesting depth added 24). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
EnvironmentOptions::check_options (cognitive 40) libs/node_shim/lib.rs:422— EnvironmentOptions::check_options has cognitive complexity 40 (threshold 15). Drivers by points: if/else 28 (33 pts), boolean chains 7 (nesting depth added 5). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
stream_base_commons.onStreamRead (cognitive 40) ext/node/polyfills/internal/stream_base_commons.ts:259— stream_base_commons.onStreamRead has cognitive complexity 40 (threshold 15). Drivers by points: if/else 18 (36 pts), ternaries 1 (3 pts), boolean chains 1 (nesting depth added 20). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
FileCollector::collect_file_patterns (cognitive 39) libs/config/glob/collector.rs:71— FileCollector::collect_file_patterns has cognitive complexity 39 (threshold 15). Drivers by points: if/else 14 (28 pts), loops 3 (6 pts), boolean chains 3, match/switch 2 (nesting depth added 17). Of this number, 37 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RawDenoResolver::resolve (cognitive 39) libs/resolver/lib.rs:321— RawDenoResolver::resolve has cognitive complexity 39 (threshold 15). Drivers by points: if/else 13 (26 pts), match/switch 5 (10 pts), boolean chains 3 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parse_args.argsToTokens (cognitive 39) ext/node/polyfills/internal/util/parse_args/parse_args.js:179— parse_args.argsToTokens has cognitive complexity 39 (threshold 15). Drivers by points: if/else 14 (32 pts), loops 2 (4 pts), boolean chains 3 (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
writeHead (cognitive 39) ext/node/polyfills/internal/http2/compat.js:763— writeHead has cognitive complexity 39 (threshold 15). Drivers by points: if/else 12 (18 pts), loops 5 (16 pts), boolean chains 5 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parseArgs (cognitive 39) ext/node/polyfills/internal/util/parse_args/parse_args.js:332— parseArgs has cognitive complexity 39 (threshold 15). Drivers by points: if/else 15 (24 pts), other 6, ternaries 2 (6 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 14). Most of this is not in the body itself: 7 of the 39 points are its own statements and the rest belongs to 3 function literals inside it that branch (lines 411, 356, 457). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
DenoTestStepCollector::visit_var_decl (cognitive 38) cli/lsp/code_lens.rs:448— DenoTestStepCollector::visit_var_decl has cognitive complexity 38 (threshold 15). Drivers by points: if/else 9 (26 pts), match/switch 2 (6 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 23). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DatabaseSyncOptions::from_v8 (cognitive 38) ext/node_sqlite/database.rs:160— DatabaseSyncOptions::from_v8 has cognitive complexity 38 (threshold 15). Drivers by points: if/else 17 (23 pts), boolean chains 13, loops 1 (2 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_server.ServerResponse.writeHead (cognitive 38) ext/node/polyfills/_http_server.js:498— _http_server.ServerResponse.writeHead has cognitive complexity 38 (threshold 15). Drivers by points: if/else 14 (26 pts), loops 3 (9 pts), boolean chains 3 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
duplexify (cognitive 38) ext/node/polyfills/internal/streams/duplexify.js:50— duplexify has cognitive complexity 38 (threshold 15). Drivers by points: if/else 19 (25 pts), ternaries 4 (8 pts), error handling 1 (3 pts), boolean chains 2 (nesting depth added 12). Of this number, 28 points are the body's own statements and 10 belong to 8 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDisplayContext::build_module_info (cognitive 37) cli/tools/info.rs:636— GraphDisplayContext::build_module_info has cognitive complexity 37 (threshold 15). Drivers by points: match/switch 8 (15 pts), if/else 8 (13 pts), loops 2 (8 pts), boolean chains 1 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
errors.createInvalidArgType (cognitive 37) ext/node/polyfills/internal/errors.ts:734— errors.createInvalidArgType has cognitive complexity 37 (threshold 15). Drivers by points: if/else 22 (33 pts), ternaries 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
operators.map (cognitive 37) ext/node/polyfills/internal/streams/operators.js:83— operators.map has cognitive complexity 37 (threshold 15). Drivers by points: if/else 16 (27 pts), loops 3 (4 pts), boolean chains 3, error handling 2 (3 pts) (nesting depth added 13). Most of this is not in the body itself: 5 of the 37 points are its own statements and the rest belongs to 3 function literals inside it that branch (lines 146, 113, 134). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
isFullWidthCodePoint (cognitive 37) ext/node/polyfills/internal/util/inspect.mjs:325— isFullWidthCodePoint has cognitive complexity 37 (threshold 15). Drivers by points: boolean chains 37. To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
#release (cognitive 37) ext/node/polyfills/internal/streams/fast-utf8-stream.js:354— #release has cognitive complexity 37 (threshold 15). Drivers by points: if/else 17 (25 pts), error handling 2 (6 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parse (cognitive 37) ext/fetch/21_formdata.js:530— parse has cognitive complexity 37 (threshold 15). Drivers by points: if/else 12 (32 pts), boolean chains 4, loops 1 (nesting depth added 20). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
LaxSingleProcessFsFlag::lock (cognitive 36) libs/npm_installer/flag.rs:143— LaxSingleProcessFsFlag::lock has cognitive complexity 36 (threshold 15). Drivers by points: match/switch 5 (18 pts), if/else 3 (11 pts), loops 2 (6 pts), boolean chains 1 (nesting depth added 25). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
40_lint.traverse (cognitive 36) REDACTED:1355— 40_lint.traverse has cognitive complexity 36 (threshold 15). Drivers by points: if/else 9 (29 pts), loops 3 (7 pts) (nesting depth added 24). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
fs.watch (cognitive 36) ext/node/polyfills/fs.ts:3474— fs.watch has cognitive complexity 36 (threshold 15). Drivers by points: if/else 14 (19 pts), ternaries 5 (8 pts), error handling 3 (5 pts), boolean chains 4 (nesting depth added 10). Of this number, 24 points are the body's own statements and 12 belong to 3 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
https.openCONNECTTunnel (cognitive 36) ext/node/polyfills/https.ts:446— https.openCONNECTTunnel has cognitive complexity 36 (threshold 15). Drivers by points: if/else 20 (24 pts), boolean chains 6, error handling 4 (5 pts), ternaries 1 (nesting depth added 5). Most of this is not in the body itself: 14 of the 36 points are its own statements and the rest belongs to 6 function items inside it that branch (onProxyReady::onData, onProxyReady, fail, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
child_process.transformDenoShellCommand (cognitive 36) ext/node/polyfills/internal/child_process.ts:1539— child_process.transformDenoShellCommand has cognitive complexity 36 (threshold 15). Drivers by points: if/else 17 (30 pts), boolean chains 4, error handling 1, ternaries 1 (nesting depth added 13). Of this number, 28 points are the body's own statements and 8 belong to 2 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._lookupAndConnect (cognitive 36) ext/node/polyfills/net.ts:1052— net._lookupAndConnect has cognitive complexity 36 (threshold 15). Drivers by points: if/else 23 (27 pts), boolean chains 9 (nesting depth added 4). Of this number, 22 points are the body's own statements and 14 belong to 5 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
generate_linux_function_orderfile.generate (cognitive 36) tools/startup_order/generate_linux_function_orderfile.ts:398— generate_linux_function_orderfile.generate has cognitive complexity 36 (threshold 15). Drivers by points: if/else 8 (20 pts), loops 6 (13 pts), boolean chains 2, ternaries 1 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
createImageBitmap (cognitive 36) ext/image/01_image.js:136— createImageBitmap has cognitive complexity 36 (threshold 15). Drivers by points: if/else 22 (25 pts), other 5, ternaries 3, match/switch 1 (2 pts), boolean chains 1 (nesting depth added 4). Most of this is not in the body itself: 10 of the 36 points are its own statements and the rest belongs to one function literal inside it that branches (line 219). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
PublishPreparer::build_and_check_graph_for_publish (cognitive 35) cli/tools/publish/mod.rs:398— PublishPreparer::build_and_check_graph_for_publish has cognitive complexity 35 (threshold 15). Drivers by points: if/else 11 (24 pts), loops 4 (11 pts) (nesting depth added 20). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ChannelWrap.#resolve (cognitive 35) ext/node/polyfills/internal_binding/cares_wrap.ts:363— ChannelWrap.#resolve has cognitive complexity 35 (threshold 15). Drivers by points: if/else 13 (30 pts), error handling 1 (2 pts), boolean chains 1, loops 1, ternaries 1 (nesting depth added 18). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_posix.parse (cognitive 35) ext/node/polyfills/path/_posix.ts:424— _posix.parse has cognitive complexity 35 (threshold 15). Drivers by points: if/else 19 (30 pts), boolean chains 4, loops 1 (nesting depth added 11). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
process.internals.__bootstrapNodeProcess (cognitive 35) ext/node/polyfills/process.ts:1831— process.internals.__bootstrapNodeProcess has cognitive complexity 35 (threshold 15). Drivers by points: if/else 11 (20 pts), loops 3 (7 pts), boolean chains 4, ternaries 2 (4 pts) (nesting depth added 15). Of this number, 32 points are the body's own statements and 3 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
pipe (cognitive 35) ext/node/polyfills/internal/streams/readable.js:998— pipe has cognitive complexity 35 (threshold 15). Drivers by points: if/else 18 (22 pts), boolean chains 9, ternaries 2 (4 pts) (nesting depth added 6). Most of this is not in the body itself: 13 of the 35 points are its own statements and the rest belongs to 9 function items inside it that branch (pause, onerror, onunpipe, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
NpmRegistryReadPermissionChecker::ensure_read_permission (cognitive 34) cli/lib/npm/permission_checker.rs:50— NpmRegistryReadPermissionChecker::ensure_read_permission has cognitive complexity 34 (threshold 15). Drivers by points: if/else 9 (24 pts), match/switch 3 (8 pts), boolean chains 2 (nesting depth added 20). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
ZlibInner::do_write (cognitive 34) ext/node/ops/zlib/mod.rs:118— ZlibInner::do_write has cognitive complexity 34 (threshold 15). Drivers by points: if/else 12 (24 pts), match/switch 3 (5 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
02_websocket.upgradeWebSocket (cognitive 34) ext/http/02_websocket.ts:43— 02_websocket.upgradeWebSocket has cognitive complexity 34 (threshold 15). Drivers by points: if/else 16 (23 pts), boolean chains 5, error handling 2 (4 pts), loops 1 (2 pts) (nesting depth added 10). Of this number, 23 points are the body's own statements and 11 belong to 3 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
dns.lookup (cognitive 34) ext/node/polyfills/dns.ts:192— dns.lookup has cognitive complexity 34 (threshold 15). Drivers by points: if/else 18 (26 pts), ternaries 2 (5 pts), match/switch 1 (3 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.partialObjectMapEquiv (cognitive 34) ext/node/polyfills/internal/util/comparisons.ts:932— comparisons.partialObjectMapEquiv has cognitive complexity 34 (threshold 15). Drivers by points: if/else 9 (30 pts), boolean chains 3, loops 1 (nesting depth added 21). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
net.Socket (cognitive 34) ext/node/polyfills/net.ts:1466— net.Socket has cognitive complexity 34 (threshold 15). Drivers by points: if/else 20 (28 pts), boolean chains 6 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
generate_linux_function_orderfile.parseArgs (cognitive 34) tools/startup_order/generate_linux_function_orderfile.ts:55— generate_linux_function_orderfile.parseArgs has cognitive complexity 34 (threshold 15). Drivers by points: if/else 16 (28 pts), boolean chains 5, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
postMessage (cognitive 34) ext/web/13_message_port.js:294— postMessage has cognitive complexity 34 (threshold 15). Drivers by points: if/else 15 (29 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
40_lint._dump (cognitive 33) REDACTED:1455— 40_lint._dump has cognitive complexity 33 (threshold 15). Drivers by points: if/else 13 (20 pts), loops 5 (8 pts), ternaries 2 (5 pts) (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
buffer.Buffer.copy (cognitive 33) ext/node/polyfills/internal/buffer.mjs:2113— buffer.Buffer.copy has cognitive complexity 33 (threshold 15). Drivers by points: if/else 24 (30 pts), boolean chains 3 (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
child_process.spawnSync (cognitive 33) ext/node/polyfills/internal/child_process.ts:1926— child_process.spawnSync has cognitive complexity 33 (threshold 15). Drivers by points: boolean chains 12, ternaries 10, if/else 7 (9 pts), error handling 1, loops 1 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
scrypt.check (cognitive 33) ext/node/polyfills/internal/crypto/scrypt.ts:129— scrypt.check has cognitive complexity 33 (threshold 15). Drivers by points: if/else 15 (32 pts), boolean chains 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parseNoProxy (cognitive 33) ext/node/polyfills/_http_proxy.js:203— parseNoProxy has cognitive complexity 33 (threshold 15). Drivers by points: if/else 13 (24 pts), ternaries 2 (5 pts), boolean chains 3, loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
request (cognitive 33) ext/web/locks.js:99— request has cognitive complexity 33 (threshold 15). Drivers by points: if/else 18 (26 pts), boolean chains 5, other 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ImageData::constructor (cognitive 32) ext/web/image_data.rs:199— ImageData::constructor has cognitive complexity 32 (threshold 15). Drivers by points: if/else 20 (25 pts), boolean chains 5, match/switch 1 (2 pts) (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
BinEntries::for_each_entry (cognitive 32) libs/npm_installer/bin_entries.rs:173— BinEntries::for_each_entry has cognitive complexity 32 (threshold 15). Drivers by points: if/else 7 (23 pts), loops 2 (5 pts), match/switch 1 (3 pts), boolean chains 1 (nesting depth added 21). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
http2.setupHandle (cognitive 32) ext/node/polyfills/http2.ts:3510— http2.setupHandle has cognitive complexity 32 (threshold 15). Drivers by points: if/else 15 (24 pts), boolean chains 5, loops 1 (2 pts), ternaries 1 (nesting depth added 10). Most of this is not in the body itself: 15 of the 32 points are its own statements and the rest belongs to 6 function items inside it that branch (socketOnData, a function literal at line 3619, a function literal at line 3562, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
DiffieHellmanImpl.constructor (cognitive 32) ext/node/polyfills/internal/crypto/diffiehellman.ts:117— DiffieHellmanImpl.constructor has cognitive complexity 32 (threshold 15). Drivers by points: if/else 19 (25 pts), boolean chains 7 (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
comparisons.mapEquiv (cognitive 32) ext/node/polyfills/internal/util/comparisons.ts:1096— comparisons.mapEquiv has cognitive complexity 32 (threshold 15). Drivers by points: if/else 10 (27 pts), boolean chains 4, loops 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
querystring.stringify (cognitive 32) ext/node/polyfills/querystring.js:346— querystring.stringify has cognitive complexity 32 (threshold 15). Drivers by points: if/else 7 (22 pts), loops 2 (6 pts), boolean chains 2, ternaries 2 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
generate_macos_function_orderfile.generate (cognitive 32) tools/startup_order/generate_macos_function_orderfile.ts:281— generate_macos_function_orderfile.generate has cognitive complexity 32 (threshold 15). Drivers by points: if/else 6 (18 pts), loops 6 (13 pts), boolean chains 1 (nesting depth added 19). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Agent (cognitive 32) ext/node/polyfills/_http_agent.js:137— Agent has cognitive complexity 32 (threshold 15). Drivers by points: boolean chains 16, if/else 13 (15 pts), ternaries 1 (nesting depth added 2). Most of this is not in the body itself: 14 of the 32 points are its own statements and the rest belongs to 2 function literals inside it that branch (lines 185, 214). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
CompletionEntryDetails::as_completion_item (cognitive 31) cli/lsp/tsc.rs:3992— CompletionEntryDetails::as_completion_item has cognitive complexity 31 (threshold 15). Drivers by points: if/else 17 (26 pts), match/switch 1 (3 pts), loops 1 (2 pts) (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
GraphDiagnosticsCollector::collect_diagnostics_for_graph (cognitive 31) cli/tools/publish/graph.rs:40— GraphDiagnosticsCollector::collect_diagnostics_for_graph has cognitive complexity 31 (threshold 15). Drivers by points: if/else 8 (19 pts), loops 4 (8 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_cache_dir::local::url_to_local_sub_path (cognitive 31) libs/cache_dir/local.rs:570— deno_cache_dir::local::url_to_local_sub_path has cognitive complexity 31 (threshold 15). Drivers by points: if/else 14 (16 pts), boolean chains 7, match/switch 4 (7 pts), loops 1 (nesting depth added 5). Most of this is not in the body itself: 11 of the 31 points are its own statements and the rest belongs to 5 function items inside it that branch (short_hash, should_hash_part, has_forbidden_chars, …). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
RecursiveModuleLoad::register_and_recurse_inner (cognitive 31) libs/core/modules/recursive_load.rs:426— RecursiveModuleLoad::register_and_recurse_inner has cognitive complexity 31 (threshold 15). Drivers by points: if/else 7 (15 pts), match/switch 2 (7 pts), loops 3 (5 pts), boolean chains 4 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmReqResolver::resolve_if_for_npm_pkg (cognitive 31) libs/resolver/npm/mod.rs:559— NpmReqResolver::resolve_if_for_npm_pkg has cognitive complexity 31 (threshold 15). Drivers by points: if/else 3 (15 pts), match/switch 6 (15 pts), boolean chains 1 (nesting depth added 21). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
01_require.Module.load (cognitive 31) ext/node/polyfills/01_require.js:1908— 01_require.Module.load has cognitive complexity 31 (threshold 15). Drivers by points: if/else 14 (20 pts), error handling 2 (6 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Socket.send (cognitive 31) ext/node/polyfills/dgram.ts:922— Socket.send has cognitive complexity 31 (threshold 15). Drivers by points: if/else 22 (28 pts), boolean chains 3 (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
comparisons.partialObjectSetEquiv (cognitive 31) ext/node/polyfills/internal/util/comparisons.ts:722— comparisons.partialObjectSetEquiv has cognitive complexity 31 (threshold 15). Drivers by points: if/else 9 (30 pts), loops 1 (nesting depth added 21). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
REPLServer.constructor (cognitive 31) ext/node/polyfills/repl.ts:593— REPLServer.constructor has cognitive complexity 31 (threshold 15). Drivers by points: if/else 106 (159 pts), boolean chains 56, error handling 7 (19 pts), loops 8 (18 pts), ternaries 9 (13 pts), match/switch 1 (2 pts) (nesting depth added 80). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: 5 other methods here (REPLServer.constructor::defaultEval, REPLServer.constructor::_doComplete, REPLServer.constructor::_doComplete::completionGroupsLoaded, …) have the same decision points, in the same order, at the same nesting depths — so this is one pattern written 6 times rather than 6 independent problems. Splitting this body alone leaves the other 5 exactly as they are. Where these are variations on one operation, the change that clears all 6 is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
_duplexify (cognitive 31) ext/node/polyfills/internal/streams/duplexify.js:281— _duplexify has cognitive complexity 31 (threshold 15). Drivers by points: if/else 16 (26 pts), boolean chains 2, loops 1 (2 pts), ternaries 1 (nesting depth added 11). Most of this is not in the body itself: 4 of the 31 points are its own statements and the rest belongs to 11 function items inside it that branch (_read, _destroy, onfinished, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
ProxyConnector::call (cognitive 30) ext/fetch/proxy.rs:596— ProxyConnector::call has cognitive complexity 30 (threshold 15). Drivers by points: if/else 11 (25 pts), match/switch 2 (5 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_proxy.shouldBypassProxy (cognitive 30) ext/node/polyfills/_http_proxy.js:282— _http_proxy.shouldBypassProxy has cognitive complexity 30 (threshold 15). Drivers by points: if/else 11 (23 pts), boolean chains 5, loops 1, ternaries 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.createIpcHandle (cognitive 30) ext/node/polyfills/internal/child_process.ts:2435— child_process.createIpcHandle has cognitive complexity 30 (threshold 15). Drivers by points: if/else 10 (17 pts), ternaries 4 (9 pts), error handling 2 (4 pts) (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.setupChannel::readLoop (cognitive 30) ext/node/polyfills/internal/child_process.ts:2788— child_process.setupChannel::readLoop has cognitive complexity 30 (threshold 15). Drivers by points: if/else 11 (25 pts), boolean chains 3, error handling 1, loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SecretKeyObject.toCryptoKey (cognitive 30) ext/node/polyfills/internal/crypto/keys.ts:739— SecretKeyObject.toCryptoKey has cognitive complexity 30 (threshold 15). Drivers by points: if/else 15 (24 pts), boolean chains 5, ternaries 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._createServerHandle (cognitive 30) ext/node/polyfills/net.ts:2519— net._createServerHandle has cognitive complexity 30 (threshold 15). Drivers by points: if/else 14 (23 pts), boolean chains 5, error handling 1 (2 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
testing.runTapEntry (cognitive 30) ext/node/polyfills/testing.ts:963— testing.runTapEntry has cognitive complexity 30 (threshold 15). Drivers by points: if/else 13 (18 pts), error handling 3 (7 pts), loops 2 (3 pts), boolean chains 1, ternaries 1 (nesting depth added 10). Of this number, 28 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
update_types_node.aliasWebStreamGlobals (cognitive 30) tools/update_types_node.ts:310— update_types_node.aliasWebStreamGlobals has cognitive complexity 30 (threshold 15). Drivers by points: if/else 6 (16 pts), ternaries 2 (8 pts), boolean chains 3, loops 2 (3 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
decode (cognitive 30) ext/web/08_text_encoding.js:127— decode has cognitive complexity 30 (threshold 15). Drivers by points: if/else 17 (21 pts), boolean chains 9 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
WatchEnvTracker::load_env_file_inner (cognitive 29) cli/util/env.rs:145— WatchEnvTracker::load_env_file_inner has cognitive complexity 29 (threshold 15). Drivers by points: if/else 5 (22 pts), match/switch 3 (5 pts), loops 1 (2 pts) (nesting depth added 20). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
LocalCronHandler::cron_loop (cognitive 29) ext/cron/local.rs:82— LocalCronHandler::cron_loop has cognitive complexity 29 (threshold 15). Drivers by points: if/else 10 (23 pts), loops 2 (3 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
UvLoopInner::has_alive_handles (cognitive 29) libs/core/uv_compat.rs:359— UvLoopInner::has_alive_handles has cognitive complexity 29 (threshold 15). Drivers by points: if/else 8 (15 pts), boolean chains 7, loops 7 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
00_serve.mapToCallback::mapped (cognitive 29) REDACTED:717— 00_serve.mapToCallback::mapped has cognitive complexity 29 (threshold 15). Drivers by points: if/else 17 (24 pts), error handling 2 (3 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
00_serve.serveInner (cognitive 29) REDACTED:1293— 00_serve.serveInner has cognitive complexity 29 (threshold 15). Drivers by points: if/else 16 (20 pts), ternaries 2 (5 pts), boolean chains 4 (nesting depth added 7). Most of this is not in the body itself: 11 of the 29 points are its own statements and the rest belongs to 4 function items inside it that branch (onListen, a function literal at line 1364, a function literal at line 1319, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
child_process.getIpcHandleInfo (cognitive 29) ext/node/polyfills/internal/child_process.ts:2300— child_process.getIpcHandleInfo has cognitive complexity 29 (threshold 15). Drivers by points: if/else 11 (18 pts), ternaries 3 (6 pts), boolean chains 5 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EventTarget.[kHybridDispatch] (cognitive 29) ext/node/polyfills/internal/event_target.mjs:716— EventTarget.[kHybridDispatch] has cognitive complexity 29 (threshold 15). Drivers by points: if/else 12 (20 pts), boolean chains 4, error handling 1 (2 pts), ternaries 1 (2 pts), loops 1 (nesting depth added 10). Of this number, 28 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._setupListenHandle (cognitive 29) ext/node/polyfills/net.ts:2681— net._setupListenHandle has cognitive complexity 29 (threshold 15). Drivers by points: if/else 16 (27 pts), boolean chains 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
REPLServer.createContext (cognitive 29) ext/node/polyfills/repl.ts:1828— REPLServer.createContext has cognitive complexity 29 (threshold 15). Drivers by points: error handling 5 (12 pts), if/else 6 (12 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 15). Of this number, 26 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Event.composedPath (cognitive 29) ext/web/02_event.js:209— Event.composedPath has cognitive complexity 29 (threshold 15). Drivers by points: if/else 13 (26 pts), loops 3 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
02_event.innerInvokeEventListeners (cognitive 29) ext/web/02_event.js:737— 02_event.innerInvokeEventListeners has cognitive complexity 29 (threshold 15). Drivers by points: if/else 12 (21 pts), boolean chains 5, error handling 1 (2 pts), loops 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WebSocket.[_eventLoop] (cognitive 29) ext/websocket/01_websocket.js:754— WebSocket.[_eventLoop] has cognitive complexity 29 (threshold 15). Drivers by points: if/else 7 (18 pts), error handling 1 (4 pts), ternaries 1 (3 pts), match/switch 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
02_timers.listOnTimeout (cognitive 29) libs/core/02_timers.js:270— 02_timers.listOnTimeout has cognitive complexity 29 (threshold 15). Drivers by points: if/else 12 (24 pts), boolean chains 2, error handling 1 (2 pts), loops 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parseMappings (cognitive 29) ext/node/polyfills/01_require.js:2766— parseMappings has cognitive complexity 29 (threshold 15). Drivers by points: if/else 7 (18 pts), boolean chains 5, ternaries 1 (5 pts), loops 1 (nesting depth added 15). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
startOverrideListener (cognitive 29) ext/node/polyfills/internal/http/address_override.js:513— startOverrideListener has cognitive complexity 29 (threshold 15). Drivers by points: if/else 7 (12 pts), error handling 6 (11 pts), ternaries 2 (4 pts), boolean chains 1, loops 1 (nesting depth added 12). Most of this is not in the body itself: 2 of the 29 points are its own statements and the rest belongs to 5 function literals inside it that branch (lines 534, 552, 574, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
WorkspaceSettings::from_raw_settings (cognitive 28) cli/lsp/config.rs:654— WorkspaceSettings::from_raw_settings has cognitive complexity 28 (threshold 15). Drivers by points: if/else 15 (27 pts), match/switch 1 (nesting depth added 12). Of this number, 26 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NavigationTree::collect_document_symbols (cognitive 28) cli/lsp/tsc.rs:2526— NavigationTree::collect_document_symbols has cognitive complexity 28 (threshold 15). Drivers by points: if/else 8 (20 pts), loops 2 (3 pts), match/switch 1 (3 pts), boolean chains 2 (nesting depth added 15). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Transform::visit_mut_program (cognitive 28) cli/util/extract.rs:1024— Transform::visit_mut_program has cognitive complexity 28 (threshold 15). Drivers by points: match/switch 7 (22 pts), if/else 2 (4 pts), loops 1 (2 pts) (nesting depth added 18). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
01_cron.cron (cognitive 28) ext/cron/01_cron.ts:108— 01_cron.cron has cognitive complexity 28 (threshold 15). Drivers by points: if/else 13 (21 pts), loops 2 (5 pts), error handling 1 (2 pts) (nesting depth added 12). Most of this is not in the body itself: 8 of the 28 points are its own statements and the rest belongs to one function literal inside it that branches (line 165). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
TextLineStream.#handle (cognitive 28) REDACTED:75— TextLineStream.#handle has cognitive complexity 28 (threshold 15). Drivers by points: if/else 10 (18 pts), boolean chains 8, loops 1, ternaries 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_events.EventEmitter.emit (cognitive 28) ext/node/polyfills/_events.mjs:416— _events.EventEmitter.emit has cognitive complexity 28 (threshold 15). Drivers by points: if/else 11 (17 pts), error handling 2 (5 pts), boolean chains 4, loops 1 (2 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_tls_wrap.checkServerIdentity (cognitive 28) ext/node/polyfills/_tls_wrap.js:1863— _tls_wrap.checkServerIdentity has cognitive complexity 28 (threshold 15). Drivers by points: if/else 14 (23 pts), ternaries 2 (4 pts), boolean chains 1 (nesting depth added 11). Of this number, 25 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Http2Stream._destroy (cognitive 28) ext/node/polyfills/http2.ts:2532— Http2Stream._destroy has cognitive complexity 28 (threshold 15). Drivers by points: if/else 15 (20 pts), boolean chains 5, ternaries 2 (3 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.getValidStdio (cognitive 28) ext/node/polyfills/internal/child_process.ts:1128— child_process.getValidStdio has cognitive complexity 28 (threshold 15). Drivers by points: if/else 16 (22 pts), boolean chains 4, loops 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
util.prepareRequestHeadersArray (cognitive 28) ext/node/polyfills/internal/http2/util.ts:632— util.prepareRequestHeadersArray has cognitive complexity 28 (threshold 15). Drivers by points: if/else 16 (24 pts), boolean chains 2, loops 1, ternaries 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
MIMEParams.#parse (cognitive 28) REDACTED:241— MIMEParams.#parse has cognitive complexity 28 (threshold 15). Drivers by points: if/else 9 (19 pts), ternaries 2 (6 pts), boolean chains 2, loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
lint.ensureNoUnusedOutFiles::checkObject (cognitive 28) tools/lint.js:617— lint.ensureNoUnusedOutFiles::checkObject has cognitive complexity 28 (threshold 15). Drivers by points: loops 5 (14 pts), if/else 6 (13 pts), boolean chains 1 (nesting depth added 16). To reduce it, break up the iteration: give each loop body a named function, and split a multi-phase loop into one function per phase so no single body carries the whole pipeline.
BiPipeRead::recv_with_fd (cognitive 27) ext/io/bi_pipe.rs:151— BiPipeRead::recv_with_fd has cognitive complexity 27 (threshold 15). Drivers by points: if/else 5 (15 pts), loops 4 (9 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Http2Settings::init (cognitive 27) ext/node/ops/http2/session.rs:576— Http2Settings::init has cognitive complexity 27 (threshold 15). Drivers by points: if/else 16 (25 pts), loops 1 (2 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Session::send_pending_data (cognitive 27) ext/node/ops/http2/session.rs:2547— Session::send_pending_data has cognitive complexity 27 (threshold 15). Drivers by points: if/else 12 (21 pts), loops 3 (5 pts), match/switch 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoPeriodicReader::new (cognitive 27) ext/telemetry/lib.rs:402— DenoPeriodicReader::new has cognitive complexity 27 (threshold 15). Drivers by points: if/else 8 (18 pts), loops 3 (5 pts), match/switch 2 (4 pts) (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NetDescriptor::parse_inner (cognitive 27) runtime/permissions/lib.rs:2153— NetDescriptor::parse_inner has cognitive complexity 27 (threshold 15). Drivers by points: if/else 18 (25 pts), boolean chains 1, match/switch 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
26_fetch.handleWasmStreaming (cognitive 27) ext/fetch/26_fetch.js:1007— 26_fetch.handleWasmStreaming has cognitive complexity 27 (threshold 15). Drivers by points: if/else 13 (21 pts), error handling 2 (3 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 10). Most of this is not in the body itself: 11 of the 27 points are its own statements and the rest belongs to one function literal inside it that branches (line 1077). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
Kv.watch (cognitive 27) ext/kv/01_db.ts:380— Kv.watch has cognitive complexity 27 (threshold 15). Drivers by points: if/else 7 (18 pts), loops 2 (3 pts), boolean chains 2, error handling 1 (2 pts), ternaries 1 (2 pts) (nesting depth added 14). Of this number, 25 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_events.EventEmitter.removeListener (cognitive 27) ext/node/polyfills/_events.mjs:646— _events.EventEmitter.removeListener has cognitive complexity 27 (threshold 15). Drivers by points: if/else 13 (22 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.execFile (cognitive 27) ext/node/polyfills/child_process.ts:525— child_process.execFile has cognitive complexity 27 (threshold 15). Drivers by points: if/else 38 (50 pts), boolean chains 9, ternaries 4 (8 pts), error handling 1 (nesting depth added 16). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body. This shape REPEATS in the file: one other method here (child_process.execFile::exithandler) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
https.Agent.createConnection (cognitive 27) ext/node/polyfills/https.ts:370— https.Agent.createConnection has cognitive complexity 27 (threshold 15). Drivers by points: if/else 14 (21 pts), boolean chains 3, loops 1 (2 pts), ternaries 1 (nesting depth added 8). Of this number, 25 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child.init (cognitive 27) ext/node/polyfills/internal/cluster/child.ts:39— child.init has cognitive complexity 27 (threshold 15). Drivers by points: if/else 18 (21 pts), boolean chains 5, loops 1 (nesting depth added 3). Most of this is not in the body itself: 4 of the 27 points are its own statements and the rest belongs to 18 function items inside it that branch (onconnection, _disconnect::checkWaitingCount, _disconnect, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
comparisons.setObjectEquiv (cognitive 27) ext/node/polyfills/internal/util/comparisons.ts:805— comparisons.setObjectEquiv has cognitive complexity 27 (threshold 15). Drivers by points: if/else 10 (24 pts), boolean chains 1, loops 1, ternaries 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.mapObjectEquiv (cognitive 27) ext/node/polyfills/internal/util/comparisons.ts:1031— comparisons.mapObjectEquiv has cognitive complexity 27 (threshold 15). Drivers by points: if/else 8 (19 pts), boolean chains 6, loops 1, ternaries 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._lookupAndConnectMultiple (cognitive 27) ext/node/polyfills/net.ts:1263— net._lookupAndConnectMultiple has cognitive complexity 27 (threshold 15). Drivers by points: if/else 13 (20 pts), boolean chains 5, loops 2 (nesting depth added 7). None of this is in the body itself: all 27 points belong to 2 function literals inside it that branch (lines 1277, 1276). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
testing.run (cognitive 27) ext/node/polyfills/testing.ts:448— testing.run has cognitive complexity 27 (threshold 15). Drivers by points: if/else 15 (21 pts), error handling 2 (3 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 8). Of this number, 17 points are the body's own statements and 10 belong to 5 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
03_abort_signal.createDependentAbortSignal (cognitive 27) ext/web/03_abort_signal.js:387— 03_abort_signal.createDependentAbortSignal has cognitive complexity 27 (threshold 15). Drivers by points: if/else 6 (18 pts), loops 4 (9 pts) (nesting depth added 17). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
processCallback (cognitive 27) ext/node/polyfills/zlib.js:667— processCallback has cognitive complexity 27 (threshold 15). Drivers by points: if/else 15 (25 pts), boolean chains 2 (nesting depth added 10). Of this number, 14 points are the body's own statements and 13 belong to 3 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
on (cognitive 27) ext/node/polyfills/_events.mjs:1045— on has cognitive complexity 27 (threshold 15). Drivers by points: if/else 15 (17 pts), boolean chains 4, loops 2 (3 pts), other 2, ternaries 1 (nesting depth added 3). Most of this is not in the body itself: 13 of the 27 points are its own statements and the rest belongs to 12 function items inside it that branch (next, eventHandler, errorHandler, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
HttpClientAdapter::send_no_follow (cognitive 26) cli/file_fetcher.rs:133— HttpClientAdapter::send_no_follow has cognitive complexity 26 (threshold 15). Drivers by points: if/else 14 (20 pts), match/switch 2 (5 pts), loops 1 (nesting depth added 9). Of this number, 24 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ChainSearch::extend (cognitive 26) ext/node/ops/tls_wrap.rs:4386— ChainSearch::extend has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (14 pts), match/switch 5 (9 pts), loops 2, boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
IpcJsonStream::read_msg_and_raw_fd (cognitive 26) ext/process/ipc.rs:504— IpcJsonStream::read_msg_and_raw_fd has cognitive complexity 26 (threshold 15). Drivers by points: if/else 11 (22 pts), match/switch 1 (3 pts), loops 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TypesVersions::map (cognitive 26) libs/node_resolver/resolution.rs:2973— TypesVersions::map has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (21 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 13). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_client.onSocketNT (cognitive 26) REDACTED:1556— _http_client.onSocketNT has cognitive complexity 26 (threshold 15). Drivers by points: if/else 9 (18 pts), boolean chains 8 (nesting depth added 9). Of this number, 15 points are the body's own statements and 11 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_tls_common.getProtocolRange (cognitive 26) ext/node/polyfills/_tls_common.ts:290— _tls_common.getProtocolRange has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (22 pts), boolean chains 4 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._afterConnectImpl (cognitive 26) ext/node/polyfills/net.ts:503— net._afterConnectImpl has cognitive complexity 26 (threshold 15). Drivers by points: if/else 12 (20 pts), boolean chains 6 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
testing.mockModule (cognitive 26) ext/node/polyfills/testing.ts:3347— testing.mockModule has cognitive complexity 26 (threshold 15). Drivers by points: if/else 14 (18 pts), boolean chains 4, loops 1 (2 pts), ternaries 2 (nesting depth added 5). Of this number, 23 points are the body's own statements and 3 belong to one function item inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
bootstrapWorkerRuntime (cognitive 26) runtime/js/99_main.js:1200— bootstrapWorkerRuntime has cognitive complexity 26 (threshold 15). Drivers by points: if/else 11 (19 pts), ternaries 2 (4 pts), loops 1 (2 pts), other 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
constructor (cognitive 26) ext/web/02_event.js:1336— constructor has cognitive complexity 26 (threshold 15). Drivers by points: if/else 7 (11 pts), boolean chains 7, other 4, loops 1 (2 pts), ternaries 2 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
httpRedirectFetch (cognitive 26) ext/fetch/26_fetch.js:749— httpRedirectFetch has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (14 pts), boolean chains 7, loops 2 (4 pts), other 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
styleText (cognitive 26) ext/node/polyfills/internal/util/inspect.mjs:654— styleText has cognitive complexity 26 (threshold 15). Drivers by points: if/else 9 (16 pts), boolean chains 5, loops 2, other 2, ternaries 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
measure (cognitive 26) ext/web/15_performance.js:727— measure has cognitive complexity 26 (threshold 15). Drivers by points: if/else 12 (14 pts), boolean chains 10, other 1, ternaries 1 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
addRequest (cognitive 26) ext/node/polyfills/_http_agent.js:350— addRequest has cognitive complexity 26 (threshold 15). Drivers by points: if/else 13 (16 pts), boolean chains 5, ternaries 2 (3 pts), loops 1 (2 pts) (nesting depth added 5). Of this number, 23 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
printMyersDiff (cognitive 26) ext/node/polyfills/internal/assert/myers_diff.js:154— printMyersDiff has cognitive complexity 26 (threshold 15). Drivers by points: if/else 10 (18 pts), ternaries 2 (6 pts), boolean chains 1, loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DrawThread::maybe_start_draw_thread (cognitive 25) cli/util/draw_thread.rs:159— DrawThread::maybe_start_draw_thread has cognitive complexity 25 (threshold 15). Drivers by points: if/else 7 (18 pts), loops 2 (5 pts), boolean chains 2 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LocalCacheManifest::insert_data (cognitive 25) libs/cache_dir/local.rs:811— LocalCacheManifest::insert_data has cognitive complexity 25 (threshold 15). Drivers by points: if/else 11 (20 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
JsRuntimeInspector::capture_network_event (cognitive 25) libs/core/inspector.rs:1255— JsRuntimeInspector::capture_network_event has cognitive complexity 25 (threshold 15). Drivers by points: if/else 11 (22 pts), boolean chains 2, match/switch 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TtyPrompter::prompt (cognitive 25) runtime/permissions/prompter.rs:416— TtyPrompter::prompt has cognitive complexity 25 (threshold 15). Drivers by points: if/else 15 (18 pts), loops 2 (3 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 5). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
00_serve.fastSyncResponseOrStream (cognitive 25) REDACTED:579— 00_serve.fastSyncResponseOrStream has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (20 pts), boolean chains 4, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_events._listenerCount (cognitive 25) ext/node/polyfills/_events.mjs:807— _events._listenerCount has cognitive complexity 25 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 1 (4 pts), ternaries 1 (4 pts), boolean chains 2 (nesting depth added 15). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
_http_agent.Agent.removeSocket (cognitive 25) ext/node/polyfills/_http_agent.js:568— _http_agent.Agent.removeSocket has cognitive complexity 25 (threshold 15). Drivers by points: if/else 10 (19 pts), boolean chains 3, loops 2 (3 pts) (nesting depth added 10). Of this number, 22 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_client.parserOnIncomingClient (cognitive 25) REDACTED:1283— _http_client.parserOnIncomingClient has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (17 pts), boolean chains 6, ternaries 1 (2 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
_http_outgoing.write_ (cognitive 25) ext/node/polyfills/_http_outgoing.ts:1373— _http_outgoing.write_ has cognitive complexity 25 (threshold 15). Drivers by points: if/else 17 (21 pts), boolean chains 4 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
assert.ifError (cognitive 25) ext/node/polyfills/assert.ts:837— assert.ifError has cognitive complexity 25 (threshold 15). Drivers by points: if/else 8 (18 pts), loops 1 (4 pts), boolean chains 3 (nesting depth added 13). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
http2.processRespondWithFD (cognitive 25) ext/node/polyfills/http2.ts:2795— http2.processRespondWithFD has cognitive complexity 25 (threshold 15). Drivers by points: if/else 12 (13 pts), boolean chains 6, ternaries 4, error handling 2 (nesting depth added 1). Most of this is not in the body itself: 7 of the 25 points are its own statements and the rest belongs to 6 function items inside it that branch (readAndWrite, a function literal at line 2872, closeOwnedFd, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
keys.parseKeyEncoding (cognitive 25) ext/node/polyfills/internal/crypto/keys.ts:417— keys.parseKeyEncoding has cognitive complexity 25 (threshold 15). Drivers by points: if/else 9 (19 pts), boolean chains 6 (nesting depth added 10). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
inspect.inspect (cognitive 25) ext/node/polyfills/internal/util/inspect.mjs:212— inspect.inspect has cognitive complexity 25 (threshold 15). Drivers by points: if/else 11 (20 pts), loops 1 (3 pts), boolean chains 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_posix.relative (cognitive 25) ext/node/polyfills/path/_posix.ts:167— _posix.relative has cognitive complexity 25 (threshold 15). Drivers by points: if/else 12 (21 pts), loops 2, boolean chains 1, ternaries 1 (nesting depth added 9). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
listenerCount (cognitive 25) ext/node/polyfills/_events.mjs:807— listenerCount has cognitive complexity 25 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 1 (4 pts), ternaries 1 (4 pts), boolean chains 2 (nesting depth added 15). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
_write (cognitive 25) ext/node/polyfills/internal/streams/writable.js:536— _write has cognitive complexity 25 (threshold 15). Drivers by points: if/else 14 (20 pts), ternaries 1 (3 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
exec (cognitive 25) ext/web/01_urlpattern.js:362— exec has cognitive complexity 25 (threshold 15). Drivers by points: if/else 7 (14 pts), loops 2 (4 pts), ternaries 3 (4 pts), match/switch 1 (2 pts), other 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
constructor (cognitive 25) REDACTED:461— constructor has cognitive complexity 25 (threshold 15). Drivers by points: if/else 8 (17 pts), ternaries 2 (5 pts), boolean chains 2, loops 1 (nesting depth added 12). Of this number, 21 points are the body's own statements and 4 belong to 3 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
parseMimeType (cognitive 25) ext/web/01_mimesniff.js:50— parseMimeType has cognitive complexity 25 (threshold 15). Drivers by points: if/else 10 (18 pts), boolean chains 6, loops 1 (nesting depth added 8). Of this number, 24 points are the body's own statements and 1 belongs to 5 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
createHttpClient (cognitive 25) ext/fetch/22_http_client.js:23— createHttpClient has cognitive complexity 25 (threshold 15). Drivers by points: if/else 6 (16 pts), boolean chains 5, match/switch 1 (3 pts), other 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ConfigTree::refresh (cognitive 24) cli/lsp/config.rs:1922— ConfigTree::refresh has cognitive complexity 24 (threshold 15). Drivers by points: if/else 8 (18 pts), loops 3 (4 pts), boolean chains 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
IpcAdvancedStream::read_msg_bytes_and_raw_fd (cognitive 24) ext/process/ipc.rs:365— IpcAdvancedStream::read_msg_bytes_and_raw_fd has cognitive complexity 24 (threshold 15). Drivers by points: if/else 12 (23 pts), loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_tls_common.validateKeyStrength (cognitive 24) ext/node/polyfills/_tls_common.ts:187— _tls_common.validateKeyStrength has cognitive complexity 24 (threshold 15). Drivers by points: if/else 9 (14 pts), boolean chains 6, error handling 1 (2 pts), loops 1, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Socket.bind (cognitive 24) ext/node/polyfills/dgram.ts:405— Socket.bind has cognitive complexity 24 (threshold 15). Drivers by points: if/else 16 (19 pts), boolean chains 4, ternaries 1 (nesting depth added 3). Of this number, 18 points are the body's own statements and 6 belong to one function literal inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
buffer.getEncodingOps (cognitive 24) ext/node/polyfills/internal/buffer.mjs:2913— buffer.getEncodingOps has cognitive complexity 24 (threshold 15). Drivers by points: if/else 11 (22 pts), boolean chains 1, match/switch 1 (nesting depth added 11). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
utils.getDirents (cognitive 24) ext/node/polyfills/internal/fs/utils.mjs:288— utils.getDirents has cognitive complexity 24 (threshold 15). Drivers by points: if/else 7 (16 pts), error handling 1 (4 pts), loops 2 (4 pts) (nesting depth added 14). Of this number, 16 points are the body's own statements and 8 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Utf8Stream.#openFile (cognitive 24) ext/node/polyfills/internal/streams/fast-utf8-stream.js:440— Utf8Stream.#openFile has cognitive complexity 24 (threshold 15). Drivers by points: if/else 14 (19 pts), boolean chains 2, error handling 1 (2 pts), ternaries 1 (nesting depth added 6). Most of this is not in the body itself: 8 of the 24 points are its own statements and the rest belongs to 3 function items inside it that branch (fileOpened, a function literal at line 452, a function literal at line 505). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
PerformanceObserver.observe (cognitive 24) ext/web/15_performance.js:503— PerformanceObserver.observe has cognitive complexity 24 (threshold 15). Drivers by points: if/else 12 (18 pts), boolean chains 4, loops 1 (2 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
clearBuffer (cognitive 24) ext/node/polyfills/internal/streams/writable.js:850— clearBuffer has cognitive complexity 24 (threshold 15). Drivers by points: if/else 7 (8 pts), ternaries 3 (7 pts), loops 3 (6 pts), boolean chains 3 (nesting depth added 8). Of this number, 22 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_lib::args::get_root_cert_store (cognitive 23) cli/lib/args.rs:129— deno_lib::args::get_root_cert_store has cognitive complexity 23 (threshold 15). Drivers by points: if/else 5 (10 pts), match/switch 4 (8 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
MultiBackendDbHandler::open (cognitive 23) ext/kv/dynamic.rs:57— MultiBackendDbHandler::open has cognitive complexity 23 (threshold 15). Drivers by points: if/else 7 (14 pts), boolean chains 3, loops 2 (3 pts), match/switch 1 (3 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeServerCertVerifier::verify_server_cert (cognitive 23) ext/node/ops/tls_wrap.rs:4623— NodeServerCertVerifier::verify_server_cert has cognitive complexity 23 (threshold 15). Drivers by points: if/else 8 (18 pts), match/switch 2 (4 pts), boolean chains 1 (nesting depth added 12). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
Args::parse (cognitive 23) libs/dcore/src/main.rs:168— Args::parse has cognitive complexity 23 (threshold 15). Drivers by points: match/switch 5 (11 pts), if/else 4 (10 pts), boolean chains 1, loops 1 (nesting depth added 12). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
Protocol::chunked_body_chunk (cognitive 23) libs/http_h1/protocol.rs:210— Protocol::chunked_body_chunk has cognitive complexity 23 (threshold 15). Drivers by points: if/else 11 (18 pts), match/switch 2 (5 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Lexer.next (cognitive 23) REDACTED:220— Lexer.next has cognitive complexity 23 (threshold 15). Drivers by points: loops 6 (16 pts), if/else 2 (4 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 13). To reduce it, break up the iteration: give each loop body a named function, and split a multi-phase loop into one function per phase so no single body carries the whole pipeline.
97_ts_host.getModuleLiteralImportKind (cognitive 23) cli/tsc/97_ts_host.js:873— 97_ts_host.getModuleLiteralImportKind has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (17 pts), boolean chains 4, loops 1 (2 pts) (nesting depth added 8). Of this number, 21 points are the body's own statements and 2 belong to 2 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
23_response.initializeAResponse (cognitive 23) ext/fetch/23_response.js:509— 23_response.initializeAResponse has cognitive complexity 23 (threshold 15). Drivers by points: if/else 9 (17 pts), boolean chains 3, loops 1 (3 pts) (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_server.storeHTTPOptions (cognitive 23) ext/node/polyfills/_http_server.js:1434— _http_server.storeHTTPOptions has cognitive complexity 23 (threshold 15). Drivers by points: if/else 20, boolean chains 3. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
http2.doSendFileFD (cognitive 23) ext/node/polyfills/http2.ts:2959— http2.doSendFileFD has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (14 pts), ternaries 3 (5 pts), boolean chains 4 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
blocklist.parseIPInfo (cognitive 23) REDACTED:248— blocklist.parseIPInfo has cognitive complexity 23 (threshold 15). Drivers by points: if/else 8 (22 pts), loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ChildProcess.kill (cognitive 23) ext/node/polyfills/internal/child_process.ts:829— ChildProcess.kill has cognitive complexity 23 (threshold 15). Drivers by points: if/else 7 (13 pts), error handling 3 (6 pts), boolean chains 3, ternaries 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
testing.runTapTop (cognitive 23) ext/node/polyfills/testing.ts:896— testing.runTapTop has cognitive complexity 23 (threshold 15). Drivers by points: if/else 5 (9 pts), error handling 3 (8 pts), loops 3 (5 pts), boolean chains 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
flamegraph.search (cognitive 23) REDACTED:294— flamegraph.search has cognitive complexity 23 (threshold 15). Drivers by points: if/else 10 (18 pts), loops 3, boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_addHeaderLine (cognitive 23) ext/node/polyfills/_http_incoming.js:380— _addHeaderLine has cognitive complexity 23 (threshold 15). Drivers by points: if/else 13 (17 pts), boolean chains 3, ternaries 1 (3 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
AddRmPackageReq::parse (cognitive 22) cli/tools/pm/mod.rs:1081— AddRmPackageReq::parse has cognitive complexity 22 (threshold 15). Drivers by points: match/switch 6 (11 pts), if/else 6 (10 pts), loops 1 (nesting depth added 9). Of this number, 14 points are the body's own statements and 8 belong to 2 function items inside it that branch. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
DiagnosticsByFolderRealIterator::check_diagnostics_in_folder (cognitive 22) cli/type_checker.rs:642— DiagnosticsByFolderRealIterator::check_diagnostics_in_folder has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11 (13 pts), boolean chains 6, loops 3 (nesting depth added 2). Of this number, 21 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
SocketCronHandler::socket_task (cognitive 22) ext/cron/socket.rs:100— SocketCronHandler::socket_task has cognitive complexity 22 (threshold 15). Drivers by points: if/else 3 (12 pts), match/switch 4 (9 pts), loops 1 (nesting depth added 14). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_telemetry::console_exporter::format_span (cognitive 22) ext/telemetry/console_exporter.rs:55— deno_telemetry::console_exporter::format_span has cognitive complexity 22 (threshold 15). Drivers by points: if/else 5 (11 pts), loops 4 (9 pts), match/switch 2 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LockfilePackageGraph::from_lockfile (cognitive 22) libs/lockfile/graphs.rs:116— LockfilePackageGraph::from_lockfile has cognitive complexity 22 (threshold 15). Drivers by points: if/else 3 (9 pts), loops 5 (7 pts), match/switch 3 (6 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RegistryInfoProviderInner::create_load_future (cognitive 22) libs/npm_cache/registry_info.rs:295— RegistryInfoProviderInner::create_load_future has cognitive complexity 22 (threshold 15). Drivers by points: if/else 8 (11 pts), match/switch 4 (6 pts), boolean chains 5 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TarballCache::create_setup_future (cognitive 22) libs/npm_cache/tarball.rs:162— TarballCache::create_setup_future has cognitive complexity 22 (threshold 15). Drivers by points: if/else 10 (14 pts), boolean chains 4, match/switch 3 (4 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
01_cron.formatToCronSchedule (cognitive 22) ext/cron/01_cron.ts:23— 01_cron.formatToCronSchedule has cognitive complexity 22 (threshold 15). Drivers by points: if/else 13 (18 pts), boolean chains 4 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
SourceMap.#parseMap (cognitive 22) ext/node/polyfills/01_require.js:2962— SourceMap.#parseMap has cognitive complexity 22 (threshold 15). Drivers by points: if/else 4 (9 pts), boolean chains 8, loops 2 (5 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
http2.hasNonZeroContentLength (cognitive 22) ext/node/polyfills/http2.ts:1186— http2.hasNonZeroContentLength has cognitive complexity 22 (threshold 15). Drivers by points: if/else 6 (16 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
keys.getKeyObjectHandleFromJwk (cognitive 22) ext/node/polyfills/internal/crypto/keys.ts:244— keys.getKeyObjectHandleFromJwk has cognitive complexity 22 (threshold 15). Drivers by points: if/else 10 (19 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
random.validateRandomPrimeJob (cognitive 22) ext/node/polyfills/internal/crypto/random.ts:261— random.validateRandomPrimeJob has cognitive complexity 22 (threshold 15). Drivers by points: if/else 11 (18 pts), boolean chains 2, ternaries 2 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
duplex.Duplex (cognitive 22) ext/node/polyfills/internal/streams/duplex.js:76— duplex.Duplex has cognitive complexity 22 (threshold 15). Drivers by points: if/else 13 (22 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
tls_wrap.wrap (cognitive 22) ext/node/polyfills/internal_binding/tls_wrap.ts:57— tls_wrap.wrap has cognitive complexity 22 (threshold 15). Drivers by points: if/else 9 (16 pts), boolean chains 4, ternaries 2 (nesting depth added 7). Most of this is not in the body itself: 10 of the 22 points are its own statements and the rest belongs to 2 function items inside it that branch (pump, flushEncOut). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
net.Socket._destroy (cognitive 22) ext/node/polyfills/net.ts:2055— net.Socket._destroy has cognitive complexity 22 (threshold 15). Drivers by points: if/else 10 (18 pts), ternaries 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 9). Of this number, 20 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Blob.slice (cognitive 22) ext/web/09_file.js:312— Blob.slice has cognitive complexity 22 (threshold 15). Drivers by points: if/else 16 (20 pts), boolean chains 1, loops 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
prefer_primordials.insideVarDeclLhsOrMemberExprOrPropOrTypeRef (cognitive 22) tools/lint_plugins/prefer_primordials.ts:641— prefer_primordials.insideVarDeclLhsOrMemberExprOrPropOrTypeRef has cognitive complexity 22 (threshold 15). Drivers by points: if/else 8 (19 pts), boolean chains 2, loops 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
createWritableStdioStream (cognitive 22) ext/node/polyfills/_process/streams.mjs:41— createWritableStdioStream has cognitive complexity 22 (threshold 15). Drivers by points: if/else 9 (11 pts), boolean chains 5, ternaries 4, error handling 1, loops 1 (nesting depth added 2). Most of this is not in the body itself: 4 of the 22 points are its own statements and the rest belongs to 18 function items inside it that branch (write, value, getColumns, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
initStdin (cognitive 22) ext/node/polyfills/_process/streams.mjs:234— initStdin has cognitive complexity 22 (threshold 15). Drivers by points: if/else 7 (10 pts), ternaries 6 (9 pts), boolean chains 2, match/switch 1 (nesting depth added 6). Of this number, 15 points are the body's own statements and 7 belong to 14 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
errorOrDestroy (cognitive 22) ext/node/polyfills/internal/streams/destroy.js:212— errorOrDestroy has cognitive complexity 22 (threshold 15). Drivers by points: if/else 7 (10 pts), boolean chains 8, ternaries 2 (4 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ModuleGraphCreator::create_publish_graph (cognitive 21) cli/graph_util.rs:540— ModuleGraphCreator::create_publish_graph has cognitive complexity 21 (threshold 15). Drivers by points: if/else 11 (14 pts), loops 2 (4 pts), boolean chains 2, match/switch 1 (nesting depth added 5). Of this number, 20 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
Diagnostic::fmt_source_line (cognitive 21) cli/tsc/diagnostics.rs:333— Diagnostic::fmt_source_line has cognitive complexity 21 (threshold 15). Drivers by points: if/else 10 (18 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Http2Options::new (cognitive 21) ext/node/ops/http2/session.rs:388— Http2Options::new has cognitive complexity 21 (threshold 15). Drivers by points: if/else 13 (14 pts), boolean chains 5, match/switch 2 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
PackageJsonDepValue::parse (cognitive 21) libs/package_json/lib.rs:209— PackageJsonDepValue::parse has cognitive complexity 21 (threshold 15). Drivers by points: if/else 10 (17 pts), match/switch 2 (3 pts), boolean chains 1 (nesting depth added 8). Of this number, 19 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DiskCache::get_cache_filename (cognitive 21) libs/resolver/cache/disk_cache.rs:55— DiskCache::get_cache_filename has cognitive complexity 21 (threshold 15). Drivers by points: if/else 4 (10 pts), match/switch 4 (9 pts), loops 1 (2 pts) (nesting depth added 12). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
DenoGraphLoader::load_or_cache (cognitive 21) libs/resolver/file_fetcher.rs:555— DenoGraphLoader::load_or_cache has cognitive complexity 21 (threshold 15). Drivers by points: if/else 6 (11 pts), match/switch 6 (10 pts) (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
40_lint_selector.getFromRawValue (cognitive 21) REDACTED:387— 40_lint_selector.getFromRawValue has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (15 pts), ternaries 1 (3 pts), boolean chains 2, match/switch 1 (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
_http_proxy.parseProxyUrl (cognitive 21) ext/node/polyfills/_http_proxy.js:104— _http_proxy.parseProxyUrl has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (11 pts), ternaries 5 (6 pts), boolean chains 3, error handling 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
_tls_common.normalizeKeyPem (cognitive 21) ext/node/polyfills/_tls_common.ts:450— _tls_common.normalizeKeyPem has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (14 pts), error handling 1 (3 pts), boolean chains 2, loops 1, ternaries 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
https.Agent.getName (cognitive 21) ext/node/polyfills/https.ts:255— https.Agent.getName has cognitive complexity 21 (threshold 15). Drivers by points: if/else 20, boolean chains 1. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
querystring.encodeStr (cognitive 21) ext/node/polyfills/internal/querystring.ts:44— querystring.encodeStr has cognitive complexity 21 (threshold 15). Drivers by points: if/else 10 (19 pts), boolean chains 1, loops 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net._internalConnect (cognitive 21) ext/node/polyfills/net.ts:718— net._internalConnect has cognitive complexity 21 (threshold 15). Drivers by points: if/else 11 (15 pts), boolean chains 4, error handling 1 (2 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
testing.fileSnapshot (cognitive 21) ext/node/polyfills/testing.ts:330— testing.fileSnapshot has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (11 pts), error handling 3 (4 pts), loops 2 (3 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
trace_events.writeMainTraceFile (cognitive 21) ext/node/polyfills/trace_events.ts:250— trace_events.writeMainTraceFile has cognitive complexity 21 (threshold 15). Drivers by points: if/else 4 (7 pts), error handling 4 (6 pts), loops 3 (5 pts), boolean chains 3 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
url.formatWhatwg (cognitive 21) ext/node/polyfills/url.ts:1060— url.formatWhatwg has cognitive complexity 21 (threshold 15). Drivers by points: if/else 10 (17 pts), boolean chains 4 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
url.pathToFileURL (cognitive 21) ext/node/polyfills/url.ts:1609— url.pathToFileURL has cognitive complexity 21 (threshold 15). Drivers by points: if/else 7 (11 pts), boolean chains 6, ternaries 2 (4 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NodeWorker.#pollControl (cognitive 21) ext/node/polyfills/worker_threads.ts:633— NodeWorker.#pollControl has cognitive complexity 21 (threshold 15). Drivers by points: if/else 7 (18 pts), match/switch 1 (2 pts), loops 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
zlib.processChunkSync (cognitive 21) ext/node/polyfills/zlib.js:516— zlib.processChunkSync has cognitive complexity 21 (threshold 15). Drivers by points: if/else 11 (17 pts), boolean chains 2, loops 1, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TLSSocket (cognitive 21) ext/node/polyfills/_tls_wrap.js:378— TLSSocket has cognitive complexity 21 (threshold 15). Drivers by points: if/else 9 (13 pts), boolean chains 6, ternaries 2 (nesting depth added 4). Of this number, 15 points are the body's own statements and 6 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_wrapHandle (cognitive 21) ext/node/polyfills/_tls_wrap.js:575— _wrapHandle has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 3, loops 2 (3 pts), other 2, ternaries 1 (2 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Zlib (cognitive 21) ext/node/polyfills/zlib.js:862— Zlib has cognitive complexity 21 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 5, ternaries 1 (3 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
fetch (cognitive 21) ext/fetch/26_fetch.js:831— fetch has cognitive complexity 21 (threshold 15). Drivers by points: if/else 15 (18 pts), loops 1 (2 pts), other 1 (nesting depth added 4). Most of this is not in the body itself: 6 of the 21 points are its own statements and the rest belongs to 8 function items inside it that branch (a function literal at line 846, a function literal at line 904, a function literal at line 946, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
fillHeaderList (cognitive 21) ext/fetch/20_headers.js:221— fillHeaderList has cognitive complexity 21 (threshold 15). Drivers by points: if/else 5 (9 pts), loops 3 (6 pts), boolean chains 3, ternaries 1 (3 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RangeTree::normalize (cognitive 20) cli/tools/coverage/range_tree.rs:80— RangeTree::normalize has cognitive complexity 20 (threshold 15). Drivers by points: loops 5 (13 pts), if/else 3 (4 pts), match/switch 1 (2 pts), boolean chains 1 (nesting depth added 10). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
WorkspaceLinter::lint_files (cognitive 20) cli/tools/lint/mod.rs:292— WorkspaceLinter::lint_files has cognitive complexity 20 (threshold 15). Drivers by points: if/else 13 (14 pts), boolean chains 4, loops 1 (2 pts) (nesting depth added 2). Of this number, 18 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
RequestedVersion::from_upgrade_flags (cognitive 20) cli/tools/upgrade.rs:1222— RequestedVersion::from_upgrade_flags has cognitive complexity 20 (threshold 15). Drivers by points: if/else 16 (20 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
ImageBitmapRenderingContext::transfer_from_image_bitmap (cognitive 20) ext/canvas/bitmaprenderer.rs:82— ImageBitmapRenderingContext::transfer_from_image_bitmap has cognitive complexity 20 (threshold 15). Drivers by points: if/else 7 (16 pts), match/switch 2 (4 pts) (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
node_resolver::resolution::resolve_pkg_json_import (cognitive 20) libs/node_resolver/resolution.rs:2504— node_resolver::resolution::resolve_pkg_json_import has cognitive complexity 20 (threshold 15). Drivers by points: if/else 7 (17 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 11). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
MatchCtx.getAttrPathValue (cognitive 20) REDACTED:981— MatchCtx.getAttrPathValue has cognitive complexity 20 (threshold 15). Drivers by points: if/else 14 (16 pts), loops 1 (2 pts), boolean chains 1, match/switch 1 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
_fs_readdir.readdir (cognitive 20) ext/node/polyfills/_fs/_fs_readdir.ts:152— _fs_readdir.readdir has cognitive complexity 20 (threshold 15). Drivers by points: if/else 5 (12 pts), loops 2 (3 pts), error handling 1 (2 pts), ternaries 2, boolean chains 1 (nesting depth added 9). Most of this is not in the body itself: 3 of the 20 points are its own statements and the rest belongs to one function literal inside it that branches (line 178). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
crypto.hash (cognitive 20) ext/node/polyfills/crypto.ts:134— crypto.hash has cognitive complexity 20 (threshold 15). Drivers by points: if/else 10 (14 pts), boolean chains 3, ternaries 2 (3 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
util.buildNgHeaderString::processHeader (cognitive 20) ext/node/polyfills/internal/http2/util.ts:828— util.buildNgHeaderString::processHeader has cognitive complexity 20 (threshold 15). Drivers by points: if/else 10 (14 pts), loops 1 (2 pts), match/switch 1 (2 pts), boolean chains 1, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
emitKeypressEvents.emitKeypressEvents::onData (cognitive 20) ext/node/polyfills/internal/readline/emitKeypressEvents.mjs:77— emitKeypressEvents.emitKeypressEvents::onData has cognitive complexity 20 (threshold 15). Drivers by points: if/else 5 (12 pts), error handling 1 (4 pts), loops 1 (3 pts), boolean chains 1 (nesting depth added 12). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.innerDeepEqual (cognitive 20) ext/node/polyfills/internal/util/comparisons.ts:262— comparisons.innerDeepEqual has cognitive complexity 20 (threshold 15). Drivers by points: if/else 7 (11 pts), boolean chains 9 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
buffer.indexOfBuffer (cognitive 20) ext/node/polyfills/internal_binding/buffer.ts:104— buffer.indexOfBuffer has cognitive complexity 20 (threshold 15). Drivers by points: if/else 10 (11 pts), boolean chains 6, ternaries 3 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_win32.extname (cognitive 20) ext/node/polyfills/path/_win32.ts:961— _win32.extname has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (16 pts), boolean chains 3, loops 1 (nesting depth added 7). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
repl._memory (cognitive 20) ext/node/polyfills/repl.ts:536— repl._memory has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (15 pts), boolean chains 2, ternaries 1 (2 pts), loops 1 (nesting depth added 7). Most of this is not in the body itself: 8 of the 20 points are its own statements and the rest belongs to 2 function items inside it that branch (a function literal at line 563, countMatches). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
MockTimers.enable (cognitive 20) ext/node/polyfills/testing.ts:2644— MockTimers.enable has cognitive complexity 20 (threshold 15). Drivers by points: if/else 12 (15 pts), loops 3 (4 pts), boolean chains 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
NodeWorker.#pollMessages (cognitive 20) ext/node/polyfills/worker_threads.ts:746— NodeWorker.#pollMessages has cognitive complexity 20 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
06_streams.fastPipeTo (cognitive 20) ext/web/06_streams.js:3155— 06_streams.fastPipeTo has cognitive complexity 20 (threshold 15). Drivers by points: error handling 4 (9 pts), if/else 6 (8 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
13_message_port.serializeJsMessageData (cognitive 20) ext/web/13_message_port.js:898— 13_message_port.serializeJsMessageData has cognitive complexity 20 (threshold 15). Drivers by points: if/else 10 (16 pts), boolean chains 2, loops 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Worker.#pollMessages (cognitive 20) runtime/js/11_workers.js:286— Worker.#pollMessages has cognitive complexity 20 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
lint.ensureDisallowedMethodsEnforced (cognitive 20) tools/lint.js:694— lint.ensureDisallowedMethodsEnforced has cognitive complexity 20 (threshold 15). Drivers by points: if/else 5 (9 pts), error handling 3 (5 pts), loops 4 (5 pts), ternaries 1 (nesting depth added 7). Of this number, 15 points are the body's own statements and 5 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
generate_macos_function_orderfile.parseArgs (cognitive 20) tools/startup_order/generate_macos_function_orderfile.ts:46— generate_macos_function_orderfile.parseArgs has cognitive complexity 20 (threshold 15). Drivers by points: if/else 10 (16 pts), boolean chains 3, loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
writableStreamForRid (cognitive 20) ext/web/06_streams.js:1486— writableStreamForRid has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (12 pts), ternaries 4 (5 pts), error handling 2, other 1 (nesting depth added 4). Most of this is not in the body itself: 7 of the 20 points are its own statements and the rest belongs to 7 function items inside it that branch (write, tryClose, flushBuffer, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
_startEsmLoadLoop (cognitive 20) ext/node/polyfills/01_require.js:868— _startEsmLoadLoop has cognitive complexity 20 (threshold 15). Drivers by points: if/else 6 (9 pts), loops 2 (4 pts), boolean chains 3, error handling 1 (2 pts), other 2 (nesting depth added 6). Most of this is not in the body itself: 1 of the 20 points is its own statement and the rest belongs to one function literal inside it that branches (line 871). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
D2 · Cognitive Complexity· Server (cognitive 20) · ×1
Server (cognitive 20) ext/node/polyfills/_tls_wrap.js:1384— Server has cognitive complexity 20 (threshold 15). Drivers by points: if/else 14 (17 pts), boolean chains 2, ternaries 1 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
newWritableStreamFromStreamWritable (cognitive 20) ext/node/polyfills/internal/webstreams/adapters.js:619— newWritableStreamFromStreamWritable has cognitive complexity 20 (threshold 15). Drivers by points: if/else 11 (13 pts), boolean chains 6, ternaries 1 (nesting depth added 2). Most of this is not in the body itself: 6 of the 20 points are its own statements and the rest belongs to 8 function items inside it that branch (a function literal at line 657, write, close, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
WriteStream (cognitive 20) ext/node/polyfills/internal/fs/streams.mjs:392— WriteStream has cognitive complexity 20 (threshold 15). Drivers by points: if/else 13, ternaries 3 (5 pts), boolean chains 2 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
createErrDiff (cognitive 20) ext/node/polyfills/internal/assert/assertion_error.js:224— createErrDiff has cognitive complexity 20 (threshold 15). Drivers by points: if/else 9 (14 pts), ternaries 2 (4 pts), boolean chains 2 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(anonymous) (cognitive 20) runtime/js/11_workers.js:286— (anonymous) has cognitive complexity 20 (threshold 15). Drivers by points: if/else 6 (15 pts), loops 2 (3 pts), boolean chains 2 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
RedirectResolver::resolve (cognitive 19) cli/lsp/resolver.rs:1520— RedirectResolver::resolve has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (14 pts), match/switch 1 (3 pts), loops 2 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DenoPluginHandler::bundle_load (cognitive 19) cli/tools/bundle/mod.rs:2171— DenoPluginHandler::bundle_load has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (12 pts), match/switch 4 (7 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
BinaryNameAndUrl::resolve (cognitive 19) cli/tools/installer/global.rs:1043— BinaryNameAndUrl::resolve has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (15 pts), loops 1 (2 pts), boolean chains 1, match/switch 1 (nesting depth added 7). Of this number, 17 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
PackagePath::new (cognitive 19) cli/tools/publish/paths.rs:63— PackagePath::new has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (15 pts), match/switch 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TsFn::call (cognitive 19) ext/napi/node_api.rs:1064— TsFn::call has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (17 pts), loops 1 (2 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DOMMatrixReadOnly::from_matrix_inner (cognitive 19) ext/web/geometry.rs:1388— DOMMatrixReadOnly::from_matrix_inner has cognitive complexity 19 (threshold 15). Drivers by points: if/else 11 (15 pts), boolean chains 4 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
LocalHttpCache::get (cognitive 19) libs/cache_dir/local.rs:442— LocalHttpCache::get has cognitive complexity 19 (threshold 15). Drivers by points: if/else 6 (14 pts), match/switch 2 (4 pts), boolean chains 1 (nesting depth added 10). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
NpmResolutionSnapshot::as_valid_serialized_for_system (cognitive 19) libs/npm/resolution/snapshot.rs:614— NpmResolutionSnapshot::as_valid_serialized_for_system has cognitive complexity 19 (threshold 15). Drivers by points: if/else 3 (11 pts), loops 4 (7 pts), boolean chains 1 (nesting depth added 11). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
DictionaryField::try_from (cognitive 19) libs/ops/webidl/dictionary.rs:170— DictionaryField::try_from has cognitive complexity 19 (threshold 15). Drivers by points: match/switch 3 (9 pts), if/else 4 (6 pts), loops 2 (4 pts) (nesting depth added 10). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
00_serve.mapToNativeResponseCallback::finishOrReturnNative (cognitive 19) REDACTED:924— 00_serve.mapToNativeResponseCallback::finishOrReturnNative has cognitive complexity 19 (threshold 15). Drivers by points: if/else 14 (17 pts), boolean chains 2 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
KvListIterator.constructor (cognitive 19) ext/kv/01_db.ts:845— KvListIterator.constructor has cognitive complexity 19 (threshold 15). Drivers by points: if/else 11 (14 pts), boolean chains 5 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
01_require.executeEsmLoadHookChain (cognitive 19) ext/node/polyfills/01_require.js:794— 01_require.executeEsmLoadHookChain has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (13 pts), error handling 1 (3 pts), boolean chains 2, loops 1 (nesting depth added 7). Most of this is not in the body itself: 4 of the 19 points are its own statements and the rest belongs to one function item inside it that branches (nextLoad). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
_events.EventEmitter.removeAllListeners (cognitive 19) ext/node/polyfills/_events.mjs:712— _events.EventEmitter.removeAllListeners has cognitive complexity 19 (threshold 15). Drivers by points: if/else 10 (15 pts), loops 2 (4 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_client.parseContentTypeFromRawHeaders (cognitive 19) REDACTED:238— _http_client.parseContentTypeFromRawHeaders has cognitive complexity 19 (threshold 15). Drivers by points: if/else 6 (13 pts), loops 2 (4 pts), boolean chains 1, ternaries 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_readline._ttyWriteDumb (cognitive 19) ext/node/polyfills/_readline.mjs:474— _readline._ttyWriteDumb has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (14 pts), boolean chains 4, match/switch 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ServerHttp2Session.altsvc (cognitive 19) ext/node/polyfills/http2.ts:4575— ServerHttp2Session.altsvc has cognitive complexity 19 (threshold 15). Drivers by points: if/else 11 (15 pts), boolean chains 4 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
myers_diff.backtrack (cognitive 19) ext/node/polyfills/internal/assert/myers_diff.js:85— myers_diff.backtrack has cognitive complexity 19 (threshold 15). Drivers by points: if/else 5 (9 pts), boolean chains 4, loops 2 (3 pts), ternaries 1 (3 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_randomBytes.randomBytes (cognitive 19) ext/node/polyfills/internal/crypto/_randomBytes.ts:80— _randomBytes.randomBytes has cognitive complexity 19 (threshold 15). Drivers by points: if/else 9 (14 pts), error handling 2 (4 pts), boolean chains 1 (nesting depth added 7). Most of this is not in the body itself: 9 of the 19 points are its own statements and the rest belongs to one function literal inside it that branches (line 107). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
net._internalConnectMultiple (cognitive 19) ext/node/polyfills/net.ts:807— net._internalConnectMultiple has cognitive complexity 19 (threshold 15). Drivers by points: if/else 14 (18 pts), boolean chains 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
TestSuite.addTest (cognitive 19) ext/node/polyfills/testing.ts:1758— TestSuite.addTest has cognitive complexity 19 (threshold 15). Drivers by points: loops 7 (9 pts), error handling 3 (6 pts), if/else 2 (3 pts), boolean chains 1 (nesting depth added 6). Most of this is not in the body itself: 1 of the 19 points is its own statement and the rest belongs to one function literal inside it that branches (line 1765). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
06_streams.readableByteStreamControllerEnqueue (cognitive 19) ext/web/06_streams.js:1772— 06_streams.readableByteStreamControllerEnqueue has cognitive complexity 19 (threshold 15). Drivers by points: if/else 13 (18 pts), boolean chains 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
readableStreamCollectIntoUint8Array (cognitive 19) ext/web/06_streams.js:1372— readableStreamCollectIntoUint8Array has cognitive complexity 19 (threshold 15). Drivers by points: if/else 8 (12 pts), loops 3, boolean chains 2, error handling 1 (2 pts) (nesting depth added 5). Of this number, 14 points are the body's own statements and 5 belong to 4 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
readableStreamPipeTo::pump (cognitive 19) ext/web/06_streams.js:3413— readableStreamPipeTo::pump has cognitive complexity 19 (threshold 15). Drivers by points: if/else 6 (14 pts), boolean chains 3, loops 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
bidirectionalIndexOf (cognitive 19) ext/node/polyfills/internal/buffer.mjs:970— bidirectionalIndexOf has cognitive complexity 19 (threshold 15). Drivers by points: if/else 12 (13 pts), ternaries 2 (4 pts), boolean chains 2 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
refresh (cognitive 19) libs/npm/resolution/tracing/app.js:71— refresh has cognitive complexity 19 (threshold 15). Drivers by points: loops 6 (7 pts), if/else 4 (5 pts), other 5, ternaries 2 (nesting depth added 2). Most of this is not in the body itself: 2 of the 19 points are its own statements and the rest belongs to 26 function items inside it that branch (getNodesAndLinks, getNodesAndLinks::getNodeY, createGraph, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
createPreviewSession (cognitive 19) ext/node/polyfills/_repl_preview.js:54— createPreviewSession has cognitive complexity 19 (threshold 15). Drivers by points: if/else 7 (11 pts), error handling 3 (4 pts), boolean chains 3, loops 1 (nesting depth added 5). Of this number, 16 points are the body's own statements and 3 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
HttpClient::get_redirected_response (cognitive 18) cli/http_util.rs:420— HttpClient::get_redirected_response has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (15 pts), loops 1 (2 pts), boolean chains 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ExternalsMatcher::new (cognitive 18) cli/tools/bundle/externals.rs:75— ExternalsMatcher::new has cognitive complexity 18 (threshold 15). Drivers by points: if/else 7 (17 pts), loops 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ReplSession::evaluate_line_and_get_output::inner (cognitive 18) cli/tools/repl/session.rs:509— ReplSession::evaluate_line_and_get_output::inner has cognitive complexity 18 (threshold 15). Drivers by points: if/else 5 (9 pts), match/switch 4 (9 pts) (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
NetworkStreamPrefixCheck::match_prefix_or_shutdown (cognitive 18) ext/http/network_buffered_stream.rs:110— NetworkStreamPrefixCheck::match_prefix_or_shutdown has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (15 pts), match/switch 1 (2 pts), loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_net::ops::op_net_connect_tcp_inner (cognitive 18) ext/net/ops.rs:607— deno_net::ops::op_net_connect_tcp_inner has cognitive complexity 18 (threshold 15). Drivers by points: if/else 10 (11 pts), match/switch 2 (4 pts), boolean chains 2, loops 1 (nesting depth added 3). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
AggregateFunctionOption::from_value (cognitive 18) ext/node_sqlite/database.rs:433— AggregateFunctionOption::from_value has cognitive complexity 18 (threshold 15). Drivers by points: if/else 14 (18 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
SessionContainer::dispatch_message_from_frontend (cognitive 18) libs/core/inspector.rs:1626— SessionContainer::dispatch_message_from_frontend has cognitive complexity 18 (threshold 15). Drivers by points: if/else 5 (11 pts), match/switch 2 (6 pts), boolean chains 1 (nesting depth added 10). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
dcore::inspector_server::server (cognitive 18) libs/dcore/src/inspector_server.rs:301— dcore::inspector_server::server has cognitive complexity 18 (threshold 15). Drivers by points: match/switch 7 (14 pts), if/else 1 (3 pts), loops 1 (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
StructField::try_from (cognitive 18) libs/ops/conversion/from_v8/struct.rs:156— StructField::try_from has cognitive complexity 18 (threshold 15). Drivers by points: match/switch 3 (9 pts), if/else 3 (5 pts), loops 2 (4 pts) (nesting depth added 10). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
Host::parse_inner (cognitive 18) runtime/permissions/lib.rs:1912— Host::parse_inner has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11 (16 pts), boolean chains 2 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Cache.put (cognitive 18) ext/cache/01_cache.js:127— Cache.put has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11 (14 pts), boolean chains 2, loops 1 (2 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
30_fs.createByteStruct (cognitive 18) ext/fs/30_fs.js:359— 30_fs.createByteStruct has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (15 pts), boolean chains 2, loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
01_require.executeResolveHookChain (cognitive 18) ext/node/polyfills/01_require.js:544— 01_require.executeResolveHookChain has cognitive complexity 18 (threshold 15). Drivers by points: if/else 10 (14 pts), boolean chains 3, loops 1 (nesting depth added 4). Most of this is not in the body itself: 4 of the 18 points are its own statements and the rest belongs to one function item inside it that branches (nextResolve). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
_fs_read.read (cognitive 18) ext/node/polyfills/_fs/_fs_read.ts:75— _fs_read.read has cognitive complexity 18 (threshold 15). Drivers by points: if/else 12 (16 pts), boolean chains 1, ternaries 1 (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
_http_client.joinRequestHeadersForCdp (cognitive 18) REDACTED:182— _http_client.joinRequestHeadersForCdp has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (14 pts), loops 2 (4 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_client.socketCloseListener (cognitive 18) REDACTED:1110— _http_client.socketCloseListener has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11 (15 pts), boolean chains 3 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
assert.expectsError (cognitive 18) ext/node/polyfills/assert.ts:362— assert.expectsError has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (14 pts), boolean chains 2, ternaries 1 (2 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
fs.write (cognitive 18) ext/node/polyfills/fs.ts:2498— fs.write has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (14 pts), boolean chains 3, ternaries 1 (nesting depth added 5). Of this number, 16 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
fs.writeFile (cognitive 18) ext/node/polyfills/fs.ts:2765— fs.writeFile has cognitive complexity 18 (threshold 15). Drivers by points: if/else 10 (11 pts), boolean chains 5, error handling 1, ternaries 1 (nesting depth added 1). Of this number, 9 points are the body's own statements and 9 belong to 2 function literals inside it that branch. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
fs.watchPromise (cognitive 18) ext/node/polyfills/fs.ts:3630— fs.watchPromise has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 2, ternaries 1 (2 pts), loops 1 (nesting depth added 6). Of this number, 16 points are the body's own statements and 2 belong to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
http2.getUnpackedSettings (cognitive 18) ext/node/polyfills/http2.ts:5518— http2.getUnpackedSettings has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (14 pts), boolean chains 3, loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
buffer.byteLength (cognitive 18) ext/node/polyfills/internal/buffer.mjs:641— buffer.byteLength has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (12 pts), ternaries 2 (4 pts), boolean chains 2 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
cipher.prepareKey (cognitive 18) ext/node/polyfills/internal/crypto/cipher.ts:884— cipher.prepareKey has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (12 pts), boolean chains 3, ternaries 1 (3 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
address_override.h2ShadowServer (cognitive 18) ext/node/polyfills/internal/http/address_override.js:398— address_override.h2ShadowServer has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (13 pts), boolean chains 3, loops 2 (nesting depth added 4). Most of this is not in the body itself: 1 of the 18 points is its own statement and the rest belongs to 2 function literals inside it that branch (lines 404, 478). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
JSStreamSocket.constructor (cognitive 18) ext/node/polyfills/internal/js_stream_socket.js:70— JSStreamSocket.constructor has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8, loops 2 (4 pts), boolean chains 3, ternaries 1 (3 pts) (nesting depth added 4). Of this number, 12 points are the body's own statements and 6 belong to 2 function items inside it that branch. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Utf8Stream.constructor (cognitive 18) ext/node/polyfills/internal/streams/fast-utf8-stream.js:103— Utf8Stream.constructor has cognitive complexity 18 (threshold 15). Drivers by points: boolean chains 10, if/else 8. Of this number, 17 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, name the conditions: bind each compound test to a well-named local or a small predicate function, so the body reads as a sequence of named decisions rather than a chain of operators.
Utf8Stream.#flushSyncUtf8 (cognitive 18) ext/node/polyfills/internal/streams/fast-utf8-stream.js:647— Utf8Stream.#flushSyncUtf8 has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (10 pts), boolean chains 4, error handling 2 (3 pts), loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
comparisons.setEquiv (cognitive 18) ext/node/polyfills/internal/util/comparisons.ts:890— comparisons.setEquiv has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (14 pts), boolean chains 3, loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
cares_wrap.getaddrinfo (cognitive 18) ext/node/polyfills/internal_binding/cares_wrap.ts:126— cares_wrap.getaddrinfo has cognitive complexity 18 (threshold 15). Drivers by points: if/else 12 (15 pts), boolean chains 2, error handling 1 (nesting depth added 3). None of this is in the body itself: all 18 points belong to 3 function literals inside it that branch (lines 138, 174, 184). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
_posix.extname (cognitive 18) ext/node/polyfills/path/_posix.ts:359— _posix.extname has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (15 pts), boolean chains 2, loops 1 (nesting depth added 7). This file's own header attributes it to another copyright holder, so it is code this repository carries rather than code it wrote: restructuring the body in place forks it from upstream and turns every future re-sync into a manual merge. The performable moves are to leave the body as close to its upstream form as possible and keep it behind a narrow interface of your own, and to re-sync it when upstream changes — or, if it has already diverged far enough that you maintain it here, adopt it deliberately and then split the body into named stages.
repl.defineDefaultCommands (cognitive 18) ext/node/polyfills/repl.ts:409— repl.defineDefaultCommands has cognitive complexity 18 (threshold 15). Drivers by points: if/else 12 (14 pts), error handling 2, boolean chains 1, ternaries 1 (nesting depth added 2). Most of this is not in the body itself: 2 of the 18 points are its own statements and the rest belongs to 5 function literals inside it that branch (lines 491, 471, 426, …). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
WASI.constructor (cognitive 18) ext/node/polyfills/wasi.ts:145— WASI.constructor has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11, error handling 1 (3 pts), loops 2 (3 pts), boolean chains 1 (nesting depth added 3). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
13_message_port.fastSerialize (cognitive 18) ext/web/13_message_port.js:749— 13_message_port.fastSerialize has cognitive complexity 18 (threshold 15). Drivers by points: if/else 5 (10 pts), loops 2 (4 pts), ternaries 1 (2 pts), boolean chains 1, match/switch 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
generate_types_deno.createDenoDtsFile (cognitive 18) tools/generate_types_deno.ts:33— generate_types_deno.createDenoDtsFile has cognitive complexity 18 (threshold 15). Drivers by points: if/else 6 (12 pts), loops 3 (5 pts), boolean chains 1 (nesting depth added 8). Of this number, 13 points are the body's own statements and 5 belong to 2 function items inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
stripTypeScriptTypes (cognitive 18) ext/node/polyfills/01_require.js:3203— stripTypeScriptTypes has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (9 pts), boolean chains 7, error handling 1, other 1 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
#receiveDatagrams (cognitive 18) ext/web/webtransport.js:699— #receiveDatagrams has cognitive complexity 18 (threshold 15). Drivers by points: if/else 4 (8 pts), loops 3 (5 pts), error handling 2 (3 pts), boolean chains 1, other 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(computed) (cognitive 18) ext/fetch/20_headers.js:363— (computed) has cognitive complexity 18 (threshold 15). Drivers by points: if/else 8 (12 pts), ternaries 1 (4 pts), boolean chains 1, loops 1 (nesting depth added 7). Of this number, 16 points are the body's own statements and 2 belong to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
newStreamDuplexFromReadableWritablePair (cognitive 18) ext/node/polyfills/internal/webstreams/adapters.js:288— newStreamDuplexFromReadableWritablePair has cognitive complexity 18 (threshold 15). Drivers by points: if/else 10, error handling 5, boolean chains 3. Most of this is not in the body itself: 4 of the 18 points are its own statements and the rest belongs to 23 function items inside it that branch (write, a function literal at line 412, destroy, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
timerify (cognitive 18) ext/node/polyfills/perf_hooks.js:216— timerify has cognitive complexity 18 (threshold 15). Drivers by points: if/else 7 (9 pts), boolean chains 6, ternaries 2, error handling 1 (nesting depth added 2). Most of this is not in the body itself: 7 of the 18 points are its own statements and the rest belongs to 2 function items inside it that branch (timerified, a function literal at line 266). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
ReadStream (cognitive 18) ext/node/polyfills/internal/fs/streams.mjs:198— ReadStream has cognitive complexity 18 (threshold 15). Drivers by points: if/else 9 (10 pts), ternaries 3 (5 pts), boolean chains 2, other 1 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
(anonymous) (cognitive 18) ext/node/polyfills/internal/timers.mjs:175— (anonymous) has cognitive complexity 18 (threshold 15). Drivers by points: if/else 11 (14 pts), boolean chains 3, ternaries 1 (nesting depth added 3). Most of this is not in the body itself: 2 of the 18 points are its own statements and the rest belongs to 3 function items inside it that branch (invokeCallback, cb, cb). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
encodeLockName (cognitive 18) ext/web/locks.js:39— encodeLockName has cognitive complexity 18 (threshold 15). Drivers by points: if/else 7 (13 pts), boolean chains 3, loops 1, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
CliOptions::resolve_config_permissions_for_dir (cognitive 17) cli/args/mod.rs:1260— CliOptions::resolve_config_permissions_for_dir has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (10 pts), match/switch 3 (7 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
TransformListParser::next (cognitive 17) ext/web/css_value.rs:2601— TransformListParser::next has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (11 pts), match/switch 2 (6 pts) (nesting depth added 6). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
deno_websocket::op_ws_next_event (cognitive 17) ext/websocket/lib.rs:993— deno_websocket::op_ws_next_event has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (9 pts), match/switch 3 (7 pts), loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
FileFetcher::should_use_cache (cognitive 17) libs/cache_dir/file_fetcher/mod.rs:972— FileFetcher::should_use_cache has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (14 pts), loops 1 (2 pts), match/switch 1 (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
LocalCacheManifestData::new (cognitive 17) libs/cache_dir/local.rs:971— LocalCacheManifestData::new has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (14 pts), boolean chains 1, loops 1, match/switch 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_npmrc::ini::parse_quoted_string::take_inner_text (cognitive 17) libs/npmrc/ini.rs:202— deno_npmrc::ini::parse_quoted_string::take_inner_text has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (15 pts), boolean chains 1, loops 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
MacroConfig::from_metas (cognitive 17) libs/ops/op2/config.rs:96— MacroConfig::from_metas has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (8 pts), match/switch 2 (5 pts), boolean chains 3, loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WorkspaceFactory::raw_node_modules_dir_mode (cognitive 17) libs/resolver/factory.rs:342— WorkspaceFactory::raw_node_modules_dir_mode has cognitive complexity 17 (threshold 15). Drivers by points: if/else 11 (16 pts), boolean chains 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
PreparedModuleLoader::load_prepared_module_or_defer_emit (cognitive 17) libs/resolver/loader/module_loader.rs:514— PreparedModuleLoader::load_prepared_module_or_defer_emit has cognitive complexity 17 (threshold 15). Drivers by points: match/switch 6 (12 pts), if/else 2 (5 pts) (nesting depth added 9). To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
40_lint.subTraverse (cognitive 17) REDACTED:1415— 40_lint.subTraverse has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (12 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
20_headers.getDecodeSplitHeader (cognitive 17) ext/fetch/20_headers.js:312— 20_headers.getDecodeSplitHeader has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (15 pts), boolean chains 1, loops 1 (nesting depth added 9). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
02_websocket.buildCaseInsensitiveCommaValueFinder (cognitive 17) ext/http/02_websocket.ts:246— 02_websocket.buildCaseInsensitiveCommaValueFinder has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (9 pts), boolean chains 4, loops 4 (nesting depth added 4). None of this is in the body itself: all 17 points belong to 4 function items inside it that branch (a function literal at line 263, hasWord, skipWhitespace, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
_fs_readdir.readdirSync (cognitive 17) ext/node/polyfills/_fs/_fs_readdir.ts:265— _fs_readdir.readdirSync has cognitive complexity 17 (threshold 15). Drivers by points: if/else 4 (11 pts), loops 2 (3 pts), error handling 1 (2 pts), boolean chains 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
myers_diff.myersDiff (cognitive 17) ext/node/polyfills/internal/assert/myers_diff.js:34— myers_diff.myersDiff has cognitive complexity 17 (threshold 15). Drivers by points: loops 3 (6 pts), boolean chains 4, if/else 2 (4 pts), ternaries 1 (3 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
buffer._from (cognitive 17) ext/node/polyfills/internal/buffer.mjs:310— buffer._from has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (13 pts), boolean chains 4 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
child_process.normalizeStdioOption (cognitive 17) ext/node/polyfills/internal/child_process.ts:1070— child_process.normalizeStdioOption has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (9 pts), boolean chains 4, loops 1 (2 pts), match/switch 1 (2 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
cipher.Cipheriv.final (cognitive 17) ext/node/polyfills/internal/crypto/cipher.ts:258— cipher.Cipheriv.final has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (8 pts), ternaries 3 (6 pts), boolean chains 3 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
cipher.Cipheriv.update (cognitive 17) ext/node/polyfills/internal/crypto/cipher.ts:339— cipher.Cipheriv.update has cognitive complexity 17 (threshold 15). Drivers by points: if/else 13 (17 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level. This shape REPEATS in the file: one other method here (cipher.Decipheriv.update) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
cipher.Decipheriv.update (cognitive 17) ext/node/polyfills/internal/crypto/cipher.ts:674— cipher.Decipheriv.update has cognitive complexity 17 (threshold 15). Drivers by points: if/else 13 (17 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level. This shape REPEATS in the file: one other method here (cipher.Cipheriv.update) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
keys.prepareAsymmetricKey (cognitive 17) ext/node/polyfills/internal/crypto/keys.ts:342— keys.prepareAsymmetricKey has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (13 pts), boolean chains 2, ternaries 1 (2 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
promises.lookup (cognitive 17) ext/node/polyfills/internal/dns/promises.ts:174— promises.lookup has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (14 pts), match/switch 1 (3 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Http2ServerResponse.end (cognitive 17) ext/node/polyfills/internal/http2/compat.js:875— Http2ServerResponse.end has cognitive complexity 17 (threshold 15). Drivers by points: if/else 11 (13 pts), boolean chains 4 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
warning.onWarning (cognitive 17) ext/node/polyfills/internal/process/warning.ts:18— warning.onWarning has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8, boolean chains 7, loops 1 (2 pts) (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
Interface.[kTabCompleter] (cognitive 17) ext/node/polyfills/internal/readline/interface.mjs:710— Interface.[kTabCompleter] has cognitive complexity 17 (threshold 15). Drivers by points: if/else 10 (12 pts), boolean chains 4, loops 1 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
Utf8Stream.#flushBufferSync (cognitive 17) ext/node/polyfills/internal/streams/fast-utf8-stream.js:606— Utf8Stream.#flushBufferSync has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (10 pts), boolean chains 4, error handling 1 (2 pts), loops 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
buffer.searchBytes (cognitive 17) ext/node/polyfills/internal_binding/buffer.ts:64— buffer.searchBytes has cognitive complexity 17 (threshold 15). Drivers by points: loops 4 (8 pts), if/else 4 (7 pts), boolean chains 2 (nesting depth added 7). To reduce it, break up the iteration: give each loop body a named function, and split a multi-phase loop into one function per phase so no single body carries the whole pipeline.
ChannelWrap.getHostByAddr (cognitive 17) ext/node/polyfills/internal_binding/cares_wrap.ts:806— ChannelWrap.getHostByAddr has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (9 pts), loops 2 (6 pts), boolean chains 2 (nesting depth added 6). Of this number, 16 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
querystring.unescapeBuffer (cognitive 17) ext/node/polyfills/querystring.js:396— querystring.unescapeBuffer has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (13 pts), boolean chains 2, loops 1, ternaries 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
worker_threads.postMessageToThread (cognitive 17) ext/node/polyfills/worker_threads.ts:1597— worker_threads.postMessageToThread has cognitive complexity 17 (threshold 15). Drivers by points: if/else 10 (12 pts), error handling 3, boolean chains 2 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
01_core.runImmediates (cognitive 17) libs/core/01_core.js:209— 01_core.runImmediates has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (15 pts), loops 1, ternaries 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
10_permissions.cache (cognitive 17) runtime/js/10_permissions.js:134— 10_permissions.cache has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (9 pts), boolean chains 8 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
prefer_primordials.walkChildren (cognitive 17) tools/lint_plugins/prefer_primordials.ts:523— prefer_primordials.walkChildren has cognitive complexity 17 (threshold 15). Drivers by points: if/else 5 (11 pts), loops 2 (4 pts), boolean chains 2 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
copyright_checker.checkCopyright (cognitive 17) tools/copyright_checker.js:23— copyright_checker.checkCopyright has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (12 pts), loops 2 (4 pts), boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
lint.lintNodePolyfillDenoApis (cognitive 17) tools/lint.js:230— lint.lintNodePolyfillDenoApis has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (7 pts), loops 4 (6 pts), boolean chains 4 (nesting depth added 3). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
install_api.findBinDir (cognitive 17) tools/release/npm/install_api.cjs:192— install_api.findBinDir has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (13 pts), ternaries 1 (3 pts), loops 1 (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
readableByteStreamTee::closeSteps (cognitive 17) ext/web/06_streams.js:4108— readableByteStreamTee::closeSteps has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (11 pts), ternaries 4, boolean chains 2 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
executeEsmResolveHookChain (cognitive 17) ext/node/polyfills/01_require.js:708— executeEsmResolveHookChain has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (8 pts), error handling 2 (5 pts), boolean chains 2, loops 1, other 1 (nesting depth added 5). Most of this is not in the body itself: 4 of the 17 points are its own statements and the rest belongs to 2 function items inside it that branch (nextResolve, nextResolve::wrappedNext). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
concat (cognitive 17) ext/node/polyfills/internal/buffer.mjs:586— concat has cognitive complexity 17 (threshold 15). Drivers by points: if/else 7 (10 pts), ternaries 1 (4 pts), loops 2 (3 pts) (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
addChunk (cognitive 17) ext/node/polyfills/internal/streams/readable.js:596— addChunk has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (14 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
createAsyncIterator (cognitive 17) ext/node/polyfills/internal/streams/readable.js:1467— createAsyncIterator has cognitive complexity 17 (threshold 15). Drivers by points: if/else 8 (9 pts), boolean chains 3, ternaries 2 (3 pts), error handling 1, loops 1 (nesting depth added 2). Of this number, 14 points are the body's own statements and 3 belong to 2 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
structuredClone (cognitive 17) ext/web/13_message_port.js:1094— structuredClone has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (10 pts), boolean chains 5, error handling 1 (2 pts) (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_addListener (cognitive 17) ext/node/polyfills/_events.mjs:500— _addListener has cognitive complexity 17 (threshold 15). Drivers by points: if/else 9 (12 pts), ternaries 1 (3 pts), boolean chains 1, other 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
readable (cognitive 17) ext/web/webtransport.js:871— readable has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (12 pts), error handling 2 (4 pts), boolean chains 1 (nesting depth added 8). Most of this is not in the body itself: 1 of the 17 points is its own statement and the rest belongs to 5 function items inside it that branch (pull, a function literal at line 879, a function literal at line 886, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
keepSocketAlive (cognitive 17) ext/node/polyfills/_http_agent.js:630— keepSocketAlive has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (12 pts), ternaries 1 (4 pts), boolean chains 1 (nesting depth added 9). To reduce it, flatten the nesting: this score is depth rather than breadth — most of its points come from checks stacked inside one another, so the work sits several levels in. Invert each enclosing check into an early exit (a return, or the language's equivalent) so the happy path stays at one level, and where a level cannot be exited early, lift the block it encloses into its own named function.
map::map::pump (cognitive 17) ext/node/polyfills/internal/streams/operators.js:146— map::map::pump has cognitive complexity 17 (threshold 15). Drivers by points: if/else 6 (11 pts), error handling 2 (3 pts), boolean chains 2, loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
Documents::change_notebook (cognitive 16) cli/lsp/documents.rs:705— Documents::change_notebook has cognitive complexity 16 (threshold 15). Drivers by points: if/else 3 (6 pts), loops 3 (5 pts), match/switch 2 (5 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
BinNameResolver::infer_name_from_url (cognitive 16) cli/tools/installer/bin_name_resolver.rs:32— BinNameResolver::infer_name_from_url has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (9 pts), boolean chains 4, match/switch 2 (3 pts) (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
BarProgressBarRenderer::render (cognitive 16) cli/util/progress_bar/renderer.rs:42— BarProgressBarRenderer::render has cognitive complexity 16 (threshold 15). Drivers by points: if/else 14 (16 pts) (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
CjsCodeAnalyzer::inner_cjs_analysis (cognitive 16) cli/rt/node.rs:70— CjsCodeAnalyzer::inner_cjs_analysis has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (11 pts), match/switch 2 (5 pts) (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
deno_fs::std_fs::cp (cognitive 16) ext/fs/std_fs.rs:745— deno_fs::std_fs::cp has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9 (11 pts), boolean chains 5 (nesting depth added 2). Of this number, 8 points are the body's own statements and 8 belong to 2 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
AuthDomain::matches (cognitive 16) libs/cache_dir/file_fetcher/auth_tokens.rs:79— AuthDomain::matches has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (12 pts), boolean chains 3, match/switch 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WorkspaceDirectory::discover::resolve_start_dir (cognitive 16) libs/config/workspace/mod.rs:1951— WorkspaceDirectory::discover::resolve_start_dir has cognitive complexity 16 (threshold 15). Drivers by points: if/else 4 (8 pts), match/switch 3 (8 pts) (nesting depth added 9). The drivers above price the dispatch low by construction — a dispatch is charged once however many cases it lists, while each branch inside an arm is charged in full — so most of this count is what the case bodies hold, and the arms are where it can be reduced. To reduce it, keep the dispatch but shrink the arms: move each non-trivial case body into its own named function (or onto the value being matched) so the dispatch reads one line per case, and group related cases into a sub-dispatch. Keep every case explicit, and make the behaviour for cases you do not list a deliberate choice rather than an accident.
RuntimeActivityStatsFactory::capture (cognitive 16) libs/core/runtime/stats.rs:173— RuntimeActivityStatsFactory::capture has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (12 pts), loops 2 (4 pts) (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
NpmPackageVersionInfo::dependencies_as_entries (cognitive 16) libs/npm/registry.rs:991— NpmPackageVersionInfo::dependencies_as_entries has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (10 pts), match/switch 2 (3 pts), loops 2, boolean chains 1 (nesting depth added 5). Of this number, 15 points are the body's own statements and 1 belongs to one function item inside it that branches. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
EnumVariantAttribute::from_variant (cognitive 16) libs/ops/conversion/to_v8/enum.rs:338— EnumVariantAttribute::from_variant has cognitive complexity 16 (threshold 15). Drivers by points: loops 3 (7 pts), match/switch 2 (5 pts), if/else 2 (4 pts) (nesting depth added 9). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
99_main_compiler.exec (cognitive 16) cli/tsc/99_main_compiler.js:98— 99_main_compiler.exec has cognitive complexity 16 (threshold 15). Drivers by points: if/else 4 (8 pts), loops 2 (4 pts), ternaries 3, boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
23_request.cloneInnerRequest (cognitive 16) ext/fetch/23_request.js:191— 23_request.cloneInnerRequest has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11, error handling 2 (4 pts), boolean chains 1 (nesting depth added 2). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
26_fetch.parseContentTypeForCdp (cognitive 16) ext/fetch/26_fetch.js:267— 26_fetch.parseContentTypeForCdp has cognitive complexity 16 (threshold 15). Drivers by points: if/else 5 (11 pts), loops 2 (3 pts), boolean chains 1, ternaries 1 (nesting depth added 7). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
30_fs.parseFileInfo (cognitive 16) ext/fs/30_fs.js:437— 30_fs.parseFileInfo has cognitive complexity 16 (threshold 15). Drivers by points: ternaries 15, boolean chains 1. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
InnerRequest.close (cognitive 16) REDACTED:189— InnerRequest.close has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (13 pts), boolean chains 3 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
00_serve.serve (cognitive 16) REDACTED:1159— 00_serve.serve has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10 (12 pts), match/switch 1 (2 pts), ternaries 1 (2 pts) (nesting depth added 4). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
Glob.#addSubpattern (cognitive 16) ext/node/polyfills/_fs/_fs_glob.ts:586— Glob.#addSubpattern has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9 (15 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
_http_outgoing.tryDirectEnd (cognitive 16) ext/node/polyfills/_http_outgoing.ts:1480— _http_outgoing.tryDirectEnd has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9, boolean chains 7. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
_tls_wrap.connect (cognitive 16) ext/node/polyfills/_tls_wrap.js:1650— _tls_wrap.connect has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11 (12 pts), boolean chains 4 (nesting depth added 1). To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
child_process.execFile::exithandler (cognitive 16) ext/node/polyfills/child_process.ts:626— child_process.execFile::exithandler has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10, boolean chains 6. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages. This shape REPEATS in the file: one other method here (child_process.execFile) has the same decision points, in the same order, at the same nesting depths — so this is one pattern written twice rather than two separate problems. Splitting this body alone leaves the other exactly as it is. Where these are variations on one operation, the change that clears both is the shared one: lift the common shape into a single routine the variants call, parameterised by whatever genuinely differs between them, and keep in each method only the part that is not shared.
fs.readFileFromFd (cognitive 16) ext/node/polyfills/fs.ts:719— fs.readFileFromFd has cognitive complexity 16 (threshold 15). Drivers by points: if/else 5 (9 pts), loops 2 (3 pts), ternaries 2 (3 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
fs.mkdir (cognitive 16) ext/node/polyfills/fs.ts:1978— fs.mkdir has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9 (12 pts), ternaries 1 (2 pts), boolean chains 1, error handling 1 (nesting depth added 4). Of this number, 12 points are the body's own statements and 4 belong to 2 function literals inside it that branch. To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
ServerHttp2Stream.pushStream (cognitive 16) ext/node/polyfills/http2.ts:3085— ServerHttp2Stream.pushStream has cognitive complexity 16 (threshold 15). Drivers by points: if/else 13, match/switch 1 (2 pts), ternaries 1 (nesting depth added 1). Of this number, 15 points are the body's own statements and 1 belongs to one function literal inside it that branches. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
http2.requestOnConnect (cognitive 16) ext/node/polyfills/http2.ts:1217— http2.requestOnConnect has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10 (12 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 3). Of this number, 12 points are the body's own statements and 4 belong to 2 function literals inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
http2.closeSession (cognitive 16) ext/node/polyfills/http2.ts:3819— http2.closeSession has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (8 pts), boolean chains 4, loops 2 (4 pts) (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
http2.connect (cognitive 16) ext/node/polyfills/http2.ts:5345— http2.connect has cognitive complexity 16 (threshold 15). Drivers by points: if/else 10 (12 pts), boolean chains 2, match/switch 1 (2 pts) (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
pbkdf2.pbkdf2 (cognitive 16) ext/node/polyfills/internal/crypto/pbkdf2.ts:106— pbkdf2.pbkdf2 has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 3, error handling 2 (nesting depth added 3). Most of this is not in the body itself: 1 of the 16 points is its own statement and the rest belongs to 2 function literals inside it that branch (lines 170, 152). The decisions are inside those literals, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literals' work into a named function or method at the enclosing scope and have each literal call it, then reduce whichever part then reads as the largest.
util.prepareRequestHeadersObject (cognitive 16) ext/node/polyfills/internal/http2/util.ts:728— util.prepareRequestHeadersObject has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9 (15 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
writable.writeOrBuffer (cognitive 16) ext/node/polyfills/internal/streams/writable.js:642— writable.writeOrBuffer has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (11 pts), boolean chains 4, ternaries 1 (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
writable.Writable.end (cognitive 16) ext/node/polyfills/internal/streams/writable.js:918— writable.Writable.end has cognitive complexity 16 (threshold 15). Drivers by points: if/else 14 (16 pts) (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
http_parser.HTTPParser.execute (cognitive 16) ext/node/polyfills/internal_binding/http_parser.ts:175— http_parser.HTTPParser.execute has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 4, ternaries 1 (nesting depth added 3). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
net.Socket.connect (cognitive 16) ext/node/polyfills/net.ts:1616— net.Socket.connect has cognitive complexity 16 (threshold 15). Drivers by points: if/else 12 (14 pts), boolean chains 2 (nesting depth added 2). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
process.emitWarning (cognitive 16) ext/node/polyfills/process.ts:384— process.emitWarning has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11 (14 pts), boolean chains 2 (nesting depth added 3). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
repl.isRecoverableError (cognitive 16) ext/node/polyfills/repl.ts:375— repl.isRecoverableError has cognitive complexity 16 (threshold 15). Drivers by points: if/else 8 (11 pts), boolean chains 3, loops 1 (2 pts) (nesting depth added 4). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
timers.setIntervalAsync (cognitive 16) ext/node/polyfills/timers.ts:278— timers.setIntervalAsync has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9 (11 pts), loops 2 (3 pts), boolean chains 1, error handling 1 (nesting depth added 3). Of this number, 15 points are the body's own statements and 1 belongs to 2 function items inside it that branch. To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition.
06_streams.readableStreamPipeTo (cognitive 16) ext/web/06_streams.js:3247— 06_streams.readableStreamPipeTo has cognitive complexity 16 (threshold 15). Drivers by points: if/else 34 (44 pts), boolean chains 10, error handling 1 (2 pts), loops 1, ternaries 1 (nesting depth added 11). To reduce it, split the body: most of this score is breadth rather than depth — checks laid out side by side rather than stacked — so group the statements between the checks into named steps and move each step into its own function. Some of it IS depth: where a check sits inside another whose only job is to reach it, merge the two into one condition, and where an else follows a branch that already returns, drop the trailing else and let the rest of the body continue at one level.
06_streams.readableStreamDefaultTee (cognitive 16) ext/web/06_streams.js:3727— 06_streams.readableStreamDefaultTee has cognitive complexity 16 (threshold 15). Drivers by points: if/else 11, boolean chains 3, error handling 1 (2 pts) (nesting depth added 1). Most of this is not in the body itself: 4 of the 16 points are its own statements and the rest belongs to 5 function items inside it that branch (chunkStepsMicrotask, a function literal at line 3887, pullAlgorithm, …). The named helpers are already separate functions; the literals' work cannot be called, reviewed or tested from outside this body. To reduce it, move the named helpers out of the body to the enclosing scope and lift each literal's work into a named function there, so each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
MessagePort.start (cognitive 16) ext/web/13_message_port.js:392— MessagePort.start has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (12 pts), error handling 1 (2 pts), boolean chains 1, loops 1 (nesting depth added 7). Most of this is not in the body itself: 1 of the 16 points is its own statement and the rest belongs to one function literal inside it that branches (line 395). The decisions are inside the literal, which nothing outside this body can call, review or test on its own, so splitting the enclosing body is not the move available here. To reduce it, lift the literal's work into a named function or method at the enclosing scope and have the literal call it, then reduce whichever part then reads as the largest.
flamegraph.update_text_for_elements (cognitive 16) REDACTED:129— flamegraph.update_text_for_elements has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (11 pts), loops 3 (4 pts), boolean chains 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
flamegraph.zoom (cognitive 16) REDACTED:234— flamegraph.zoom has cognitive complexity 16 (threshold 15). Drivers by points: if/else 6 (11 pts), boolean chains 2, ternaries 1 (2 pts), loops 1 (nesting depth added 6). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
executeLoadHookChain (cognitive 16) ext/node/polyfills/01_require.js:620— executeLoadHookChain has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (9 pts), boolean chains 3, ternaries 1 (2 pts), loops 1, other 1 (nesting depth added 3). Most of this is not in the body itself: 4 of the 16 points are its own statements and the rest belongs to 2 function items inside it that branch (nextLoad, nextLoad::wrappedNext). Those helpers are already separate functions, so extracting the branching again is not available. To reduce it, move them out of the body to the enclosing scope, where each is measured, reviewed and tested on its own, and reduce whichever one then reads as the largest.
processTicksAndRejections (cognitive 16) libs/core/01_core.js:358— processTicksAndRejections has cognitive complexity 16 (threshold 15). Drivers by points: if/else 2 (4 pts), loops 3 (4 pts), match/switch 1 (4 pts), error handling 1 (3 pts), boolean chains 1 (nesting depth added 8). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
(computed) (cognitive 16) ext/node/polyfills/internal/readline/interface.mjs:621— (computed) has cognitive complexity 16 (threshold 15). Drivers by points: if/else 7 (9 pts), loops 2 (4 pts), ternaries 1 (2 pts), boolean chains 1 (nesting depth added 5). To reduce it, split the body into named stages: move each independent step or branch into its own named function so the body reads as a short sequence of named calls rather than one long body.
WritableState (cognitive 16) ext/node/polyfills/internal/streams/writable.js:350— WritableState has cognitive complexity 16 (threshold 15). Drivers by points: if/else 9, boolean chains 5, ternaries 2. To reduce it, split the body: this score is breadth rather than depth — many checks laid out side by side rather than nested inside one another, so inverting conditions into early returns has nothing left to flatten. Group the statements between the checks into named steps and move each step into its own function, so the body reads as a short sequence of named stages.
D4 · Code Duplication· Near-duplicate member family (5 members, 15 shared lines) · ×1
Near-duplicate member family (5 members, 15 shared lines) ext/node/ops/tls_wrap.rs:530— ext/node/ops/tls_wrap.rs:530-567 | ext/node/ops/tls_wrap.rs:573-601 | ext/node/ops/tls_wrap.rs:609-635 | ext/node/ops/tls_wrap.rs:690-712 | ext/node/ops/tls_wrap.rs:840-872 — These 5 members are variants of one another: a block of 15 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 5 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 5 times.
D4 · Code Duplication· Near-duplicate member family (4 members, 27 shared lines) · ×1
Near-duplicate member family (4 members, 27 shared lines) cli/lsp/code_lens.rs:276— cli/lsp/code_lens.rs:276-317 | cli/lsp/code_lens.rs:383-446 | cli/lsp/testing/collectors.rs:390-441 | cli/lsp/testing/collectors.rs:530-579 — These 4 members are variants of one another: a block of 27 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
D4 · Code Duplication· Near-duplicate member family (4 members, 23 shared lines) · ×1
Near-duplicate member family (4 members, 23 shared lines) ext/signals/dict.rs:33— ext/signals/dict.rs:33-110 | ext/signals/dict.rs:33-180 | ext/signals/dict.rs:33-145 | ext/signals/dict.rs:33-75 — These 4 members are variants of one another: a block of 23 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
D4 · Code Duplication· Near-duplicate member family (4 members, 20 shared lines) · ×1
Near-duplicate member family (4 members, 20 shared lines) ext/node/ops/tls_wrap.rs:530— ext/node/ops/tls_wrap.rs:530-567 | ext/node/ops/tls_wrap.rs:573-601 | ext/node/ops/tls_wrap.rs:609-635 | ext/node/ops/tls_wrap.rs:840-872 — These 4 members are variants of one another: a block of 20 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 4 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 4 times.
D4 · Code Duplication· Near-duplicate member family (3 members, 60 shared lines) · ×1
Near-duplicate member family (3 members, 60 shared lines) ext/webgpu/compute_pass.rs:164— ext/webgpu/compute_pass.rs:164-260 | ext/webgpu/render_bundle.rs:158-255 | ext/webgpu/render_pass.rs:238-333 — These 3 members are variants of one another: a block of 60 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 3 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 3 times.
D4 · Code Duplication· Near-duplicate member family (3 members, 36 shared lines) · ×1
Near-duplicate member family (3 members, 36 shared lines) ext/crypto/subtle_export_key.rs:720— ext/crypto/subtle_export_key.rs:720-795 | ext/crypto/subtle_export_key.rs:800-876 | ext/crypto/subtle_export_key.rs:881-944 — These 3 members are variants of one another: a block of 36 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 3 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 3 times.
D4 · Code Duplication· Near-duplicate member family (3 members, 22 shared lines) · ×1
Near-duplicate member family (3 members, 22 shared lines) ext/node/ops/fs.rs:1441— ext/node/ops/fs.rs:1441-1505 | ext/node/ops/fs.rs:1638-1686 | ext/node/ops/fs.rs:1806-1865 — These 3 members are variants of one another: a block of 22 lines reported below appears in every one of them, and the pairwise near-duplicate rows they would otherwise produce are collapsed into this row. Read them as one construct written 3 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 3 times.
Near-duplicate member pair (93 shared lines) ext/node/ops/fs.rs:3118— ext/node/ops/fs.rs:3118-3313 | ext/node/ops/fs.rs:3322-3574 — These two members are variants of one another: 93 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (90 shared lines) ext/node_sqlite/sql_tag_store.rs:475— ext/node_sqlite/sql_tag_store.rs:475-772 | ext/node_sqlite/statement.rs:759-983 — These two members are variants of one another: 90 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (68 shared lines) libs/core/ops_builtin_v8.rs:309— libs/core/ops_builtin_v8.rs:309-427 | libs/core/ops_builtin_v8.rs:436-559 — These two members are variants of one another: 68 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (59 shared lines) cli/lsp/completions.rs:558— cli/lsp/completions.rs:558-710 | cli/lsp/completions.rs:718-869 — These two members are variants of one another: 59 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (45 shared lines) ext/node/ops/zlib/mod.rs:912— ext/node/ops/zlib/mod.rs:912-982 | ext/node/ops/zlib/mod.rs:998-1068 — These two members are variants of one another: 45 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
Near-duplicate member pair (38 shared lines) cli/tools/bundle/esbuild.rs:51— cli/tools/bundle/esbuild.rs:51-156 | cli/tsc/native.rs:85-204 — These two members are variants of one another: 38 of their lines are already reported as duplicated blocks below, spread through both bodies rather than gathered into one. Read them as a single construct written twice. The repair is at the members' grain — factor the shared pipeline into one implementation the two call with their differences as parameters or as an injected step, or, where the difference is systematic (sync against async, one transport against another), generate one from the other. Extracting the individual blocks below is not the same fix: it leaves the two bodies in place and the next edit still has to be made twice.
D4 · Code Duplication· Edited copy of a member (27 corresponding lines) · ×1
Edited copy of a member (27 corresponding lines) ext/node/ops/pipe_wrap.rs:138— ext/node/ops/pipe_wrap.rs:138-164 | ext/node/ops/tcp_wrap.rs:139-165 — These two members are one piece of code written twice and then edited apart: 27 consecutive lines correspond almost exactly, broken only by small local edits. Most of that correspondence is NOT reported as duplicated blocks below — the edits cut it into fragments and only the largest of them clear the block floor, so the rows below understate it. The repair is at the members' grain — factor the shared implementation into one the two call with their differences as parameters or as an injected step, or, where the difference is systematic (an extra return value, one transport against another), generate one from the other. Left alone, the next edit has to be made twice and the two will drift further apart.
D4 · Code Duplication· Edited copy of a member (26 corresponding lines) · ×1
Edited copy of a member (26 corresponding lines) ext/telemetry/lib.rs:3091— ext/telemetry/lib.rs:3091-3116 | ext/telemetry/lib.rs:3129-3158 — These two members are one piece of code written twice and then edited apart: 26 consecutive lines correspond almost exactly, broken only by small local edits. Most of that correspondence is NOT reported as duplicated blocks below — the edits cut it into fragments and only the largest of them clear the block floor, so the rows below understate it. The repair is at the members' grain — factor the shared implementation into one the two call with their differences as parameters or as an injected step, or, where the difference is systematic (an extra return value, one transport against another), generate one from the other. Left alone, the next edit has to be made twice and the two will drift further apart.
D4 · Code Duplication· Edited copy of a member (20 corresponding lines) · ×1
Edited copy of a member (20 corresponding lines) cli/lib/worker.rs:194— cli/lib/worker.rs:194-230 | ext/node/ops/process.rs:671-695 — These two members are one piece of code written twice and then edited apart: 20 consecutive lines correspond almost exactly, broken only by small local edits. Most of that correspondence is NOT reported as duplicated blocks below — the edits cut it into fragments and only the largest of them clear the block floor, so the rows below understate it. The repair is at the members' grain — factor the shared implementation into one the two call with their differences as parameters or as an injected step, or, where the difference is systematic (an extra return value, one transport against another), generate one from the other. Left alone, the next edit has to be made twice and the two will drift further apart.
D4 · Code Duplication· Members sharing a duplicated core (15 members, 50+ identical tokens) · ×1
Members sharing a duplicated core (15 members, 50+ identical tokens) cli/lsp/language_server.rs:1829— cli/lsp/language_server.rs:1829-1862 | cli/lsp/language_server.rs:2155-2448 | cli/lsp/language_server.rs:2650-2714 | cli/lsp/language_server.rs:2750-2788 | cli/lsp/language_server.rs:2795-2830 | cli/lsp/language_server.rs:2837-2872 | cli/lsp/language_server.rs:2879-2914 | cli/lsp/language_server.rs:3216-3252 | cli/lsp/language_server.rs:3259-3289 | cli/lsp/language_server.rs:3381-3416 | cli/lsp/language_server.rs:3423-3459 | cli/lsp/language_server.rs:3466-3501 | cli/lsp/language_server.rs:3590-3626 | cli/lsp/language_server.rs:4607-4641 | cli/lsp/language_server.rs:4781-4812 — These 15 members share a duplicated core: a run of at least 50 identical tokens appears in every one of them. That run is NOT broken out as duplicated-block rows below — it is what admitted this row, and the blocks below cover only the part of it that clears the block floor, so they understate the correspondence. Read the members as one construct written 15 times. The repair is at the members' grain — factor the shared implementation out once and have all of them call it with their differences as parameters or as an injected step, or, where the difference is systematic, generate them from one template. Extracting the individual blocks below is not the same fix: it leaves every body in place and the next edit still has to be made 15 times.
Duplicated block (120 lines × 2) ext/crypto/subtle_decrypt.rs:88— ext/crypto/subtle_decrypt.rs:88-207 | ext/crypto/subtle_encrypt.rs:88-207 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (88 lines × 2) ext/crypto/subtle_sign.rs:103— ext/crypto/subtle_sign.rs:103-190 | ext/crypto/subtle_verify.rs:97-184 — before extracting anything, compare `ext/crypto/subtle_sign.rs` and `ext/crypto/subtle_verify.rs` as WHOLE FILES: this scan already matched 6 separate duplicated blocks between them, totalling at least 160 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (80 lines × 3) ext/crypto/import_key.rs:361— ext/crypto/import_key.rs:361-440 | ext/crypto/import_key.rs:445-524 | ext/crypto/import_key.rs:529-608 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (69 lines × 2) ext/node/ops/fs.rs:2131— ext/node/ops/fs.rs:2131-2199 | ext/node/ops/fs.rs:2263-2331 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (59 lines × 2) ext/node/ops/zlib/mod.rs:1225— ext/node/ops/zlib/mod.rs:1225-1283 | ext/node/ops/zlib/mod.rs:1309-1367 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (51–57 lines × 2) cli/lsp/code_lens.rs:452— cli/lsp/code_lens.rs:452-502 | cli/lsp/testing/collectors.rs:445-501 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (53–57 lines × 2) ext/node/ops/tcp_wrap.rs:724— ext/node/ops/tcp_wrap.rs:724-780 | ext/node/ops/tcp_wrap.rs:792-844 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (42–51 lines × 2) ext/node/ops/vm.rs:508— ext/node/ops/vm.rs:508-558 | ext/node/ops/vm.rs:622-663 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (47–49 lines × 2) cli/tools/upgrade.rs:712— cli/tools/upgrade.rs:712-760 | cli/tools/upgrade.rs:884-930 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (46–48 lines × 2) ext/telemetry/lib.rs:2064— ext/telemetry/lib.rs:2064-2111 | ext/telemetry/lib.rs:2160-2205 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (45 lines × 2) libs/core/uv_compat/tty.rs:1868— libs/core/uv_compat/tty.rs:1868-1912 | libs/core/uv_compat/tty.rs:1940-1984 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (44 lines × 2) libs/npm_installer/hoisted.rs:821— libs/npm_installer/hoisted.rs:821-864 | libs/npm_installer/local.rs:1184-1227 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (40–43 lines × 2) libs/npm_installer/hoisted.rs:590— libs/npm_installer/hoisted.rs:590-629 | libs/npm_installer/local.rs:948-990 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (41 lines × 3) ext/ffi/call.rs:104— ext/ffi/call.rs:104-144 | ext/ffi/ir.rs:601-641 | ext/ffi/ir.rs:683-723 — there are 3 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 3 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (35–41 lines × 2) ext/node/ops/zlib/mod.rs:925— ext/node/ops/zlib/mod.rs:925-959 | ext/node/ops/zlib/mod.rs:1011-1051 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (39–41 lines × 2) ext/webgpu/compute_pass.rs:185— ext/webgpu/compute_pass.rs:185-225 | ext/webgpu/render_pass.rs:260-298 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_pass.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 146 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (24–40 lines × 3) ext/signals/dict.rs:35— ext/signals/dict.rs:35-74 | ext/signals/dict.rs:86-109 | ext/signals/dict.rs:157-180 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (34–39 lines × 2) cli/tools/upgrade.rs:780— cli/tools/upgrade.rs:780-818 | cli/tools/upgrade.rs:943-976 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (36–39 lines × 2) ext/crypto/digest.rs:195— ext/crypto/digest.rs:195-233 | ext/crypto/subtle_encrypt.rs:239-274 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 6 separate duplicated blocks between them, totalling at least 76 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (36–38 lines × 2) ext/node/ops/vm.rs:97— ext/node/ops/vm.rs:97-134 | ext/node/ops/vm.rs:1507-1542 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (32–36 lines × 2) ext/node/ops/tcp_wrap.rs:324— ext/node/ops/tcp_wrap.rs:324-359 | ext/node/ops/tcp_wrap.rs:564-595 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (25–36 lines × 2) ext/telemetry/lib.rs:2472— ext/telemetry/lib.rs:2472-2496 | ext/telemetry/lib.rs:2517-2552 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (35 lines × 2) runtime/web_worker.rs:504— runtime/web_worker.rs:504-538 | runtime/worker.rs:474-508 — before extracting anything, compare `runtime/web_worker.rs` and `runtime/worker.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 83 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (33–34 lines × 2) ext/node/ops/fs.rs:2539— ext/node/ops/fs.rs:2539-2572 | ext/node/ops/fs.rs:2632-2664 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–32 lines × 3) ext/signals/dict.rs:27— ext/signals/dict.rs:27-58 | ext/signals/dict.rs:150-164 | ext/signals/dict.rs:185-199 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (28–32 lines × 2) ext/telemetry/lib.rs:3131— ext/telemetry/lib.rs:3131-3158 | ext/telemetry/lib.rs:3175-3206 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (32 lines × 2) libs/resolver/bun_lockfile_import.rs:302— libs/resolver/bun_lockfile_import.rs:302-333 | libs/resolver/pnpm_lockfile_import.rs:492-523 — before extracting anything, compare `libs/resolver/bun_lockfile_import.rs` and `libs/resolver/pnpm_lockfile_import.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 69 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (30–31 lines × 3) ext/webgpu/compute_pass.rs:169— ext/webgpu/compute_pass.rs:169-198 | ext/webgpu/render_bundle.rs:166-196 | ext/webgpu/render_pass.rs:244-273 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_bundle.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 63 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (28–30 lines × 2) ext/napi/js_native_api.rs:1356— ext/napi/js_native_api.rs:1356-1385 | ext/napi/js_native_api.rs:1944-1971 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (29 lines × 5) ext/http/http_next.rs:4613— ext/http/http_next.rs:4613-4641 | ext/http/http_next.rs:4667-4695 | ext/http/http_next.rs:4848-4876 | ext/http/http_next.rs:4986-5014 | ext/http/http_next.rs:5036-5064 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (29 lines × 2) cli/rt/hmr.rs:105— cli/rt/hmr.rs:105-133 | cli/tools/run/hmr.rs:34-62 — before extracting anything, compare `cli/rt/hmr.rs` and `cli/tools/run/hmr.rs` as WHOLE FILES: this scan already matched 4 separate duplicated blocks between them, totalling at least 62 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. The two sit in different directories, so one cannot simply be deleted in favour of the other while both are reached separately: hoist the shared part into a location both already depend on and have each file call it, and retire whichever file turns out to have no caller of its own left. Extracting one helper per block leaves the fork in place.
Duplicated block (24–29 lines × 2) ext/node/ops/tls_wrap.rs:426— ext/node/ops/tls_wrap.rs:426-449 | ext/node/ops/tls_wrap.rs:480-508 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (27 lines × 4) cli/lsp/code_lens.rs:281— cli/lsp/code_lens.rs:281-307 | cli/lsp/code_lens.rs:388-414 | cli/lsp/testing/collectors.rs:395-421 | cli/lsp/testing/collectors.rs:535-561 — there are 4 copies across 2 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 4 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (26–27 lines × 2) libs/npm_installer/hoisted.rs:556— libs/npm_installer/hoisted.rs:556-581 | libs/npm_installer/local.rs:911-937 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (26 lines × 4) ext/napi/js_native_api.rs:1262— ext/napi/js_native_api.rs:1262-1287 | ext/napi/js_native_api.rs:1309-1334 | ext/napi/js_native_api.rs:1846-1871 | ext/napi/js_native_api.rs:1897-1922 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (23–26 lines × 3) libs/npm_installer/global.rs:220— libs/npm_installer/global.rs:220-242 | libs/npm_installer/hoisted.rs:1132-1154 | libs/npm_installer/local.rs:1430-1455 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (25–26 lines × 2) libs/cli_parser/src/convert.rs:2998— libs/cli_parser/src/convert.rs:2998-3023 | libs/node_shim/lib.rs:3105-3129 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (8–25 lines × 4) ext/signals/dict.rs:35— ext/signals/dict.rs:35-59 | ext/signals/dict.rs:87-94 | ext/signals/dict.rs:158-165 | ext/signals/dict.rs:193-200 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (16–25 lines × 2) ext/net/ops.rs:791— ext/net/ops.rs:791-815 | ext/node/ops/udp.rs:86-101 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (21–25 lines × 2) libs/core/modules/map.rs:1332— libs/core/modules/map.rs:1332-1352 | libs/core/modules/map.rs:1403-1427 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (22–24 lines × 2) ext/node/ops/fs.rs:2952— ext/node/ops/fs.rs:2952-2973 | ext/node/ops/fs.rs:3056-3079 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (21–24 lines × 2) libs/core/runtime/jsruntime.rs:2752— libs/core/runtime/jsruntime.rs:2752-2775 | libs/core/runtime/jsruntime.rs:2796-2816 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20–23 lines × 2) cli/rt/binary.rs:819— cli/rt/binary.rs:819-838 | cli/tools/pack/mod.rs:607-629 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
Duplicated block (22–23 lines × 2) cli/tools/bundle/mod.rs:669— cli/tools/bundle/mod.rs:669-690 | cli/tools/bundle/mod.rs:828-850 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20–22 lines × 2) libs/npm_installer/hoisted.rs:353— libs/npm_installer/hoisted.rs:353-372 | libs/npm_installer/local.rs:203-224 — before extracting anything, compare `libs/npm_installer/hoisted.rs` and `libs/npm_installer/local.rs` as WHOLE FILES: this scan already matched 14 separate duplicated blocks between them, totalling at least 273 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12–21 lines × 4) libs/core/modules/map/ext_script.rs:116— libs/core/modules/map/ext_script.rs:116-136 | libs/core/modules/map/ext_script.rs:253-264 | libs/core/modules/map/ext_script.rs:272-283 | libs/core/modules/map/ext_script.rs:344-355 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (21 lines × 3) ext/node/ops/stream_wrap.rs:1474— ext/node/ops/stream_wrap.rs:1474-1494 | ext/node/ops/stream_wrap.rs:1955-1975 | ext/node/ops/stream_wrap.rs:2041-2061 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (19–21 lines × 2) ext/http/http_next.rs:4645— ext/http/http_next.rs:4645-4665 | ext/http/http_next.rs:5017-5035 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (20–21 lines × 2) ext/telemetry/lib.rs:2970— ext/telemetry/lib.rs:2970-2989 | ext/telemetry/lib.rs:3023-3043 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (12–20 lines × 4) cli/tools/desktop.rs:199— cli/tools/desktop.rs:199-214 | cli/tools/desktop.rs:220-237 | cli/tools/desktop.rs:264-283 | cli/tools/desktop.rs:300-311 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (18–20 lines × 3) ext/webgpu/compute_pass.rs:203— ext/webgpu/compute_pass.rs:203-222 | ext/webgpu/render_bundle.rs:200-217 | ext/webgpu/render_pass.rs:278-295 — before extracting anything, compare `ext/webgpu/compute_pass.rs` and `ext/webgpu/render_bundle.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 63 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (17–20 lines × 2) ext/node/ops/tls_wrap.rs:2606— ext/node/ops/tls_wrap.rs:2606-2625 | ext/node/ops/tls_wrap.rs:2632-2648 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–19 lines × 4) ext/node/ops/tcp_wrap.rs:328— ext/node/ops/tcp_wrap.rs:328-345 | ext/node/ops/tcp_wrap.rs:568-582 | ext/node/ops/tcp_wrap.rs:728-746 | ext/node/ops/tcp_wrap.rs:796-812 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (16–19 lines × 2) cli/tools/bundle/mod.rs:739— cli/tools/bundle/mod.rs:739-757 | cli/tools/bundle/mod.rs:772-787 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (8–19 lines × 2) libs/core/inspector.rs:1094— libs/core/inspector.rs:1094-1112 | libs/core/inspector.rs:1137-1144 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (17–18 lines × 4) ext/crypto/subtle_import_key.rs:460— ext/crypto/subtle_import_key.rs:460-477 | ext/crypto/subtle_import_key.rs:1053-1069 | ext/crypto/subtle_import_key.rs:1447-1463 | ext/crypto/subtle_import_key.rs:1870-1887 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (17–18 lines × 2) ext/http/http_next.rs:2254— ext/http/http_next.rs:2254-2270 | ext/http/http_next.rs:2297-2314 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–18 lines × 2) ext/node/ops/fs.rs:1574— ext/node/ops/fs.rs:1574-1591 | ext/node/ops/fs.rs:1907-1919 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (15–18 lines × 2) ext/node/ops/stream_wrap.rs:1687— ext/node/ops/stream_wrap.rs:1687-1704 | ext/node/ops/stream_wrap.rs:1871-1885 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (7–17 lines × 5) ext/signals/dict.rs:34— ext/signals/dict.rs:34-50 | ext/signals/dict.rs:80-86 | ext/signals/dict.rs:115-121 | ext/signals/dict.rs:150-156 | ext/signals/dict.rs:185-191 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (15–17 lines × 3) cli/tools/desktop.rs:1645— cli/tools/desktop.rs:1645-1659 | cli/tools/desktop.rs:1778-1792 | cli/tools/desktop.rs:3222-3238 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (16 lines × 4) libs/resolver/bun_lockfile_import.rs:164— libs/resolver/bun_lockfile_import.rs:164-179 | libs/resolver/npm_lockfile_import.rs:248-263 | libs/resolver/pnpm_lockfile_import.rs:222-237 | libs/resolver/yarn_lockfile_import.rs:130-145 — before extracting anything, compare `libs/resolver/bun_lockfile_import.rs` and `libs/resolver/npm_lockfile_import.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (16 lines × 3) libs/core/uv_compat.rs:486— libs/core/uv_compat.rs:486-501 | libs/core/uv_compat.rs:510-525 | libs/core/uv_compat.rs:534-549 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11–16 lines × 2) ext/node_crypto/sign.rs:383— ext/node_crypto/sign.rs:383-398 | ext/node_crypto/sign.rs:570-580 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14–16 lines × 2) ext/node_sqlite/database.rs:2428— ext/node_sqlite/database.rs:2428-2443 | ext/node_sqlite/database.rs:2700-2713 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (13–15 lines × 6) ext/node/ops/tls_wrap.rs:417— ext/node/ops/tls_wrap.rs:417-429 | ext/node/ops/tls_wrap.rs:531-545 | ext/node/ops/tls_wrap.rs:574-588 | ext/node/ops/tls_wrap.rs:610-623 | ext/node/ops/tls_wrap.rs:691-705 | ext/node/ops/tls_wrap.rs:841-855 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (15 lines × 4) ext/node_sqlite/statement.rs:1097— ext/node_sqlite/statement.rs:1097-1111 | ext/node_sqlite/statement.rs:1115-1129 | ext/node_sqlite/statement.rs:1133-1147 | ext/node_sqlite/statement.rs:1151-1165 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12–15 lines × 2) ext/crypto/subtle_derive_bits.rs:444— ext/crypto/subtle_derive_bits.rs:444-455 | ext/crypto/subtle_derive_bits.rs:478-492 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (4–15 lines × 3) ext/node_sqlite/sql_tag_store.rs:642— ext/node_sqlite/sql_tag_store.rs:642-645 | ext/node_sqlite/sql_tag_store.rs:684-697 | ext/node_sqlite/statement.rs:894-908 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9–15 lines × 2) ext/tls/lib.rs:311— ext/tls/lib.rs:311-325 | ext/tls/lib.rs:350-358 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (14 lines × 4) cli/lsp/completions.rs:607— cli/lsp/completions.rs:607-620 | cli/lsp/completions.rs:657-670 | cli/lsp/completions.rs:768-781 | cli/lsp/completions.rs:816-829 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (14 lines × 3) cli/tools/desktop.rs:438— cli/tools/desktop.rs:438-451 | cli/tools/desktop.rs:661-674 | cli/tools/desktop.rs:738-751 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11–14 lines × 2) ext/http/http_next.rs:5512— ext/http/http_next.rs:5512-5522 | ext/http/http_next.rs:5581-5594 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9–14 lines × 3) runtime/subprocess_windows/src/lib.rs:432— runtime/subprocess_windows/src/lib.rs:432-445 | runtime/subprocess_windows/src/lib.rs:447-460 | runtime/subprocess_windows/src/lib.rs:461-469 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (13 lines × 5) ext/node_sqlite/statement.rs:1095— ext/node_sqlite/statement.rs:1095-1107 | ext/node_sqlite/statement.rs:1113-1125 | ext/node_sqlite/statement.rs:1131-1143 | ext/node_sqlite/statement.rs:1149-1161 | ext/node_sqlite/statement.rs:1167-1179 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12–13 lines × 4) libs/resolver/bun_lockfile_import.rs:117— libs/resolver/bun_lockfile_import.rs:117-129 | libs/resolver/npm_lockfile_import.rs:183-195 | libs/resolver/pnpm_lockfile_import.rs:129-140 | libs/resolver/yarn_lockfile_import.rs:99-111 — before extracting anything, compare `libs/resolver/bun_lockfile_import.rs` and `libs/resolver/npm_lockfile_import.rs` as WHOLE FILES: this scan already matched 3 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12–13 lines × 3) libs/http_h1/protocol.rs:95— libs/http_h1/protocol.rs:95-106 | libs/http_h1/protocol.rs:124-136 | libs/http_h1/protocol.rs:150-162 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (10–13 lines × 2) REDACTED:1656— REDACTED:1656-1665 | libs/core/uv_compat/tty.rs:2333-2345 — before extracting anything, compare `REDACTED` and `libs/core/uv_compat/tty.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 52 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (12 lines × 11) cli/lsp/language_server.rs:1835— cli/lsp/language_server.rs:1835-1846 | cli/lsp/language_server.rs:2756-2767 | cli/lsp/language_server.rs:2799-2810 | cli/lsp/language_server.rs:2843-2854 | cli/lsp/language_server.rs:2885-2896 | cli/lsp/language_server.rs:3222-3233 | cli/lsp/language_server.rs:3265-3276 | cli/lsp/language_server.rs:3387-3398 | cli/lsp/language_server.rs:3427-3438 | cli/lsp/language_server.rs:3472-3483 | cli/lsp/language_server.rs:3596-3607 — all 11 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (12 lines × 7) cli/lsp/language_server.rs:1833— cli/lsp/language_server.rs:1833-1844 | cli/lsp/language_server.rs:2205-2216 | cli/lsp/language_server.rs:2652-2663 | cli/lsp/language_server.rs:3263-3274 | cli/lsp/language_server.rs:3470-3481 | cli/lsp/language_server.rs:4609-4620 | cli/lsp/language_server.rs:4785-4796 — all 7 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11–12 lines × 5) ext/node_crypto/lib.rs:1361— ext/node_crypto/lib.rs:1361-1372 | ext/node_crypto/lib.rs:1384-1394 | ext/node_crypto/lib.rs:1406-1416 | ext/node_crypto/lib.rs:1428-1438 | ext/node_crypto/lib.rs:1450-1460 — all 5 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (11–12 lines × 3) libs/node_resolver/resolution.rs:1413— libs/node_resolver/resolution.rs:1413-1424 | libs/node_resolver/resolution.rs:1517-1527 | libs/node_resolver/resolution.rs:1531-1541 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9–12 lines × 2) ext/node_sqlite/database.rs:2842— ext/node_sqlite/database.rs:2842-2850 | ext/node_sqlite/statement.rs:191-202 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (10–11 lines × 3) ext/crypto/subtle_generate_key.rs:832— ext/crypto/subtle_generate_key.rs:832-842 | ext/crypto/subtle_import_key.rs:158-168 | ext/crypto/subtle_import_key.rs:209-218 — before extracting anything, compare `ext/crypto/subtle_generate_key.rs` and `ext/crypto/subtle_import_key.rs` as WHOLE FILES: this scan already matched 10 separate duplicated blocks between them, totalling at least 118 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (9–11 lines × 3) ext/node/ops/pipe_wrap.rs:446— ext/node/ops/pipe_wrap.rs:446-456 | ext/node/ops/tcp_wrap.rs:755-765 | ext/node/ops/tcp_wrap.rs:821-829 — before extracting anything, compare `ext/node/ops/pipe_wrap.rs` and `ext/node/ops/tcp_wrap.rs` as WHOLE FILES: this scan already matched 7 separate duplicated blocks between them, totalling at least 73 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8–11 lines × 2) ext/http/lib.rs:462— ext/http/lib.rs:462-469 | ext/http/lib.rs:484-494 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (10 lines × 8) ext/node/ops/stream_wrap.rs:1398— ext/node/ops/stream_wrap.rs:1398-1407 | ext/node/ops/stream_wrap.rs:1486-1495 | ext/node/ops/stream_wrap.rs:1685-1694 | ext/node/ops/stream_wrap.rs:1869-1878 | ext/node/ops/stream_wrap.rs:1967-1976 | ext/node/ops/stream_wrap.rs:2053-2062 | ext/node/ops/tls_wrap.rs:2128-2137 | ext/node/ops/tls_wrap.rs:2186-2195 — before extracting anything, compare `ext/node/ops/stream_wrap.rs` and `ext/node/ops/tls_wrap.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 51 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (10 lines × 6) ext/image/bitmap.rs:104— ext/image/bitmap.rs:104-113 | ext/image/bitmap.rs:117-126 | ext/image/bitmap.rs:130-139 | ext/image/bitmap.rs:142-151 | ext/image/bitmap.rs:154-163 | ext/image/bitmap.rs:168-177 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8–10 lines × 2) cli/lsp/jsr.rs:432— cli/lsp/jsr.rs:432-439 | cli/lsp/npm.rs:97-106 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (7–10 lines × 2) ext/net/ops.rs:282— ext/net/ops.rs:282-291 | ext/net/ops.rs:716-722 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (9 lines × 7) ext/crypto/subtle_decrypt.rs:242— ext/crypto/subtle_decrypt.rs:242-250 | ext/crypto/subtle_decrypt.rs:375-383 | ext/crypto/subtle_derive_bits.rs:278-286 | ext/crypto/subtle_encrypt.rs:297-305 | ext/crypto/subtle_encrypt.rs:431-439 | ext/crypto/subtle_sign.rs:241-249 | ext/crypto/subtle_sign.rs:289-297 — before extracting anything, compare `ext/crypto/subtle_decrypt.rs` and `ext/crypto/subtle_encrypt.rs` as WHOLE FILES: this scan already matched 21 separate duplicated blocks between them, totalling at least 355 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (8–9 lines × 7) ext/node/ops/tls_wrap.rs:423— ext/node/ops/tls_wrap.rs:423-430 | ext/node/ops/tls_wrap.rs:476-484 | ext/node/ops/tls_wrap.rs:538-546 | ext/node/ops/tls_wrap.rs:581-589 | ext/node/ops/tls_wrap.rs:617-624 | ext/node/ops/tls_wrap.rs:698-706 | ext/node/ops/tls_wrap.rs:848-856 — all 7 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6–9 lines × 3) REDACTED:1658— REDACTED:1658-1663 | libs/core/uv_compat/tty.rs:2251-2259 | libs/core/uv_compat/tty.rs:2336-2343 — before extracting anything, compare `REDACTED` and `libs/core/uv_compat/tty.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 52 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7–9 lines × 2) ext/fs/ops.rs:1193— ext/fs/ops.rs:1193-1201 | ext/fs/ops.rs:1288-1294 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (4–9 lines × 3) ext/net/ops.rs:265— ext/net/ops.rs:265-273 | ext/net/ops.rs:970-978 | ext/net/ops.rs:1029-1032 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6–8 lines × 9) ext/node_sqlite/database.rs:194— ext/node_sqlite/database.rs:194-199 | ext/node_sqlite/database.rs:207-212 | ext/node_sqlite/database.rs:222-229 | ext/node_sqlite/database.rs:237-243 | ext/node_sqlite/database.rs:254-261 | ext/node_sqlite/database.rs:299-304 | ext/node_sqlite/database.rs:313-319 | ext/node_sqlite/database.rs:327-333 | ext/node_sqlite/database.rs:340-346 — all 9 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (8 lines × 8) ext/crypto/digest.rs:340— ext/crypto/digest.rs:340-347 | ext/crypto/subtle_decrypt.rs:240-247 | ext/crypto/subtle_decrypt.rs:373-380 | ext/crypto/subtle_derive_bits.rs:276-283 | ext/crypto/subtle_encrypt.rs:295-302 | ext/crypto/subtle_encrypt.rs:429-436 | ext/crypto/subtle_sign.rs:239-246 | ext/crypto/subtle_sign.rs:287-294 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_decrypt.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (7–8 lines × 4) ext/web/css_value.rs:1171— ext/web/css_value.rs:1171-1177 | ext/web/css_value.rs:1189-1195 | ext/web/css_value.rs:1207-1213 | ext/web/css_value.rs:1356-1363 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6–8 lines × 3) cli/tools/lint/ast_buffer/ts_estree.rs:759— cli/tools/lint/ast_buffer/ts_estree.rs:759-766 | cli/tools/lint/ast_buffer/ts_estree.rs:792-799 | cli/tools/lint/ast_buffer/ts_estree.rs:1301-1306 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (4–8 lines × 3) ext/napi/node_api.rs:461— ext/napi/node_api.rs:461-468 | ext/napi/node_api.rs:509-512 | ext/napi/node_api.rs:530-537 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (7 lines × 5) ext/crypto/digest.rs:367— ext/crypto/digest.rs:367-373 | ext/crypto/digest.rs:395-401 | ext/crypto/subtle_decrypt.rs:261-267 | ext/crypto/subtle_encrypt.rs:316-322 | ext/crypto/subtle_sign.rs:331-337 — before extracting anything, compare `ext/crypto/digest.rs` and `ext/crypto/subtle_decrypt.rs` as WHOLE FILES: this scan already matched 5 separate duplicated blocks between them, totalling at least 37 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (6–7 lines × 4) cli/lsp/diagnostics.rs:818— cli/lsp/diagnostics.rs:818-823 | cli/lsp/diagnostics.rs:886-892 | cli/lsp/diagnostics.rs:912-918 | cli/lsp/diagnostics.rs:938-943 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (3–7 lines × 3) ext/web/geometry.rs:335— ext/web/geometry.rs:335-337 | ext/web/geometry.rs:371-377 | ext/web/geometry.rs:385-391 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (6 lines × 10) REDACTED:700— REDACTED:700-705 | REDACTED:856-861 | REDACTED:912-917 | REDACTED:1022-1027 | REDACTED:1048-1053 | REDACTED:1311-1316 | REDACTED:1349-1354 | libs/core/uv_compat/stream.rs:503-508 | libs/core/uv_compat/stream.rs:608-613 | libs/core/uv_compat/tcp.rs:728-733 — there are 10 copies across 3 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 10 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (6 lines × 8) ext/node/ops/http2/session.rs:950— ext/node/ops/http2/session.rs:950-955 | ext/node/ops/http2/session.rs:1017-1022 | ext/node/ops/http2/session.rs:1058-1063 | ext/node/ops/http2/session.rs:1084-1089 | ext/node/ops/http2/session.rs:1139-1144 | ext/node/ops/http2/session.rs:1173-1178 | ext/node/ops/http2/session.rs:1224-1229 | ext/node/ops/http2/session.rs:1275-1280 — all 8 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5–6 lines × 3) ext/node_sqlite/sql_tag_store.rs:597— ext/node_sqlite/sql_tag_store.rs:597-602 | ext/node_sqlite/statement.rs:828-833 | ext/node_sqlite/statement.rs:859-863 — before extracting anything, compare `ext/node_sqlite/sql_tag_store.rs` and `ext/node_sqlite/statement.rs` as WHOLE FILES: this scan already matched 9 separate duplicated blocks between them, totalling at least 119 lines, which is the signature of one file having been copied from the other rather than of a helper waiting to be extracted. If that is what happened, the fix is to keep one copy and have the other call it (or delete it), which resolves this row and its siblings together — extracting one helper per block leaves the fork in place.
Duplicated block (4–6 lines × 3) ext/web/geometry.rs:2145— ext/web/geometry.rs:2145-2150 | ext/web/geometry.rs:2185-2190 | ext/web/geometry.rs:2252-2255 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5–6 lines × 2) libs/ops/op2/dispatch_fast.rs:502— libs/ops/op2/dispatch_fast.rs:502-506 | libs/ops/op2/dispatch_slow.rs:257-262 — the copies sit in sibling files of one directory, so a shared home is within easy reach: extract the block into a single shared function the call sites can all reach — a file they already depend on, or a new one alongside them — and call it from both call sites, so a change lands once.
Duplicated block (2–5 lines × 7) ext/web/geometry.rs:339— ext/web/geometry.rs:339-343 | ext/web/geometry.rs:351-353 | ext/web/geometry.rs:357-358 | ext/web/geometry.rs:365-369 | ext/web/geometry.rs:379-383 | ext/web/geometry.rs:393-397 | ext/web/geometry.rs:405-409 — all 7 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (3–5 lines × 3) ext/web/geometry.rs:304— ext/web/geometry.rs:304-308 | ext/web/geometry.rs:316-320 | ext/web/geometry.rs:411-413 — all 3 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 4) libs/http_h1/parse.rs:456— libs/http_h1/parse.rs:456-460 | libs/http_h1/protocol.rs:405-409 | libs/http_h1/write.rs:389-393 | libs/http_h1/write.rs:395-399 — there are 4 copies across 3 file(s) — more copies than files, so at least one file holds the block twice. Extract it once into a single shared function every call site can reach and call it from all 4 sites; resolving a subset leaves the remainder to drift apart.
Duplicated block (14 lines × 10) cli/lsp/language_server.rs:2772— cli/lsp/language_server.rs:2772-2788 | cli/lsp/language_server.rs:2817-2830 | cli/lsp/language_server.rs:2859-2872 | cli/lsp/language_server.rs:2901-2914 | cli/lsp/language_server.rs:3239-3252 | cli/lsp/language_server.rs:3319-3332 | cli/lsp/language_server.rs:3361-3374 | cli/lsp/language_server.rs:3403-3416 | cli/lsp/language_server.rs:3446-3459 | cli/lsp/language_server.rs:3488-3501 — all 10 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 4) ext/node_sqlite/database.rs:503— ext/node_sqlite/database.rs:503-511 | ext/node_sqlite/database.rs:516-525 | ext/node_sqlite/database.rs:530-538 | ext/node_sqlite/database.rs:543-551 — all 4 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (9 lines × 6) ext/fs/ops.rs:289— ext/fs/ops.rs:289-297 | ext/fs/ops.rs:353-361 | ext/fs/ops.rs:377-385 | ext/fs/ops.rs:421-429 | ext/fs/ops.rs:1068-1076 | ext/fs/ops.rs:1120-1128 — all 6 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (5 lines × 7) ext/crypto/subtle_import_key.rs:758— ext/crypto/subtle_import_key.rs:758-762 | ext/crypto/subtle_import_key.rs:768-772 | ext/crypto/subtle_import_key.rs:884-888 | ext/crypto/subtle_import_key.rs:894-898 | ext/crypto/subtle_import_key.rs:997-1001 | ext/crypto/subtle_import_key.rs:1007-1011 | ext/crypto/subtle_import_key.rs:1486-1490 — all 7 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited.
Duplicated block (34 lines × 2) libs/ops/op2/test_cases/compiler_pass/sync.rs:4— libs/ops/op2/test_cases/compiler_pass/sync.rs:4-54 | libs/ops/op2/test_cases/sync/smi.rs:4-37 — the copies span different directories, so extracting a shared function means choosing where it lives: put it somewhere both call sites can already reach — a location they all depend on today, or a new shared one if there is none — and call it from each site; until then, every change has to be made twice.
End-of-life runtime: Rust 1.95 rust-toolchain.toml:1— rust-toolchain.toml declares Rust 1.95 as this project's toolchain file, and Rust 1.95, superseded by 1.96 on 2026-05-28 (the Rust project patches only the current stable). An unsupported runtime receives no security patches, so every vulnerability disclosed in it since 2026-05-28 is present and unfixable without moving off it. This is a migration rather than an upgrade: there is no newer release of a runtime that has ended.
Duplication concentrated across 14 sibling directories (48 clone groups) ext/fetch/26_fetch.js:194— 48 duplicated blocks under ext/ have copies in at least two of the sibling directories cache, fetch, fs, http, image, io (+8 more sibling(s) not listed) — 17 of them are reported below, and 31 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 48 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 48 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 48 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on.
Duplication concentrated across 3 sibling directories (13 clone groups) ext/node/polyfills/worker_threads.ts:636— 13 duplicated blocks under the repository root have copies in at least two of the sibling directories ext, libs, runtime — 5 of them are reported below, and 8 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 13 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 13 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 13 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on.
Duplication concentrated across 8 sibling directories (10 clone groups) ext/node/polyfills/internal/console/constructor.mjs:764— 10 duplicated blocks under ext/node/polyfills/internal/ have copies in at least two of the sibling directories console, crypto, dns, fs, http2, readline (+2 more sibling(s) not listed) — 1 of them are reported below, and 9 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 10 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 10 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 10 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on.
Duplication concentrated across 8 sibling directories (9 clone groups) ext/node/polyfills/internal/util/types.ts:136— 9 duplicated blocks under ext/node/polyfills/ have copies in at least two of the sibling directories _fs, _process, fs, inspector, internal, internal_binding (+2 more sibling(s) not listed) — 5 of them are reported below, and 4 are counted here but not reported individually: those copies match on shape but no longer clear R10's bar for an individually reported row — either they kept neither their own names nor their values, or what was copied is too small to stand on its own (it reports near-exact duplication only, and only of substantial extent). What this row states is the concentration, which the detector measured over all 9 and which does not depend on how exactly each block's copies still match. That concentration is one structural fact, not 9 local ones: the siblings replicate behaviour none of them owns, which is the shape of a missing shared module — a common library every sibling imports — rather than 9 separate extractions. Check first whether the siblings are deliberately standalone deliverables (scaffold templates, demo apps that must stay copy-pasteable); where they are, the duplication is the design and the per-block rows are the ones to act on.
R10 · Code Duplication· Duplicated block with local edits (216 matched lines × 2 locations) · ×1
Duplicated block with local edits (216 matched lines × 2 locations) ext/node/polyfills/path/_posix.ts:183— ext/node/polyfills/path/_posix.ts:183 · ext/node/polyfills/path/_win32.ts:655 — the two spans are one implementation copied and then locally edited — 1307 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (191 matched lines × 2 locations) · ×1
Duplicated block with local edits (191 matched lines × 2 locations) ext/node/polyfills/internal/crypto/cipher.ts:182— ext/node/polyfills/internal/crypto/cipher.ts:182 · ext/node/polyfills/internal/crypto/cipher.ts:493 — the two spans are one implementation copied and then locally edited — 1065 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (135 matched lines × 2 locations) · ×1
Duplicated block with local edits (135 matched lines × 2 locations) tools/startup_order/generate_linux_function_orderfile.ts:402— tools/startup_order/generate_linux_function_orderfile.ts:402 · tools/startup_order/generate_macos_function_orderfile.ts:282 — the two spans are one implementation copied and then locally edited — 808 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
Duplicated block (107 lines × 2 locations) ext/node/polyfills/internal/errors.ts:3361— ext/node/polyfills/internal/errors.ts:3361 · ext/node/polyfills/internal/errors.ts:3684 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
R10 · Code Duplication· Duplicated block with local edits (106 matched lines × 2 locations) · ×1
Duplicated block with local edits (106 matched lines × 2 locations) ext/web/12_location.js:22— ext/web/12_location.js:22 · ext/web/12_location.js:228 — the two spans are one implementation copied and then locally edited — 393 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (93 matched lines × 2 locations) · ×1
Duplicated block with local edits (93 matched lines × 2 locations) ext/node/polyfills/worker_threads.ts:636— ext/node/polyfills/worker_threads.ts:636 · runtime/js/11_workers.js:222 — the two spans are one implementation copied and then locally edited — 491 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (92 matched lines × 2 locations) · ×1
Duplicated block with local edits (92 matched lines × 2 locations) ext/node/polyfills/internal/streams/readable.js:257— ext/node/polyfills/internal/streams/readable.js:257 · ext/node/polyfills/internal/streams/writable.js:251 — the two spans are one implementation copied and then locally edited — 551 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (86 matched lines × 2 locations) · ×1
Duplicated block with local edits (86 matched lines × 2 locations) ext/node/polyfills/internal/crypto/sig.ts:350— ext/node/polyfills/internal/crypto/sig.ts:350 · ext/node/polyfills/internal/crypto/sig.ts:470 — the two spans are one implementation copied and then locally edited — 464 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
Duplicated block (86 lines × 2 locations) tools/startup_order/generate_linux_function_orderfile.ts:154— tools/startup_order/generate_linux_function_orderfile.ts:154 · tools/startup_order/generate_macos_function_orderfile.ts:126 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it.
Duplicated block (77 lines × 2 locations) ext/node/polyfills/internal/errors.ts:3475— ext/node/polyfills/internal/errors.ts:3475 · ext/node/polyfills/internal/errors.ts:3796 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
R10 · Code Duplication· Duplicated block with local edits (76 matched lines × 2 locations) · ×1
Duplicated block with local edits (76 matched lines × 2 locations) ext/node/polyfills/internal/webstreams/adapters.js:129— ext/node/polyfills/internal/webstreams/adapters.js:129 · ext/node/polyfills/internal/webstreams/adapters.js:272 — the two spans are one implementation copied and then locally edited — 346 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (75 matched lines × 2 locations) · ×1
Duplicated block with local edits (75 matched lines × 2 locations) ext/node/polyfills/internal/streams/readable.js:136— ext/node/polyfills/internal/streams/readable.js:136 · ext/node/polyfills/internal/streams/writable.js:146 — the two spans are one implementation copied and then locally edited — 453 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (72 matched lines × 2 locations) · ×1
Duplicated block with local edits (72 matched lines × 2 locations) ext/fetch/26_fetch.js:194— ext/fetch/26_fetch.js:194 · REDACTED:146 — the two spans are one implementation copied and then locally edited — 435 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (70 matched lines × 2 locations) · ×1
Duplicated block with local edits (70 matched lines × 2 locations) ext/node/polyfills/internal/streams/compose.js:94— ext/node/polyfills/internal/streams/compose.js:94 · ext/node/polyfills/internal/streams/duplexify.js:290 — the two spans are one implementation copied and then locally edited — 318 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
Duplicated block (67 lines × 2 locations) ext/node/polyfills/crypto.ts:495— ext/node/polyfills/crypto.ts:495 · ext/node/polyfills/crypto_esm.ts:6 — the 2 copies are spread across 2 files, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
R10 · Code Duplication· Duplicated block with local edits (67 matched lines × 2 locations) · ×1
Duplicated block with local edits (67 matched lines × 2 locations) ext/node/polyfills/timers.ts:53— ext/node/polyfills/timers.ts:53 · ext/node/polyfills/timers.ts:160 — the two spans are one implementation copied and then locally edited — 358 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
R10 · Code Duplication· Duplicated block with local edits (55 matched lines × 2 locations) · ×1
Duplicated block with local edits (55 matched lines × 2 locations) ext/fetch/20_headers.js:549— ext/fetch/20_headers.js:549 · ext/fetch/21_formdata.js:188 — the two spans are one implementation copied and then locally edited — 323 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
Duplicated block (53 lines × 2 locations) ext/node/polyfills/internal/buffer.mjs:1060— ext/node/polyfills/internal/buffer.mjs:1060 · ext/node/polyfills/internal/buffer.mjs:1125 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
R10 · Code Duplication· Duplicated block with local edits (52 matched lines × 2 locations) · ×1
Duplicated block with local edits (52 matched lines × 2 locations) runtime/js/98_global_scope_window.js:9— runtime/js/98_global_scope_window.js:9 · runtime/js/98_global_scope_worker.js:9 — the two spans are one implementation copied and then locally edited — 221 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one.
Duplicated block (51 lines × 2 locations) REDACTED:948— REDACTED:948 · REDACTED:1005 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (50 lines × 2 locations) ext/node/polyfills/_http_agent.js:78— ext/node/polyfills/_http_agent.js:78 · ext/node/polyfills/net.ts:337 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (47 lines × 2 locations) ext/node/polyfills/dns.ts:1061— ext/node/polyfills/dns.ts:1061 · ext/node/polyfills/dns.ts:1114 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
Duplicated block (46 lines × 2 locations) runtime/js/98_global_scope_window.js:165— runtime/js/98_global_scope_window.js:165 · runtime/js/98_global_scope_worker.js:147 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (45 lines × 2 locations) ext/node/polyfills/internal/constants.ts:58— ext/node/polyfills/internal/constants.ts:58 · ext/node/polyfills/internal/constants.ts:107 — all 2 copies are in the same file, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
Duplicated block (43 lines × 2 locations) ext/web/06_streams.js:5904— ext/web/06_streams.js:5904 · ext/web/06_streams.js:5961 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (42 lines × 2 locations) ext/web/06_streams.js:1654— ext/web/06_streams.js:1654 · ext/web/06_streams.js:2144 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited.
Duplicated block (40 lines × 2 locations) ext/node/polyfills/_fs/_fs_glob.ts:701— ext/node/polyfills/_fs/_fs_glob.ts:701 · ext/node/polyfills/_fs/_fs_glob.ts:973 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported.
Duplicated block (39 lines × 2 locations) ext/node/polyfills/internal/util/types.ts:136— ext/node/polyfills/internal/util/types.ts:136 · ext/node/polyfills/util/types.ts:6 — the 2 copies are spread across 2 files, and what repeats is a LIST OF ENTRIES rather than behaviour — the same entries written out more than once. Extract them into one shared, exported constant and spread that constant into each site, rather than into a function the sites call: a list like this often lives in declarative metadata (a decorator's options object, a static configuration table) that a build step must be able to read statically, where a function call is not allowed. Adding an entry to one copy and not the other is the failure this prevents.
Complex function resolveObject (cyclomatic 117, cognitive 168) ext/node/polyfills/url.ts:262— resolveObject has cyclomatic complexity 117 and cognitive complexity 168; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function emitKeys (cyclomatic 112, cognitive 77) ext/node/polyfills/internal/readline/utils.mjs:121— emitKeys has cyclomatic complexity 112 and cognitive complexity 77; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function #iterateSubpatterns (cyclomatic 106, cognitive 283) ext/node/polyfills/_fs/_fs_glob.ts:880— #iterateSubpatterns has cyclomatic complexity 106 and cognitive complexity 283; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function urlParse (cyclomatic 106, cognitive 141) ext/node/polyfills/url.ts:666— urlParse has cyclomatic complexity 106 and cognitive complexity 141; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function objectComparisonStart (cyclomatic 91, cognitive 109) ext/node/polyfills/internal/util/comparisons.ts:302— objectComparisonStart has cyclomatic complexity 91 and cognitive complexity 109; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function matchKnownFields (cyclomatic 90, cognitive 113) ext/node/polyfills/_http_incoming.js:259— matchKnownFields has cyclomatic complexity 90 and cognitive complexity 113; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function ClientRequest (cyclomatic 86, cognitive 125) REDACTED:505— ClientRequest has cyclomatic complexity 86 and cognitive complexity 125; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function #addSubpatterns (cyclomatic 82, cognitive 151) ext/node/polyfills/_fs/_fs_glob.ts:618— #addSubpatterns has cyclomatic complexity 82 and cognitive complexity 151; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function (computed) (cyclomatic 71, cognitive 61) ext/node/polyfills/internal/readline/interface.mjs:1093— (computed) has cyclomatic complexity 71 and cognitive complexity 61; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive sits below cyclomatic here, so much of the count is breadth — arms side by side rather than stacked — and splitting per arm would leave a function per arm; group the work between the checks into named steps instead. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function constructor (cyclomatic 61, cognitive 111) ext/node/polyfills/worker_threads.ts:291— constructor has cyclomatic complexity 61 and cognitive complexity 111; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function createJob (cyclomatic 60, cognitive 102) ext/node/polyfills/internal/crypto/keygen.ts:390— createJob has cyclomatic complexity 60 and cognitive complexity 102; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function _load (cyclomatic 59, cognitive 104) ext/node/polyfills/01_require.js:1412— _load has cyclomatic complexity 59 and cognitive complexity 104; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function mainFetch (cyclomatic 59, cognitive 90) ext/fetch/26_fetch.js:386— mainFetch has cyclomatic complexity 59 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function #spawnInternal (cyclomatic 59, cognitive 90) ext/node/polyfills/internal/child_process.ts:369— #spawnInternal has cyclomatic complexity 59 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function _resolveFilename (cyclomatic 52, cognitive 87) ext/node/polyfills/01_require.js:1657— _resolveFilename has cyclomatic complexity 52 and cognitive complexity 87; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function normalize (cyclomatic 48, cognitive 92) ext/node/polyfills/path/_win32.ts:275— normalize has cyclomatic complexity 48 and cognitive complexity 92; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function pipelineImpl (cyclomatic 48, cognitive 90) ext/node/polyfills/internal/streams/pipeline.js:210— pipelineImpl has cyclomatic complexity 48 and cognitive complexity 90; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
Complex function resolve (cyclomatic 47, cognitive 108) ext/node/polyfills/path/_win32.ts:91— resolve has cyclomatic complexity 47 and cognitive complexity 108; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes.
ext/web/06_streams.js: 8052 lines of code ext/web/06_streams.js:1— ext/web/06_streams.js has 8052 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/http2.ts · ×1
ext/node/polyfills/http2.ts: 5055 lines of code ext/node/polyfills/http2.ts:1— ext/node/polyfills/http2.ts has 5055 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/errors.ts · ×1
ext/node/polyfills/internal/errors.ts: 3783 lines of code ext/node/polyfills/internal/errors.ts:1— ext/node/polyfills/internal/errors.ts has 3783 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/fs.ts: 3740 lines of code ext/node/polyfills/fs.ts:1— ext/node/polyfills/fs.ts has 3740 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/testing.ts · ×1
ext/node/polyfills/testing.ts: 3321 lines of code ext/node/polyfills/testing.ts:1— ext/node/polyfills/testing.ts has 3321 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/01_require.js · ×1
ext/node/polyfills/01_require.js: 3230 lines of code ext/node/polyfills/01_require.js:1— ext/node/polyfills/01_require.js has 3230 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/buffer.mjs · ×1
ext/node/polyfills/internal/buffer.mjs: 3114 lines of code ext/node/polyfills/internal/buffer.mjs:1— ext/node/polyfills/internal/buffer.mjs has 3114 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/net.ts: 2947 lines of code ext/node/polyfills/net.ts:1— ext/node/polyfills/net.ts has 2947 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/child_process.ts · ×1
ext/node/polyfills/internal/child_process.ts: 2799 lines of code ext/node/polyfills/internal/child_process.ts:1— ext/node/polyfills/internal/child_process.ts has 2799 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/worker_threads.ts · ×1
ext/node/polyfills/worker_threads.ts: 2201 lines of code ext/node/polyfills/worker_threads.ts:1— ext/node/polyfills/worker_threads.ts has 2201 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/repl.ts: 1930 lines of code ext/node/polyfills/repl.ts:1— ext/node/polyfills/repl.ts has 1930 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/process.ts · ×1
ext/node/polyfills/process.ts: 1896 lines of code ext/node/polyfills/process.ts:1— ext/node/polyfills/process.ts has 1896 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
REDACTED: 1779 lines of code REDACTED:1— REDACTED has 1779 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/_tls_wrap.js · ×1
ext/node/polyfills/_tls_wrap.js: 1760 lines of code ext/node/polyfills/_tls_wrap.js:1— ext/node/polyfills/_tls_wrap.js has 1760 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/streams/readable.js · ×1
ext/node/polyfills/internal/streams/readable.js: 1666 lines of code ext/node/polyfills/internal/streams/readable.js:1— ext/node/polyfills/internal/streams/readable.js has 1666 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
REDACTED: 1627 lines of code REDACTED:1— REDACTED has 1627 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/_http_outgoing.ts · ×1
ext/node/polyfills/_http_outgoing.ts: 1610 lines of code ext/node/polyfills/_http_outgoing.ts:1— ext/node/polyfills/_http_outgoing.ts has 1610 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/url.ts: 1597 lines of code ext/node/polyfills/url.ts:1— ext/node/polyfills/url.ts has 1597 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/crypto/diffiehellman.ts · ×1
ext/node/polyfills/internal/crypto/diffiehellman.ts: 1592 lines of code ext/node/polyfills/internal/crypto/diffiehellman.ts:1— ext/node/polyfills/internal/crypto/diffiehellman.ts has 1592 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/webidl/00_webidl.js: 1553 lines of code ext/webidl/00_webidl.js:1— ext/webidl/00_webidl.js has 1553 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/web/02_event.js: 1515 lines of code ext/web/02_event.js:1— ext/web/02_event.js has 1515 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
REDACTED: 1510 lines of code REDACTED:1— REDACTED has 1510 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/dgram.ts · ×1
ext/node/polyfills/dgram.ts: 1460 lines of code ext/node/polyfills/dgram.ts:1— ext/node/polyfills/dgram.ts has 1460 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
REDACTED: 1409 lines of code REDACTED:1— REDACTED has 1409 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
runtime/js/99_main.js: 1304 lines of code runtime/js/99_main.js:1— runtime/js/99_main.js has 1304 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/readline/interface.mjs · ×1
ext/node/polyfills/internal/readline/interface.mjs: 1282 lines of code ext/node/polyfills/internal/readline/interface.mjs:1— ext/node/polyfills/internal/readline/interface.mjs has 1282 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/util/comparisons.ts · ×1
ext/node/polyfills/internal/util/comparisons.ts: 1282 lines of code ext/node/polyfills/internal/util/comparisons.ts:1— ext/node/polyfills/internal/util/comparisons.ts has 1282 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/zlib.js: 1241 lines of code ext/node/polyfills/zlib.js:1— ext/node/polyfills/zlib.js has 1241 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
libs/core/01_core.js: 1230 lines of code libs/core/01_core.js:1— libs/core/01_core.js has 1230 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/_fs/_fs_glob.ts · ×1
ext/node/polyfills/_fs/_fs_glob.ts: 1202 lines of code ext/node/polyfills/_fs/_fs_glob.ts:1— ext/node/polyfills/_fs/_fs_glob.ts has 1202 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/_events.mjs · ×1
ext/node/polyfills/_events.mjs: 1198 lines of code ext/node/polyfills/_events.mjs:1— ext/node/polyfills/_events.mjs has 1198 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/web/00_url.js: 1169 lines of code ext/web/00_url.js:1— ext/web/00_url.js has 1169 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/fs/utils.mjs · ×1
ext/node/polyfills/internal/fs/utils.mjs: 1133 lines of code ext/node/polyfills/internal/fs/utils.mjs:1— ext/node/polyfills/internal/fs/utils.mjs has 1133 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/path/_win32.ts · ×1
ext/node/polyfills/path/_win32.ts: 1132 lines of code ext/node/polyfills/path/_win32.ts:1— ext/node/polyfills/path/_win32.ts has 1132 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
cli/js/jupyter_kernel.js: 1120 lines of code cli/js/jupyter_kernel.js:1— cli/js/jupyter_kernel.js has 1120 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R3 · Large Files· ext/node/polyfills/internal/streams/writable.js · ×1
ext/node/polyfills/internal/streams/writable.js: 1118 lines of code ext/node/polyfills/internal/streams/writable.js:1— ext/node/polyfills/internal/streams/writable.js has 1118 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/web/13_message_port.js: 1108 lines of code ext/web/13_message_port.js:1— ext/web/13_message_port.js has 1108 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/node/polyfills/dns.ts: 1080 lines of code ext/node/polyfills/dns.ts:1— ext/node/polyfills/dns.ts has 1080 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
REDACTED: 1072 lines of code REDACTED:1— REDACTED has 1072 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
ext/fetch/26_fetch.js: 1059 lines of code ext/fetch/26_fetch.js:1— ext/fetch/26_fetch.js has 1059 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module.
R6 · Tooling· The declared test suite includes a file that cannot be loaded · ×1
The declared test suite includes a file that cannot be loaded tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js:6— This repository declares test tooling, and the ✓ above records that declaration — but tests/registry/npm/@denotest/install-launch-cjs-temp-dir/1.0.0/install.js and 23 other test file(s) in this workspace cannot be loaded at all: it imports a module that names no file in this repository, so the runner throws while collecting it and none of its cases execute. The wiring is present and the suite it points at does not run as written, which is why the tooling tick must not be read as a statement that the tests pass. Fix the unloadable file(s) — each one is reported with its failing import under Test Coverage — then the declared script exercises what it claims to.
Dead file (~528 LoC) ext/node/polyfills/internal/streams/pipeline.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~479 LoC) ext/node/polyfills/internal/streams/operators.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~268 LoC) ext/node/polyfills/internal/streams/compose.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~226 LoC) ext/node/polyfills/_brotli.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~219 LoC) libs/core_testing/unit/serialize_deserialize_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~209 LoC) tools/ecosystem_compat_slack.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~205 LoC) libs/core_testing/integration/ts_types/which.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), but 1 in-repo import(s) from 1 other file(s) do name it (libs/core_testing/integration/ts_types/ts_types.ts) — every one of those referrers is itself unreachable, so this file is dead only as a member of that cluster: if any referrer is in fact alive, this row falls with it
Dead file (~197 LoC) libs/core_testing/unit/resource_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~179 LoC) libs/core_testing/unit/type_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~170 LoC) libs/core_testing/unit/immediate_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~154 LoC) libs/core_testing/unit/stats_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~117 LoC) libs/core_testing/unit/timer_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~108 LoC) libs/core_testing/integration/wasm_stack_trace/wasm_stack_trace.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~101 LoC) libs/core_testing/unit/ops_async_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~95 LoC) libs/core_testing/unit/encode_decode_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~84 LoC) tools/upload_wptfyi.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~70 LoC) tools/verify_pr_title.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~69 LoC) ext/node/polyfills/internal/streams/duplexpair.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~64 LoC) libs/core_testing/unit/tc39_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~63 LoC) ext/websocket/autobahn/fuzzingclient.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~53 LoC) ext/node/polyfills/dns/promises_esm.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~42 LoC) libs/core_testing/unit/task_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~39 LoC) ext/node/polyfills/fs/promises_esm.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~38 LoC) libs/core_testing/integration/error_callsite/error_callsite.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~36 LoC) libs/core_testing/integration/error_rejection_catch/error_rejection_catch.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~35 LoC) libs/core_testing/integration/import_defer/import_defer.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~31 LoC) libs/core_testing/unit/error_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~29 LoC) libs/core_testing/integration/error_prepare_stack_trace/error_prepare_stack_trace.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~27 LoC) libs/core_testing/unit/ops_buffer_test.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~20 LoC) ext/websocket/autobahn/autobahn_server.js— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make
Dead file (~18 LoC) libs/core_testing/integration/ts_types/decorator.ts— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), but 1 in-repo import(s) from 1 other file(s) do name it (libs/core_testing/integration/ts_types/ts_types.ts) — every one of those referrers is itself unreachable, so this file is dead only as a member of that cluster: if any referrer is in fact alive, this row falls with it
Dead file (~17 LoC) libs/core_testing/integration/wasm_imports/lib.mjs— no import path from any entry point (908 application, 329 tooling, 1242 test roots considered), but 2 in-repo import(s) from 1 other file(s) do name it (libs/core_testing/integration/wasm_imports/import_from_wasm.mjs) — every one of those referrers is itself unreachable, so this file is dead only as a member of that cluster: if any referrer is in fact alive, this row falls with it
Unlisted import 'wasi' cli/tsc/dts/node/process.d.cts:112— Imported only as a TYPE and declared in no reachable package.json. The import is erased at compile time, so nothing is installed and no runtime resolution depends on it — but type-checking a clean clone will fail. Declare the typings it resolves through (or the package itself) in the owning package.json.
Unused dependency 'local-pkg' — Declared in tests/registry/npm/@denotest/file-dep/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
Unused dependency '@denotest/conditional-exports-node' — Declared in tests/registry/npm/@denotest/mjs-reexport-cjs/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
Unused dependency '@denotest/non-existent' — Declared in tests/registry/npm/@denotest/non-existent-dep/1.0.0/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
Orphaned file ext/crypto/subtle_sign.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/node_interop.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_decrypt.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/make_key.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/lsp/lint.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/http/network_buffered_stream.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_verify.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/io/pipe.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/node/ops/shell.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/node/ops/constant.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_get_public_key.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/crypto_key.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/slhdsa.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/tools/bundle/wasm.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/tools/pack/package_json.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/net/win_pipe.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_encapsulate.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/lsp/compiler_options.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_key.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/io/winpipe.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file ext/crypto/subtle_encapsulate_key.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/tools/pack/extensions.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/cache/code_cache.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file cli/lsp/testing/lsp_custom.rs:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Orphaned file tools/build_bench.ts:1— No one still active in this repository holds living knowledge of this file: everyone who made a meaningful change to it has gone quiet, or what the current team did to it (moves, reformatting, log-level or import edits, renames) never needed understanding it. If it breaks, no one currently understands it. Attach the read to the next change that touches it: have a second person review that change, and leave behind a short comment or test recording what the file is for.
Duplicated predicate tools/startup_order/generate_linux_function_orderfile.ts:377— `!Number.isSafeInteger(count) || count < 0 || count > totalStarts || raw.byteLength < (HEADER_WORDS + count) * 8` appears character-identically in 2 files — tools/startup_order/generate_linux_function_orderfile.ts, tools/startup_order/generate_macos_function_orderfile.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate tools/startup_order/generate_linux_function_orderfile.ts:92— `!Number.isSafeInteger(repeats) || repeats <= 0` appears character-identically in 2 files — tools/startup_order/generate_linux_function_orderfile.ts, tools/startup_order/generate_macos_function_orderfile.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/_fs/_fs_readdir.ts:222— `!encoding || encoding === "utf8" || encoding === "utf-8"` appears character-identically in 2 files — ext/node/polyfills/_fs/_fs_readdir.ts, ext/node/polyfills/fs.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/crypto/_randomFill.mjs:70— `!isAnyArrayBuffer(buf) && !isArrayBufferView(buf)` appears character-identically in 2 files — ext/node/polyfills/internal/crypto/_randomFill.mjs, ext/node/polyfills/internal_binding/_timingSafeEqual.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/_fs/_fs_common.ts:40— `!optOrCallback || typeof optOrCallback === "function"` appears character-identically in 2 files — ext/node/polyfills/_fs/_fs_common.ts, ext/node/polyfills/fs.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/tty.js:153— `(env.NODE_DISABLE_COLORS !== undefined && env.NODE_DISABLE_COLORS !== "") || (env.NO_COLOR !== undefined && env.NO_COLOR !== "") || env.TERM…` appears character-identically in 2 files — ext/node/polyfills/internal/tty.js, ext/node/polyfills/internal/util/colorize.mjs. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/buffer.mjs:3019— `(min != null && value < min) || (max != null && value > max) || ((min != null || max != null) && NumberIsNaN(value))` appears character-identically in 2 files — ext/node/polyfills/internal/buffer.mjs, ext/node/polyfills/internal/validators.mjs. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/crypto/_randomBytes.ts:44— `NumberIsNaN(size) || size > kMaxPossibleLength || size < 0` appears character-identically in 2 files — ext/node/polyfills/internal/crypto/_randomBytes.ts, ext/node/polyfills/internal/crypto/_randomFill.mjs. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/_http_proxy.js:142— `StringPrototypeStartsWith(hostname, "[") && StringPrototypeEndsWith(hostname, "]")` appears character-identically in 2 files — ext/node/polyfills/_http_proxy.js, REDACTED. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate tools/startup_order/generate_linux_function_orderfile.ts:100— `binary === undefined || output === undefined` appears character-identically in 2 files — tools/startup_order/generate_linux_function_orderfile.ts, tools/startup_order/generate_macos_function_orderfile.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/fetch/26_fetch.js:292— `charset.length >= 2 && charset[0] === '"' && charset[charset.length - 1] === '"'` appears character-identically in 2 files — ext/fetch/26_fetch.js, REDACTED. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/streams/readable.js:322— `defaultEncoding == null || defaultEncoding === "utf8" || defaultEncoding === "utf-8"` appears character-identically in 2 files — ext/node/polyfills/internal/streams/readable.js, ext/node/polyfills/internal/streams/writable.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/_process/streams.mjs:171— `env === undefined && (count === undefined || typeof count === "object" && count !== null)` appears character-identically in 2 files — ext/node/polyfills/_process/streams.mjs, ext/node/polyfills/internal/tty.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/path/_posix.ts:292— `ext !== undefined && ext.length > 0 && ext.length <= path.length` appears character-identically in 2 files — ext/node/polyfills/path/_posix.ts, ext/node/polyfills/path/_win32.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/path/_posix.ts:282— `ext !== undefined && typeof ext !== "string"` appears character-identically in 2 files — ext/node/polyfills/path/_posix.ts, ext/node/polyfills/path/_win32.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/path/_posix.ts:293— `ext.length === path.length && ext === path` appears character-identically in 2 files — ext/node/polyfills/path/_posix.ts, ext/node/polyfills/path/_win32.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/crypto/keygen.ts:218— `formatStr === undefined && defaultFormat !== undefined` appears character-identically in 2 files — ext/node/polyfills/internal/crypto/keygen.ts, ext/node/polyfills/internal/crypto/keys.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/_http_outgoing.ts:947— `headers.length && ArrayIsArray(headers[0])` appears character-identically in 2 files — ext/node/polyfills/_http_outgoing.ts, ext/node/polyfills/internal/http2/compat.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/worker_threads.ts:761— `i < 1000 && this.#status !== "TERMINATED"` appears character-identically in 2 files — ext/node/polyfills/worker_threads.ts, runtime/js/11_workers.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/crypto/keygen.ts:252— `keyType !== undefined && keyType !== "ec"` appears character-identically in 2 files — ext/node/polyfills/internal/crypto/keygen.ts, ext/node/polyfills/internal/crypto/keys.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/crypto/keygen.ts:240— `keyType !== undefined && keyType !== "rsa"` appears character-identically in 2 files — ext/node/polyfills/internal/crypto/keygen.ts, ext/node/polyfills/internal/crypto/keys.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/dgram.ts:166— `options !== null && typeof options === "object"` appears character-identically in 3 files — ext/node/polyfills/dgram.ts, ext/node/polyfills/https.ts, ext/web/01_dom_exception.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/01_require.js:3208— `options !== undefined && (typeof options !== "object" || options === null)` appears character-identically in 2 files — ext/node/polyfills/01_require.js, ext/node/polyfills/perf_hooks.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/dns.ts:430— `options && (options as ResolveOptions).ttl` appears character-identically in 2 files — ext/node/polyfills/dns.ts, ext/node/polyfills/internal/dns/promises.ts. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Duplicated predicate ext/node/polyfills/internal/streams/readable.js:315— `options && options.autoDestroy === false` appears character-identically in 2 files — ext/node/polyfills/internal/streams/readable.js, ext/node/polyfills/internal/streams/writable.js. It is one line, so the duplication detector's token window never sees it; the copies drift when only one is corrected. Give the condition a name and one home.
Silent fallback default on Err cli/lsp/language_server.rs:2145— `resolution_to_hover_text` turns every `Err` into `"_[errored]_".to_string()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/lsp/cache.rs:32— `calculate_fs_version_at_path` turns every `Err` into `Some("1".to_string())` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tools/bench/mitata.rs:132— `windows` turns every `Err` into `String::from("unknown")` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tools/check.rs:475— `remote_root_mirror_files` turns every `Err` into `Vec::new()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tools/framework.rs:261— `deno_exe` turns every `Err` into `"deno".into()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tools/test/fmt.rs:18— `to_relative_path_or_remote_url` turns every `Err` into `"<anonymous>".to_string()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tools/upgrade.rs:1525— `build_delta_chain` turns every `Err` into `vec![]` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err cli/tsc/tsconfig_gen.rs:1521— `package_export_keys` turns every `Err` into `vec![]` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/crypto/digest.rs:467— `value_to_byte_vec` turns every `Err` into `Vec::new()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/http/http_next.rs:2575— `op_http_read_request_body` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/stream_wrap.rs:371— `read_start_intercepted_for_stream` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/tcp_wrap.rs:334— `bind_inner` turns every `Err` into `Ok(-1)` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/tcp_wrap.rs:574— `bind6` turns every `Err` into `Ok(-1)` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/tcp_wrap.rs:736— `connect` turns every `Err` into `Ok(-1)` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/tcp_wrap.rs:804— `connect6` turns every `Err` into `Ok(-1)` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/llhttp/binding.rs:455— `on_headers_complete` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/llhttp/binding.rs:604— `on_body` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/tls.rs:130— `parse_extra_ca_certs` turns every `Err` into `vec![]` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/node/ops/v8.rs:418— `op_v8_query_objects_count` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/os/lib.rs:830— `rss` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/web/console/error_fmt.rs:946— `path_to_file_url_href` turns every `Err` into `String::new()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err ext/websocket/lib.rs:985— `op_ws_get_error` turns every `Err` into `"Bad resource".into()` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Silent fallback default on Err libs/core/ops_builtin.rs:568— `op_str_byte_length` turns every `Err` into `0` — a failure becomes a plausible value and a silent behavior change with no trail. Log the error or propagate it with `?`. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the arm or in the doc comment, and the row stops firing.
Off-boarding risk: anonymized user #1 — If anonymized user #1 becomes unavailable, 30 significant file(s) lose their only recent owner: libs/config/glob/mod.rs, libs/cli_parser/src/tests.rs, libs/core/async_cell.rs, libs/core/modules/map/ext_script.rs, libs/core/modules/recursive_load.rs, cli/tsc/native.rs, ext/node_crypto/primes.rs, libs/core/modules/map/dynamic.rs (+22 more). Pair on, review, or document these before any departure.
Off-boarding risk: anonymized user #2 — If anonymized user #2 becomes unavailable, 6 significant file(s) lose their only recent owner: ext/node/ops/wasi.rs, ext/crypto/algorithm.rs, ext/crypto/subtle_wrap_key.rs, cli/lsp/test_code_actions.rs, ext/napi/pe.rs, libs/core/runtime/host_defined_options.rs. Pair on, review, or document these before any departure.
Off-boarding risk: anonymized user #3 — If anonymized user #3 becomes unavailable, 4 significant file(s) lose their only recent owner: cli/lib/standalone/virtual_fs.rs, cli/util/draw_thread.rs, tools/release/npm/build.ts, libs/npm_installer/graph.rs. Pair on, review, or document these before any departure.
Off-boarding risk: anonymized user #4 — If anonymized user #4 becomes unavailable, 3 significant file(s) lose their only recent owner: libs/dcore/src/inspector_server.rs, runtime/subprocess_windows/src/anon_pipe.rs, libs/core/io/buffer_strategy.rs. Pair on, review, or document these before any departure.
Silent fallback default in catch ext/node/polyfills/internal/assert/assertion_error.js:26— `getConsoleWidth` swallows every exception into `return 80` — a data error becomes a silent behavior change with no trail. Log the failure or let it raise. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the handler or in the docstring, and the row stops firing.
Silent fallback default in catch ext/node/polyfills/internal_binding/node_options.ts:160— `getExecArgv` swallows every exception into `return []` — a data error becomes a silent behavior change with no trail. Log the failure or let it raise. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the handler or in the docstring, and the row stops firing.
Silent fallback default in catch ext/node/polyfills/repl.ts:306— `_getPropertyNames` swallows every exception into `return []` — a data error becomes a silent behavior change with no trail. Log the failure or let it raise. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the handler or in the docstring, and the row stops firing.
Silent fallback default in catch ext/web/00_url.js:980— `origin` swallows every exception into `return "null"` — a data error becomes a silent behavior change with no trail. Log the failure or let it raise. If that constant is the correct answer rather than a stand-in for a value that could not be read, say so in a comment on the handler or in the docstring, and the row stops firing.
Subsumed condition operand libs/cli_parser/src/convert.rs:427— `result.contains("no-lock")` can never decide this `||` — every value satisfying `result.contains("no-lock")` also satisfies `result.contains("lock")`, so the `||` chain is already decided by the latter. The expression is equivalent to the chain without it, which means it is wider than it reads. Delete the dead operand, or narrow the surviving one if IT is the accident.
Subsumed condition operand libs/cli_parser/src/convert.rs:429— `result.contains("frozen-lockfile")` can never decide this `||` — every value satisfying `result.contains("frozen-lockfile")` also satisfies `result.contains("lock")`, so the `||` chain is already decided by the latter. The expression is equivalent to the chain without it, which means it is wider than it reads. Delete the dead operand, or narrow the surviving one if IT is the accident.
Subsumed condition operand libs/cli_parser/src/convert.rs:432— `result.contains("no-check")` can never decide this `||` — every value satisfying `result.contains("no-check")` also satisfies `result.contains("check")`, so the `||` chain is already decided by the latter. The expression is equivalent to the chain without it, which means it is wider than it reads. Delete the dead operand, or narrow the surviving one if IT is the accident.
D16 · Bus Factor· Further sole-owners (lower concentration) · ×1
Further sole-owners (lower concentration) — 5 other contributor(s) are each the sole owner of a small amount of code below the off-boarding threshold — folded into the bus-factor score and metrics (50 single-owned of 796 analysed files in total, counted over production source files of roughly 2,400 bytes or more, excluding vendored, generated, example/demo and scaffolding-template trees and test files identified by path convention, largest first; 796 of the 1141 production source files in this repository met that bar). They are anonymized user #5 (2 file(s)), anonymized user #6 (2 file(s)), anonymized user #7 (1 file(s)), anonymized user #8 (1 file(s)), anonymized user #9 (1 file(s)) — spread or document their files in the same way, at lower priority than the named off-boarding risks above. The files folded here: libs/core/convert.rs, libs/ops/conversion/from_v8/enum.rs, libs/core/fast_string.rs, cli/tools/pack/npm_tarball.rs, tools/lint_plugins/prefer_primordials.ts, cli/util/archive.rs, ext/http/compressible.rs.
No ADRs found — No ADRs found. No recognised ADR directory (`docs/adr/`, `docs/decisions/`, `adr/`, `docs/rfcs/`, an `ADR0001/` folder, or their siblings) exists anywhere in this tree. What was searched, so you can tell an empty log from a search that missed one: every directory under the tree (build output, dependencies and VCS metadata excepted), for a document that is either any non-index page inside a recognised ADR directory, whatever its name and however deeply nested (`docs/adr/use-postgres.md`, `docs/adr/2024/0001-x.md`); or a file anywhere whose name is ADR-shaped (`0001-use-postgres.md`, `adr-012-caching.md`); or, when neither turned anything up, a document carrying the decision-record signature (an "Architecture Decision Record" heading, or Status / Context / Decision / Consequences as section headings). A decision log that clears none of these — unnumbered files outside any recognised directory, without those headings — is not seen by this check and this row is then wrong. If that is your case, say so rather than renaming anything; otherwise, consider recording architectural decisions in `docs/adr/`.
D26 · Project Cohesion· Projects may be oversized for their cohesion · ×1
Projects may be oversized for their cohesion — 8 of 71 project(s) overshoot their size bounds, lowering Project Cohesion to 7.8/10. The most over is `cli` (153876 LoC, 795 module-visible types across 29 directories). Review these for cohesion — draw the boundary inside the module first (group each responsibility into its own package or directory and keep the cross-boundary members non-public), since splitting a published package moves types between packages and breaks consumers.
D34 · Knowledge Freshness· Further orphaned files (smaller) · ×1
Further orphaned files (smaller) — 26 smaller file(s) also have no living knowledge — folded into the freshness score and metrics rather than raised one row each — most significant first: ext/crypto/subtle_sign.rs, ext/crypto/node_interop.rs, ext/crypto/subtle_decrypt.rs, ext/crypto/make_key.rs, cli/lsp/lint.rs, ext/crypto/subtle_verify.rs, ext/io/pipe.rs, ext/node/ops/shell.rs (and 18 more) (35 orphaned of 796 analysed files in total, counted over production source files of roughly 2,400 bytes or more, excluding vendored, generated, example/demo and scaffolding-template trees and test files identified by path convention, largest first; 796 of the 1141 production source files in this repository met that bar). Attach the read to the next change that touches one of them: have a second person review that change, and leave behind a short comment or test recording what the file is for, so the knowledge comes back at the cost of a change you were making anyway.
No ADRs — No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
Logging is not universal — Only 28/33 runnable modules use logging (modules with no entry point or server are excluded — they are libraries a runnable module hosts). Silent: `.`, `ext/fetch`, `libs/dcore`, `libs/node_shim`, `libs/ops/compile_test_runner`.
Nullable reference types not enabled everywhere — 0/1 NRT-eligible project(s) enable <Nullable>enable</Nullable> (projects targeting a pre-C#-8 framework are excluded — NRTs aren't available there). NRTs catch a whole class of null-deref bugs at compile time.
Outdated: aead-gcm-stream — `aead-gcm-stream` is locked at 0.4.0 but 0.4.1 is the current stable release on crates.io, and it already satisfies the `"0.4"` requirement declared in ext/node_crypto/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p aead-gcm-stream` and commit the updated REDACTED.
Outdated: anyhow — `anyhow` is locked at 1.0.98 but 1.0.104 is the current stable release on crates.io, and it already satisfies the `"1.0.57"` requirement declared in ext/kv/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p anyhow` and commit the updated REDACTED.
Outdated: arc-swap — `arc-swap` is locked at 1.7.1 but 1.9.3 is the current stable release on crates.io, and it already satisfies the `"1.7"` requirement declared in cli/lib/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p arc-swap` and commit the updated REDACTED.
Outdated: argon2 — `argon2` is locked at 0.6.0-rc.8 but 0.6.0 is the current stable release on crates.io, and it already satisfies the `"0.6.0-rc.8"` requirement declared in ext/crypto/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p argon2` and commit the updated REDACTED.
Outdated: async-stream — `async-stream` is locked at 0.3.5 but 0.3.6 is the current stable release on crates.io, and it already satisfies the `"0.3"` requirement declared in ext/cache/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p async-stream` and commit the updated REDACTED.
Outdated: async-trait — `async-trait` is locked at 0.1.88 but 0.1.92 is the current stable release on crates.io, and it already satisfies the `"0.1.73"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p async-trait` and commit the updated REDACTED.
Outdated: backhand — `backhand` is locked at 0.25.1 but 0.25.5 is the current stable release on crates.io, and it already satisfies the `"0.25.1"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p backhand` and commit the updated REDACTED.
Outdated: bytemuck — `bytemuck` is locked at 1.24.0 but 1.25.2 is the current stable release on crates.io, and it already satisfies the `"1.17.1"` requirement declared in ext/canvas/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p bytemuck` and commit the updated REDACTED.
Outdated: bytes — `bytes` is locked at 1.11.1 but 1.12.1 is the current stable release on crates.io, and it already satisfies the `"1.11.1"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p bytes` and commit the updated REDACTED.
Outdated: cc — `cc` is locked at 1.2.56 but 1.10.0 is the current stable release on crates.io, and it already satisfies the `"1"` requirement declared in ext/node/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p cc` and commit the updated REDACTED.
Outdated: chrono — `chrono` is locked at 0.4.42 but 0.4.45 is the current stable release on crates.io, and it already satisfies the `"0.4"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p chrono` and commit the updated REDACTED.
Outdated: color-print — `color-print` is locked at 0.3.5 but 0.3.7 is the current stable release on crates.io, and it already satisfies the `"0.3.5"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p color-print` and commit the updated REDACTED.
Outdated: data-encoding — `data-encoding` is locked at 2.5.0 but 2.11.1 is the current stable release on crates.io, and it already satisfies the `"2.3.3"` requirement declared in ext/node_crypto/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p data-encoding` and commit the updated REDACTED.
Outdated: deno_native_certs — `deno_native_certs` is locked at 0.3.0 but 0.3.1 is the current stable release on crates.io, and it already satisfies the `"0.3.0"` requirement declared in ext/node/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p deno_native_certs` and commit the updated REDACTED.
Outdated: errno — `errno` is locked at 0.3.10 but 0.3.14 is the current stable release on crates.io, and it already satisfies the `"0.3.10"` requirement declared in ext/node/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p errno` and commit the updated REDACTED.
Outdated: filetime — `filetime` is locked at 0.2.23 but 0.2.29 is the current stable release on crates.io, and it already satisfies the `"0.2.16"` requirement declared in ext/fs/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p filetime` and commit the updated REDACTED.
Outdated: futures — `futures` is locked at 0.3.31 but 0.3.34 is the current stable release on crates.io, and it already satisfies the `"0.3.31"` requirement declared in ext/cache/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p futures` and commit the updated REDACTED.
Outdated: futures-channel — `futures-channel` is locked at 0.3.31 but 0.3.34 is the current stable release on crates.io, and it already satisfies the `"0.3.31"` requirement declared in runtime/subprocess_windows/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p futures-channel` and commit the updated REDACTED.
Outdated: glob — `glob` is locked at 0.3.1 but 0.3.4 is the current stable release on crates.io, and it already satisfies the `"0.3.1"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p glob` and commit the updated REDACTED.
Outdated: h2 — `h2` is locked at 0.4.19 but 0.4.20 is the current stable release on crates.io, and it already satisfies the `"0.4.6"` requirement declared in ext/fetch/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p h2` and commit the updated REDACTED.
Outdated: hdrhistogram — `hdrhistogram` is locked at 7.5.4 but 7.6.0 is the current stable release on crates.io, and it already satisfies the `"7.5"` requirement declared in ext/node/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p hdrhistogram` and commit the updated REDACTED.
Outdated: http — `http` is locked at 1.4.0 but 1.5.0 is the current stable release on crates.io, and it already satisfies the `"1.0"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p http` and commit the updated REDACTED.
Outdated: http-body — `http-body` is locked at 1.0.0 but 1.1.0 is the current stable release on crates.io, and it already satisfies the `"1.0"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p http-body` and commit the updated REDACTED.
Outdated: http-body-util — `http-body-util` is locked at 0.1.3 but 0.1.5 is the current stable release on crates.io, and it already satisfies the `"0.1.2"` requirement declared in cli/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p http-body-util` and commit the updated REDACTED.
Outdated: httparse — `httparse` is locked at 1.10.0 but 1.10.1 is the current stable release on crates.io, and it already satisfies the `"1.8.0"` requirement declared in libs/http_h1/Cargo.toml — so the lockfile is behind this repository's own declared range. Run `cargo update -p httparse` and commit the updated REDACTED.
Skipped (documented): (unnamed test) tests/testdata/coverage/invalid_cache/mod.test.ts:2— Skipped with a documented reason — a deferral, not lazy debt: declared with no body — a pending test the runner lists but never runs
Skipped (documented): (unnamed test) tests/specs/npm/workspace_symlink_cyclic/packages/pkg-a/src/test.spec.ts:8— Skipped with a documented reason — a deferral, not lazy debt: declared with no body — a pending test the runner lists but never runs
D8 · Code Coverage· Coverage read from a committed report · ×1
Coverage read from a committed report — Line coverage 62.9% — read from a committed lcov report (tests/testdata/coverage/complex_expected.lcov); the in-image collector couldn't run the suite (commonly external-service dependencies). A real measurement, but from a committed artifact rather than a fresh in-image run.
Appendix B — Reproduction & audit trail
Every external tool invocation behind a deep-scan dimension — the tool, its captured version, the exact command, how many findings it yielded, and a link to the retained raw output. To reproduce any finding: check out the same commit and run the command shown (repo-relative — never an absolute scratch path). The complete raw scanner output is retained verbatim under artifacts/raw/ (indexed in artifacts/raw/index.json); per-invocation exit codes and wall-clock durations are in sidecar.json — kept out of this table so the rendered report stays byte-identical across runs of the same commit.
semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 23 file(s) — `cli/tsc/dts/lib.deno.ns.d.ts`, `cli/tsc/dts/lib.deno.unstable.d.ts`, `cli/tsc/dts/lib.es2015.iterable.d.ts`, `cli/tsc/dts/lib.es2015.symbol.wellknown.d.ts`, `cli/tsc/dts/lib.es2018.asynciterable.d.ts`, … (+18 more) — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real.
runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
Run 01a1762f-d068-7c53-b3a0-c7d04a299e4c · every finding is also locatable in findings.md, and the complete scoring record (with exit codes + durations) in sidecar.json.
Issues: 49 · Warnings: 4310 · Recommendations: 101 · Info: 81 — Appendix A · all findings · full markdown report.
Generated by Watchdog — deterministic code-health analysis. 26-10-2026 @ 03:10 UTC.
Downloadable artifacts
Machine-readable and reproducible from this commit + frozen rubric — drop them straight into a contract appendix, a CRA dossier, or a downstream SCA / VEX tool.