- #93
- #92
- #91
- #90
- #89
- #88
- #87
- #86
- #85
- #84
- #83
- #82
- #81
- #80
- #79
- #78
- #77
- #76
- #75
- #74
- #73
- #72
- #71
- #70
- #69
- #68
- #67
- #66
- #65
- #64
- #63
- #62
- #61
- #60
- #59
- #58
- #57
- #56
- #55
- #54
- #53
- #52
- #51
- #50
- #49
- #48
- #47
- #46
- #45
- #44
- #43
- #42
- #41
- #40
- #39
- #38
- #37
- #36
- #35
- #34
Why Keep Package Versions Updated?
We always put upgrade maintenance at the lowest importance level, which is a reasonable decision. After all, the core goal of product development is to meet user needs rather than to make developers happy. However, the relationship between the two is complementary. When technology stagnates, future upgrades will incur higher costs and face greater challenges.
- Versions become increasingly outdated until they can no longer be modified…
- Fewer and fewer people want to understand old technologies, and the development community gradually fade away…
- Security issues…
Recently, I specifically added a CI for regularly automatically updating package versions to the company’s new architecture project because the neglect of updates in old projects has caused a lot of pain. This way, at least the team is constantly reminded of this matter.
Developers should keep up with the times. This does not contradict the long-term goals of the product. Try to pay attention to this point and use some tools to solve this problem! Such as GitHub Dependabot and Renovate.
I heard that the Angular community has a good automated update solution (ng update), and Nx has also launched nx migrate to manage Monorepo architecture. More records can be found in Nx migrate to solve upgrade problem
- #33
- #32
- #31
- #30
- #29
- #28
- #27
- #26
- #25
- #24
- #23
- #22
- #21
- #20
- #19
- #18
- #17
- #16
- #15
- #14
- #13
- #12
- #11
- #10
- #9
- #8
- #7
- #6
- #5
- #4
- #3
- #2
- #1