12/31/2023 0 Comments Package.json caret meaning![]() there might be a space of 30 minutes where your package specifies foobar 1.1.0 and the other one specifies 1.1.1 and your joint downstream users end up with a duplicate. According to Rhys Arkins (the author of Renovate), even if both authors are using a service like Renovate this is still not a good idea:Įven if both projects use a service like Renovate to keep their pinned dependencies up to date with the very latest versions, it's still not a good idea - there will always be times when one package has updated/released before the other one, and they will be out of sync. If another package pinned a different version you will end up with both and your bundle size will increase (and thus the loading times). If you are publishing you own library to npm, and you decide to pin the dependencies then the incredibly narrow range of versions will almost certainly lead to duplicates in node_module. The biggest downside of pinning concerns libraries development. Such tools will constantly check for dependency updates and take care of automatically PR your repo. Fortunately there are several tools you can use to automate the process, like Renovate. You may be asking who is going to PR the repo every time a new dependency gets released, because this is a very tedious task to be done manually. The whole process can be automated and it's usually very quick. Depending on your answer it will divide the leftmost or rightmost interval and iterate the process until the guilty commit is detected. Instead of doing it manually a git bisect allows you to specify a good commit and a bad commit, then it will pick up a commit in the middle and ask you if it's good or bad. Git bisecting is a quick way to roll back to previous commits and find out which one introduced the regression. Nevertheless pinning still has a big advantage even when the failure is not caught in time: instead of randomly looking for which dependency broke your code, you will be able to bisect the issue very quickly. Truth is that tests are not perfect either and chances are you probably didn't read the release notes looking for breaking changes before merging a green-light PR. So you will know exactly which dependency is going to break your app before that happens. With pinning, you will have to make a PR to update your dependencies and thus get some feedback from the automated tests. Since multiple dependencies can be updated at once when that happens you will have to manually check which one to blame and then you will be forced to pin it to fix the issue. Unfortunately semantic versioning is far from being infallible and breakage might occur. The theory behind that is that semantic versioning should protect us against breaking chances, while still getting the security fixes. This is done because we want to get security fixes as fast as possible. The main reason is to automatically get updates every time we run npm install (assuming you're not using a lock file, more on that later). Why did package managers default to semver? Package managers like npm or yarn use semver ranges by default, which basically allows you to install a “range” of versions instead of a specific one.īy freezing the dependencies we want to achieve repeatable deployment and make sure that every developer is testing on the very same codebase. With the term pinning we are referring to the practice of making explicit the version of the libraries your application is depending on. What is pinning and why is it so important? Had we taken a closer look at it, we would have noticed the update and tested the depending features.Looking for experts? We offer consulting and trainings.Įxplore our services and get in touch. We often don't look carefully at that file, since it is generated, and the GitHub pull request feature hides it by default. Don't skip reviewing changes to package-lock.json. Had we specified exact versions, we would have noticed the change in package.json and more thoroughly tested that feature.Īside from specifing exact versions and shoring up or test coverage, we learned another valuable lesson. ![]() Needless to say, a customer-facing defect slipped into production. Our QA team (which unfortunately where I work is a totally separate team that we have little visibility into) also didn't have good coverage around this issue. Since we didn't notice the update, we didn't test carefully the code paths where the package was used. Since the new version still satisfied the package's range, the package.json file did not reflect the update. npm audit fix updated a minor version of a dependency automatically. We run npm audit every quarter and address anything that pops up. Our team recently got bit by range versions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |