Um estudo empírico sobre breaking changes no ecossistema do NPM

• Autor(a) principal: Venturini, Daniel
• Data de Publicação: 2020
• Tipo de documento: Trabalho de conclusão de curso
• Idioma: por
• Título da fonte: Repositório Institucional da UTFPR (da Universidade Tecnológica Federal do Paraná (RIUT))
• Texto Completo: http://repositorio.utfpr.edu.br/jspui/handle/1/26106
• topic: JavaScript (Linguagem de programação de computador); Software - Desenvolvimento; Gerenciamento de configurações de software; JavaScript (Computer program language); Computer software - Development; Software configuration management; CNPQ::CIENCIAS EXATAS E DA TERRA::CIENCIA DA COMPUTACAO

Context: Packages hosted on npm create a dependency network, where client packages use some recource from provider packages. Occasionally, providers introduce breaking changes, which are changes that may cause defects on clients. These changes should be only introduced in major level of Semantic Versioning, but when introduced in minor or patch levels, these may cause issues on clients. Objective: This work proposes a study about breaking changes in minor and patch levels on npm . Our objectives are: (RQ1) to measure the breaking change occurrence, (RQ2) to show the most common breaking change types, and (RQ3) to analyze how clients recover themselves. Method: From a sample of clients from npm , we restored the releases and installed the latest version of providers that the client accepted in the release timestamp. Following, we executed the npm install/test scripts. All releases that raised an error were analyzed, and the client and providers code and repositories was verified to check whether the error was raised by a provider, characterizing a breaking change. Results: (RQ1) Altogether, 13.9% of client releases are impacted by breaking changes, which have happened year after year and 54.9% of provider releases with breaking changes have more commits than their other releases. (RQ2) The majority of breaking changes are fixed by providers in patch levels and are documented in 78.1% of cases, mainly on issues, causing the fix to be 3.3 time faster. (RQ3) While indirect providers are the ones that introduces the majority of breaking changes, clients fix these in 39.1% of cases and they prefer to do an upgrade on the provider’s version without changing the range. Conclusions: Breaking changes do really happen in minor and patch releases. Previous studies focused only on API breaking changes, while this study used clients’ tests to find any types of breaking changes. We presented several suggestions to developers to improve their interaction with the npm ecosystem.