How many people understand each part?
38 of 40 modules depend on one person
Is there a safety net for changes?
tests run in CI and live in a central test directory; tying them to individual modules would need a coverage run
How much scaffolding did nobody remove?
51 in source, 39 in tests (kept, not work), 23 untouched for 3+ years, 30 external issues to check
Does it build from scratch?
1 gap that makes the build less reproducible (submodules)
Is the documentation real?
2 day-one questions are unanswered: how to deploy it; how to restore a backup
Who holds the keys?
answered by a person, not by a scanner
Where knowledge is concentrated
Read from who changed what, not from a staffing plan. Contributors are labelled, not named: this is about how knowledge is spread, never about a person.
| Module | Changes | People | Reading |
|---|---|---|---|
test |
1339 | 67 | risk one person made 61% of the changes |
(root) |
993 | 57 | risk one person made 67% of the changes |
lib |
681 | 57 | risk one person made 64% of the changes |
.changeset |
604 | 23 | risk one person made 68% of the changes |
lib/dependencies |
406 | 29 | risk one person made 65% of the changes |
lib/css |
324 | 14 | risk one person made 79% of the changes |
lib/util |
266 | 20 | risk one person made 76% of the changes |
lib/javascript |
240 | 24 | risk one person made 69% of the changes |
lib/config |
205 | 18 | risk one person made 75% of the changes |
lib/optimize |
202 | 19 | risk one person made 64% of the changes |
declarations |
198 | 17 | risk one person made 67% of the changes |
schemas |
193 | 15 | risk one person made 66% of the changes |
Scaffolding nobody removed
Code written because of an external problem, oldest first, from the source only. A comment in a test that links to an issue is usually the regression test for that bug, so a closed issue there is a reason to keep the test, not to remove it. This project has 39 of those and they are not listed here.
| Untouched | Where | Recorded reason |
|---|---|---|
| 8.5 yr | lib/UseStrictPlugin.js:46Remove "use strict" expression. It will be added later by the renderer again. This is necessary in order to not break the strict mode when w |
github:webpack/webpack#1970 |
| 7.9 yr | lib/util/comparators.js:536TODO this is no longer needed when minimum node.js version is >= 12 since these versions ship with a stable sort function * Keep original or |
unmarked |
| 7.7 yr | lib/ExternalModuleFactoryPlugin.js:386TODO webpack 6 remove this |
unmarked |
| 6.9 yr | lib/ChunkTemplate.js:30TODO webpack 6 remove this class |
unmarked |
| 6.9 yr | lib/MainTemplate.js:49TODO webpack 6 remove this class |
unmarked |
| 6.9 yr | lib/ModuleTemplate.js:31TODO webpack 6: remove this class |
unmarked |
| 6.8 yr | lib/ExternalModuleFactoryPlugin.js:78TODO webpack 6 remove this |
unmarked |
| 6.2 yr | lib/util/semver.js:420EOA end of array equal (version is equal range): when !negated: return true, when negated: return false bigger (version is bigger as range): |
unmarked |
| 3.8 yr | lib/NormalModuleFactory.js:996https://github.com/webpack/webpack/issues/16466 if a request exists PrePostAutoLoaders, should disable modifying Rule.type |
github:webpack/webpack#16466 |
| 2.1 yr | lib/WebpackOptionsApply.js:110ts-expect-error https://github.com/microsoft/TypeScript/issues/41697 |
github:microsoft/TypeScript#41697 |
| 2.1 yr | lib/WebpackOptionsApply.js:253ts-expect-error https://github.com/microsoft/TypeScript/issues/41697 |
github:microsoft/TypeScript#41697 |
| 2.1 yr | lib/WebpackOptionsApply.js:869ts-expect-error https://github.com/microsoft/TypeScript/issues/41697 |
github:microsoft/TypeScript#41697 |
The same report, on your own repository
npx ancient-code .
Everything on this page came out of that one command, run against a full clone. It is free and open source, it needs no account, and your code never leaves your machine.