Managing project dependencies is a key maintenance issue in software development. Developers need to choose an update strategy that allows them to receive important updates and fixes while protecting them from breaking changes. Semantic Versioning was proposed to address this dilemma, but many have opted for more restrictive or permissive alternatives. This empirical study explores the association between package characteristics and the dependency update strategy selected by its dependents to understand how developers select and change their update strategies. We study over 112,000 Node Package Manager (npm) packages and use 19 characteristics to build a prediction model that identifies the common dependency update strategy for each package. Our model achieves a minimum improvement of 72% over the baselines and is much better aligned with community decisions than the npm default strategy. We investigate how different package characteristics can influence the predicted update strategy and find that dependent count, age, and release status to be the highest influencing features. We complement the work with qualitative analyses of 160 packages to investigate the evolution of update strategies. While the common update strategy remains consistent for many packages, certain events such as the release of the 1.0.0 version or breaking changes influence the selected update strategy over time.

Dependency management in modern software development poses many challenges for developers who wish to stay up to date with the latest features and fixes whilst ensuring backwards compatibility. Project maintainers have opted for varied, and sometimes conflicting, approaches for maintaining their dependencies. Opting for unsuitable approaches can introduce bugs and vulnerabilities into the project, introduce breaking changes, cause extraneous installations, and reduce dependency understandability, making it harder for others to contribute effectively. In this paper, we empirically examine evidence of recurring dependency management issues (dependency smells). We look at the commit data for a dataset of 1,146 active JavaScript repositories to catalog, quantify and understand dependency smells. Through a series of surveys with practitioners, we identify and quantify seven dependency smells with varying degrees of popularity and investigate why they are introduced throughout project history. Our findings indicate that dependency smells are prevalent in JavaScript projects with two or more distinct smells appearing in 80 percent of the projects, but they generally infect a minority of a project’s dependencies. Our observations show that the number of dependency smells tend to increase over time. Practitioners agree that dependency smells bring about many problems including security threats, bugs, dependency breakage, runtime errors, and other maintenance issues. These smells are generally introduced as developers react to dependency misbehaviour and the shortcomings of thenpmecosystem.

Abstract Bad smells are bad practices in developing software. These poor solutions significantly influence the understandability and maintainability of source code. Therefore, bad smell detection plays a vital role in the refactoring, maintaining, and measuring the quality of large and complex software systems. Researchers believe that bad smells should be precisely identified and addressed. However, bad smell detection is complicated by issues such as informal and inconsistent specifications of bad smells and high false positive rates in the detection process, all of which affect the success rate in detection. In this paper, we present a new method to detect bad smells in code by addressing the aforementioned issues. Our proposed method is a multi‐step process using software quality metrics and refactoring opportunities. In this method, after obtaining the bad smell formal specifications based on software metrics, we utilize them to achieve a set of candidates for each bad smell. Afterwards, each of the instances will be examined and compared with the corresponding refactoring situations specified for that bad smell. This examination strikes out the false positives created in the previous step. The evaluation of this method on four open‐source systems demonstrates the improved effectiveness of bad smell detection in code.