9/5/2023 0 Comments Package json caretWe want frequent changes to our own libraries, which we code-review and vet all changes on, to be able to be rolled out to the many front-end apps easily without code reviews or a bunch of process and blockers. As our # of front-ends grows, so does the pain of rolling out updates. Alternatively, because we use a micro-services-front-end consisting of 25+ *-web front-end repos, pinning the versions of 1st party libraries would mean each change would require 25+ package.json changes, branches, PR reviews, and deploys.Note: We make a point that our npm audit has zero Major, Minor, Trivial issues 100% of the time. We only upgrade if there's a feature/bugfix we need, or if there's a known security vulnerability. Most of the time, the risk of making changes is not worth the reward of whatever they add. We want to vet that new code and make sure it's bug free and tested before we pull it into our apps. We are not ok with our 3rd party libraries getting updated whenever their developers release new code.In our current setup we pin all 3rd party library versions ( react: 16.8.6), and we use semver caret versions for our own dependencies ( ^2.3.3). We are have tried all of the industry-standard tools like package-lock of NPM, yarn, shrinkwrap, etc appropriately, but they still have their shortcomings in a micro-services world and we’re feeling the pain. TLDR Our web product is made up of 25+ different micro-frontends. The problems we’re facing are unique to Aver’s situation in that we maintain a micro-services-front-end. Maintaining dependencies of our front-end apps has been a struggle.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |