💻 computer science

A Longitudinal Study of Dependency Reclassifications in JavaScript Projects

This paper presents a longitudinal study of 33,087 JavaScript projects revealing that dependency reclassification, including removal and role reassignment, is a prevalent and often iterative maintenance activity that unfolds over extended periods, highlighting the need for improved tooling and research to support correct dependency declarations.

Original authors: Yuxin Liu, Cristian Bogdan, Benoit Baudry

Published 2026-04-13

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Yuxin Liu, Cristian Bogdan, Benoit Baudry

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a massive, ever-changing Lego castle. To make your castle cool, you need to borrow pieces from other people's sets. In the world of software (specifically JavaScript), these borrowed pieces are called dependencies.

Every time you add a piece, you have to write it down in a "shopping list" (called package.json). But here's the tricky part: you have to decide what kind of piece it is.

Core: A piece that is essential for the castle to stand up and function right now (like the foundation).
Dev: A piece you only need while you are building the castle (like a hammer or a ruler), but you don't need it once the castle is finished.
Peer: A piece you think the owner of the castle should bring themselves, so you don't have to carry it.

The Problem: The "Oops, I Packed the Wrong Bag" Moment

For a long time, researchers thought developers just added new pieces or updated old ones to newer versions. They assumed that once you put a piece in the "Foundation" bag, it stayed there forever.

But this paper says: Nope! Developers are constantly repacking their bags.

The authors looked at over 33,000 software projects (like a giant library of Lego castles) and watched how developers changed their shopping lists over time. They found that developers are constantly realizing, "Wait, I don't need this hammer in the final castle," or "Oh no, I forgot to bring this essential brick!"

The Three Main Ways Developers "Repack"

The study found that developers do three main things to fix their lists:

1. The "Purge" (Removal)

Sometimes, a piece is just useless.

The Analogy: You realize you packed a snow shovel for a beach vacation. You take it out.
The Finding: This happens in 97% of projects. But here's the twist: 33% of the time, they take it out, realize they actually do need it, and put it back in later! It's like packing the shovel, realizing you need it for the snow day, and repacking it.

2. The "Role Swap" (Reassignment)

Sometimes, a piece is in the wrong bag.

The Analogy: You packed your "Construction Hammer" in the "Final Castle" bag. You realize, "Hey, this is only for building, not for living in!" So, you move it from the Foundation bag to the Construction Tools bag.
The Finding: This happens in 38% of projects. It's a constant game of musical chairs where tools move between "Production" (the real thing) and "Development" (the workshop).

3. The "Fence Jumper" (Peer to Core)

Sometimes, you tell a guest, "You bring your own chair," but then you realize, "Actually, I'll just buy a chair for you so you don't have to."

The Analogy: You stop asking the guest to bring the chair (Peer) and decide to buy it yourself (Core).
The Finding: This happens often because asking guests to bring their own stuff is confusing and error-prone.

The "Oscillation" (The Rollercoaster)

The most interesting finding is that this isn't a one-time fix.

The Analogy: Imagine you move a tool from the "Workshop" to the "Living Room." Then, two weeks later, you move it back. Then, a month later, you move it to the "Garage."
The Finding: About 11% of the time, developers keep moving a dependency back and forth between roles. It's like a pendulum swinging until they finally figure out where it belongs.

The Big Surprise: It Takes a Long Time!

You might think, "If I made a mistake, I'd fix it immediately."

The Reality: No. The study found that the median time to fix a role mistake is 408 days (more than a year!).
The Analogy: It's like realizing you packed the wrong shoes for a trip, but you don't swap them out until you've been walking in them for a whole year. Developers often let these mistakes sit for a long time before cleaning them up.

Why Should You Care?

This matters because:

Bloat: If you keep "Construction Hammers" in your "Final Castle" bag, your castle becomes heavier and slower than it needs to be.
Security: If you leave a tool in the wrong bag, hackers might find a way in through that tool.
Confusion: If you tell a guest to bring a chair, but then you buy one, the guest might get confused and bring two, or none at all.

The Takeaway

Software isn't a static building; it's a living, breathing organism that constantly edits its own memory. Developers are constantly looking at their lists and saying, "Wait, that doesn't belong here," or "Actually, we need that back."

The authors suggest that our tools (the software that helps us build) are too dumb. They only look at the current list. They need to get smarter and say, "Hey, you moved this tool three times in the last year. Are you sure it belongs here?"

In short: Managing software dependencies is less like building a house and more like constantly reorganizing a messy garage, realizing you've been storing your winter coats in the summer shed for a year, and finally moving them to the right place.

1. Problem Statement

Modern JavaScript projects rely heavily on third-party dependencies declared in package.json. While extensive research exists on dependency versioning (updates) and security, there is a significant gap in understanding how developers manage the roles of these dependencies over time.

In JavaScript, dependencies are assigned specific roles:

Core (dependencies): Required at runtime.
Dev (devDependencies): Required only for development/build.
Peer (peerDependencies): Required at runtime but expected to be provided by the consumer.

The Problem: These role declarations are often not static. Developers frequently misassign roles initially or discover that a dependency's actual usage changes as the project evolves. This leads to dependency reclassification: the removal of a dependency or the reassignment of its role (e.g., moving a build tool from dependencies to devDependencies). Current tools and package managers do not effectively track or warn about these role shifts, potentially leading to bloated production footprints, increased attack surfaces, and installation errors.

2. Methodology

The authors conducted the first large-scale longitudinal study of dependency reclassification across the JavaScript ecosystem.

Dataset:
- Source: GitHub repositories retrieved via the GitHub Search Engine (GHS).
- Filtering: From 261,739 repositories, they filtered for active JavaScript projects with valid package.json files, at least 10 commits, and at least one commit after 2020.
- Final Corpus: 33,087 projects with active dependency maintenance.
- Scope: Analysis of 1,504,472 commits modifying package.json, identifying 291,741 specific reclassification events.
Detection & Taxonomy:
- Event Definition: A reclassification event is any change in a dependency's declared role after its initial introduction. This includes role switches (e.g., Core $\to$ Dev), removals (Role $\to$ Void), and reintroductions (Void $\to$ Role).
- Exclusions: Version-only updates, initial introductions, and cross-file relocations in monorepos were excluded.
- Practice Taxonomy: The authors aggregated individual events into sequences to define recurring maintenance patterns:
  1. Removal Practices: One-step removal, Multi-step removal (reassignment before removal), and Removal Reversion (removal followed by reintroduction).
  2. Reassignment Practices: Role reassignment (e.g., Core $\to$ Dev) and Role Oscillation (moving away from a role and returning to it).
Research Questions (RQs):
- RQ1: Prevalence of reclassification.
- RQ2: Patterns of dependency removal.
- RQ3: Patterns of role reassignment.
- RQ4: Temporal duration of these practices.

3. Key Contributions

First Large-Scale Longitudinal Study: The first empirical investigation into dependency reclassification (not just versioning) across 33k+ JavaScript projects.
Empirical Taxonomy: A structured classification of reclassification practices (Removal vs. Reassignment, One-step vs. Multi-step, Reversion vs. Oscillation).
Data Release: Publicly available dataset and replication materials to support future research.
Practical Implications: Concrete recommendations for dependency tools, package managers, and researchers regarding role-aware management.

4. Key Results

RQ1: Prevalence

High Prevalence: 79.1% of the studied projects reclassified at least one dependency.
Removal Dominance: 97.2% of reclassifying projects removed dependencies at some point.
Reassignment: 38.0% of projects performed role reassignments (e.g., Core $\to$ Dev).
Instability: 33.1% of projects reintroduced removed dependencies later, and 11.2% exhibited role oscillation (switching roles and returning).

RQ2: Removal Patterns

Batching: One-step removals are often performed in batches. 61.9% of Core and 79.6% of Dev removals occur in commits deleting $\ge$ 2 dependencies.
Partial Reversion: When batch removals are reversed, developers often reintroduce only a subset of the removed dependencies (62% of cases), suggesting an iterative correction process.
Multi-step Removal: In ~80% of multi-step removals, a dependency is reassigned to an intermediate role (e.g., Core $\to$ Dev) before final deletion, indicating that role correction often precedes removal.

RQ3: Reassignment Patterns

Core $\leftrightarrow$ Dev: The most common reassignment.
- Core $\to$ Dev: Often involves build tools (Babel, Webpack) and linters (ESLint) being moved out of production to reduce bloat.
- Dev $\to$ Core: Occurs when build tools are needed in the production runtime environment.
Peer Dependencies: Frequently reassigned to Core or Dev. This suggests that relying on consumers to provide dependencies is often unstable, leading projects to take ownership of these dependencies to simplify installation.
Oscillation: Dependencies often undergo "trial and error," moving between roles multiple times before settling (or being removed).

RQ4: Timing

Long Duration: Reclassification is a slow process. The median duration for a reclassification practice is 408 days.
One-Step: Even single-step changes take months (e.g., median 293 days for Core removal).
Multi-Step: These involve distinct temporal phases. For example, a role reassignment might happen early (e.g., 76 days), but the final deletion occurs much later (e.g., 571 days later).
Oscillation: The shortest duration, typically occurring within a year, often triggered by immediate deployment issues.

5. Significance and Implications

For Tooling: Current tools only show the current state of package.json. Tools need to provide historical context (e.g., "This dependency was moved from Core to Dev 2 years ago") and batch impact analysis to help developers verify large-scale cleanups before merging.
For Package Managers (npm/yarn):
- Warnings: Package managers should warn when "Dev" tools are added to "Core" dependencies, as this often persists for long periods before correction.
- Peer Guidance: Since Peer dependencies are frequently reassigned to Core, managers should provide data-driven guidance on whether a dependency should be consumer-provided or project-managed.
For Research:
- Shift focus from static dependency lists to dynamic role evolution.
- Investigate why misassignments occur (e.g., ambiguity in build vs. runtime usage) using qualitative analysis of commit messages and issues.
- Develop models to predict role suitability based on usage patterns.

Conclusion

The paper demonstrates that dependency management is not just about updating versions; it is a continuous process of role refinement. Developers frequently correct initial misassignments, remove unused dependencies, and oscillate between roles over periods of months or years. This study highlights a critical gap in current tooling and suggests that future dependency management systems must be "role-aware" to support developers in maintaining lean, secure, and correctly configured production environments.