Keep upgrading your dependencies like npm packages. If you doing it in a short cadence then fixing eventual issues is much easier than trying to upgrade and fix issues after a very long time.
Review your dependencies
Keep reviewing your dependencies 1-2 times per year. There is a chance that some of them could be removed or replaced with other solutions.
Before including dependencies
Determine dependency size
If you use npm packages use bundlephobia service to check the package size. Example for @sitelintcode/optimize-image-on-the-client-side package. However, double-check also on the original repository and check the distributable package size. There might be some differences between bundlephobia service calculation and real distributable package size.
Determine last publish date
The last date change determines the freshness of the packages. At least, at some level of degree. You better avoid including very old packages that may not be up to date.
Determine how long it takes to resolve the issue
When you find a bug, it’s good practice to report it to the author. However, check the list of previously reported bugs and feature requests and determine how long it takes from the date of request to the date of the published solution. You don’t want to wait a couple of years for the issue resolution.
Maintenance
How many items (bugs or requests for new features) are submitted? How many have been solved? How many have not been resolved? What is the date of the oldest unsolved problem? This will allow you to determine the average response to the questions asked, reported problems, or requests for new functionalities.
Determine if the problem can’t be solved with a few lines of code
Often, there are already built-in methods (e.g. Date, Intl.DateTimeFormat) that can greatly provide the solution to the problem. You don’t need to attach a 0.5MB package just to calculate what day of the week it was yesterday. Besides, writing code makes your experience stronger. Note that this doesn’t mean always writing the code on your own. Just evaluate possibilities and then decide whether to use an external solution or not to use.
The threshold for the maximum package size
Avoid increasing the threshold for the package size
Be disciplined and if the application size is exceeded, stop the work and look for a solution to reduce the application size. For example, look for a code that is no longer used. Or sometimes some dependencies are no longer used but are still part of the application.
Experiment with decreasing the threshold for the package size
It will trigger a reminder to review the app size.
Avoid submitting changes when you won’t be around
Don’t push changes if you won’t be around
Pushing changes to the development branch and leaving it without your support may lead to unexpected consequences. Other engineers may pull the changes and the whole build might be broken or working in unexpected ways. To avoid that we strongly recommend not pushing the changes till you’re not around to support in case of any failure.
Disable loading some dependencies while development
Disable loading some dependencies when you don’t need them locally
Sometimes it might be handy to disable loading some dependencies. For example, user traffic analytics or chat. That way your local app may load and work faster. This will make also your environment more clean as nothing from disabled dependencies impacts your app. It’s easier then to spot the root cause of potential issues.
However, use that approach with cautious because you need at the end to test your features within all available dependencies.
Fix reported errors and warning
Keep console error and warning clean
Ensure all reported messages in console errors and warnings are in your software development review loop and processed as soon as possible. In most cases, console.error is a sign that something’s gone wrong. While console.warn tends to be ignored due to its nature, we recommend not ignoring the warnings, but rather reviewing them and checking whether they are understandable and whether they are up-to-date.
What’s slowing down your software development
Unclear steps to reproduce in bug report
When reporting the issue ensure the steps to reproduce are clear.
Testing
Keep test cases clear
Set test steps clearly so that the logic of expected behaviour can be determined from the specified steps, not from reading the code.
