pith. sign in

arxiv: 2604.08747 · v1 · submitted 2026-04-09 · 💻 cs.SE

A Longitudinal Study of Dependency Reclassifications in JavaScript Projects

Yuxin Liu , Cristian Bogdan , Benoit Baudry This is my paper

Pith reviewed 2026-05-10 16:42 UTC · model grok-4.3

classification 💻 cs.SE
keywords JavaScriptdependency managementsoftware maintenancereclassificationlongitudinal studypackage.jsonopen source projectsrole assignment
0
0 comments X

The pith

Dependency reclassification occurs in 79.1% of actively maintained JavaScript projects.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper studies how developers in JavaScript projects change the assigned roles of third-party dependencies over the project's lifetime. These changes include removing dependencies or reassigning them among three roles: Core for runtime use, Dev for development tools only, and Peer for code provided by the consumer. By examining commit histories in 33,087 projects, the work shows that reclassifications affect nearly 80 percent of projects, with removals in 97.2 percent, role switches in 38 percent, and frequent reversals such as reintroducing removed dependencies in 33.1 percent of cases. The median time span for these activities is 408 days, indicating that dependency role decisions are not one-time events but part of ongoing maintenance.

Core claim

Our analysis of 33,087 JavaScript projects with active dependency maintenance reveals that dependency reclassification is a prevalent maintenance activity, occurring in 79.1% of the studied projects. Of these projects, nearly all (97.2%) remove dependencies at some point, while 38.0% undergo role reassignments across Core (runtime), Dev (development-only), and Peer (consumer-provided) roles. These changes are not always final, as 33.1% of projects later reintroduce removed dependencies and 11.2% exhibit repeated role switching. Reclassification practices also tend to unfold over long periods, with a median duration of 408 days.

What carries the argument

Automated detection of dependency roles (Core, Dev, Peer) and reclassifications by tracking changes to package.json declarations across commit histories.

Load-bearing premise

The automated detection of dependency roles and reclassifications from commit history accurately reflects developer intent without significant misclassification.

What would settle it

A manual audit of commit messages and code usage in a sample of projects flagged by the detection method to check whether each detected role change matches the developer's documented reason or actual usage pattern.

read the original abstract

Modern software projects depend on third-party dependencies, whose declarations must be maintained as projects evolve. Prior work has focused on dependency version updates, while much less is known about how developers assign dependencies to different roles over time. In this paper, we investigate how developers of JavaScript projects reclassify their dependencies, including removal and role reassignment. Our analysis of 33,087 JavaScript projects with active dependency maintenance reveals that dependency reclassification is a prevalent maintenance activity, occurring in 79.1% of the studied projects. Of these projects, nearly all (97.2%) remove dependencies at some point, while 38.0% undergo role reassignments across Core (runtime), Dev (development-only), and Peer (consumer-provided) roles. These changes are not always final, as 33.1% of projects later reintroduce removed dependencies and 11.2% exhibit repeated role switching. Reclassification practices also tend to unfold over long periods, with a median duration of 408 days. These findings broaden the study of dependency maintenance beyond version updates, and contribute implications for dependency tools, package managers, and research to support correct dependency role declarations.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper reports an empirical longitudinal study of dependency maintenance in 33,087 JavaScript projects with active dependency updates. It claims that dependency reclassification (removals plus role changes among Core, Dev, and Peer) occurs in 79.1% of projects, with 97.2% of those projects removing dependencies at least once, 38.0% performing role reassignments, 33.1% reintroducing previously removed dependencies, 11.2% showing repeated role switches, and a median reclassification duration of 408 days. The work positions these observations as broadening dependency research beyond version pinning.

Significance. If the automated role and change detection is reliable, the large-scale observational data would usefully document role management as a common, long-term maintenance activity and supply concrete implications for package-manager tooling and dependency-analysis research.

major comments (2)
  1. [Methods] Methods section (automated detection of roles and reclassifications): The central 79.1% prevalence statistic is derived from parsing git history for changes to the three dependency sections of package.json, yet the manuscript reports no precision, recall, or inter-rater agreement figures on a manually labeled sample. Common confounders such as dependency-bot PRs, lockfile-only commits, or partial edits are not quantified, so even modest false-positive rates would materially affect the headline percentage and the downstream 38.0% role-reassignment and 97.2% removal claims.
  2. [Results] Results section (prevalence and role-reassignment statistics): Because the 79.1% figure and its breakdowns rest directly on the unvalidated extraction pipeline, the absence of accuracy metrics makes it impossible to assess whether the reported rates reflect developer intent or extraction noise; this is load-bearing for the paper's primary contribution.
minor comments (1)
  1. [Abstract] Abstract: The phrasing 'dependency reclassification is a prevalent maintenance activity, occurring in 79.1%' could be clarified to explicitly separate removal events from role reassignments so readers immediately see the distinct 97.2% and 38.0% sub-figures.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. The comments highlight an important gap in reporting the reliability of our automated detection pipeline. We address each major comment below and will incorporate the suggested improvements in the revised version.

read point-by-point responses

  1. Referee: [Methods] Methods section (automated detection of roles and reclassifications): The central 79.1% prevalence statistic is derived from parsing git history for changes to the three dependency sections of package.json, yet the manuscript reports no precision, recall, or inter-rater agreement figures on a manually labeled sample. Common confounders such as dependency-bot PRs, lockfile-only commits, or partial edits are not quantified, so even modest false-positive rates would materially affect the headline percentage and the downstream 38.0% role-reassignment and 97.2% removal claims.

    Authors: We agree that the absence of explicit validation metrics is a limitation. Our extraction process parses git diffs on package.json to detect section-level changes (additions, removals, and role shifts between dependencies, devDependencies, and peerDependencies). This is a deterministic, rule-based approach rather than a learned classifier, but we acknowledge that unquantified noise from bots, lockfile-only commits, or incomplete edits could affect results. In the revision we will add a manual validation study: two authors will independently label a stratified random sample of 300 projects (covering at least 500 reclassification events), compute precision, recall, and Cohen's kappa, and report the figures together with an analysis of common error sources. We will also quantify the prevalence of bot-authored commits and lockfile-only changes in the dataset and discuss their potential impact. revision: yes

  2. Referee: [Results] Results section (prevalence and role-reassignment statistics): Because the 79.1% figure and its breakdowns rest directly on the unvalidated extraction pipeline, the absence of accuracy metrics makes it impossible to assess whether the reported rates reflect developer intent or extraction noise; this is load-bearing for the paper's primary contribution.

    Authors: We recognize that the headline statistics (79.1% prevalence, 97.2% removals, 38.0% role reassignments) are only interpretable once the extraction accuracy is known. The planned validation study described above will directly support these results by providing accuracy bounds and an error analysis. In the revised results section we will present the validated figures alongside the original ones, include a limitations subsection on extraction noise, and qualify the claims accordingly. This will allow readers to judge whether the observed rates primarily reflect developer behavior. revision: yes

Circularity Check

0 steps flagged

No circularity: purely observational empirical counts from project data

full rationale

The paper reports direct observational statistics (79.1% of projects exhibit reclassification, 97.2% remove dependencies, etc.) computed from parsing commit histories across 33,087 JavaScript repositories. No equations, fitted parameters, predictive models, or self-citation chains appear in the derivation. All figures are simple aggregates and proportions of detected events; the automated role extraction from package.json diffs is an input-processing step whose validity is an external methodological assumption, not a reduction of the output to the input by construction. The study is self-contained against its own dataset with no load-bearing self-referential steps.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities are involved; the work is an observational analysis of existing project data.

pith-pipeline@v0.9.0 · 5502 in / 1030 out tokens · 38112 ms · 2026-05-10T16:42:45.985402+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

2 extracted references · 2 canonical work pages

  1. [1]

    Abdalkareem R, Nourry O, Wehaibi S, et al (2017) Why do developers use trivial packages? an empirical case study on npm. In: Proceedings of the 2017 11th joint meeting on foundations of software engineering, pp 385–395 Berhe S, Maynard M, Khomh F (2020) Software release patterns when is it a good time to update a software component? Procedia Computer Scie...

    work page doi:10.1109/tse.2022.3191353 2017

  2. [2]

    Systems, Programming, Languages, and Applications: Software for Humanity, pp 29–33 Kikas R, Gousios G, Dumas M, et al (2017) Structure and evolution of package depen- dency networks. In: 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR), IEEE, pp 102–112 25 Koishybayev I, Kapravelos A (2020) Mininode: Reducing the attack su...

    work page 2017