Contractor Chronicles 3

This week was spent working on the maintenance of an existing Angular application, which has been recently updated to Angular 15.

The upgrade was fairly easy, Angular and the Angular CLI make upgrading between versions so easy. It was something I missed when working with Vue. I know that the Vue CLI does have a way of upgrading, but with the Angular CLI being a bit more mature I find the upgrade process far more straightforward.

I also spent a bit of time watching a live Twitch stream of Josh Goldberg (he’s a full-time open-source developer, who specialises in Typescript), in this stream he was reviewing a pull request to a Typescript project Typescript-ESLint, which is a library for adding linting for Typescript to ESLint.

Linting is a way of checking for bad practices in your code, it is a set of rules for JavaScript. This Typescript-ESLint project adds rules for Typescript to ESLint.

As I mentioned in earlier Contractor Chronicles I said I was looking for an open-source Typescript project to get involved in and I started to look more and more into this Typescript ESLint project and get involved in the project.

So this week I spent a bit more time looking at this project and after watching the Twitch Stream of Josh’s I’m starting to understand how the project works and hopefully soon I can start contributing to the project.

Finally, I spent some time going through a plan for the rest of the year, breaking down some goals I have for the years into projects. Then using the PARA method to organise these projects and goals.

Using third party libraries are useful as long as they are maintained

There’s no denying that the open-source movement has helped move web development forward. Before open source was so prevalent on the web everything had to be built from scratch, there was no searching on NPM for a library that could help fix an issue you had or a framework to structure your application.
But one of the downsides I see with using third-party libraries in your application is if this library is no longer maintained or updated and your work relies heavily on this library it can easily become a maintenance nightmare.

I’ve worked on a few Angular apps now and many are using third-party libraries every time a new version of Angular is released I have to check if these libraries work with the latest version, which on the whole they do. But if one of these libraries is no longer maintained or worked on, then you are stuck with the choice of either not upgrading your Angular version (something I don’t recommend) or refactoring your code to remove this dependency (something I do recommend).

So when it comes to adding third-party libraries to our codebase we need to make a few decisions. First, is it regularly maintained? Checking the history of the library on GitHub can answer that. If there have been no updates within the last year I get worried. Second, if it is maintained how crucial is this library going to be in my application? If it’s core to how the app works how would I maintain the app if later this library is no longer updated? Will it break my application? Can I easily refactor my code to remove this dependency if I need to? These are all questions that need to be considered before just adding a library.

One tip I have used is if you are using a third-party library or component in your application to wrap it within your own library or component then use this ‘wrapper’ throughout your codebase. So if you need to remove the outdated component/library all you need to do is refactor your ‘wrapper’ to either use another third-party library/component or your own version.

Open source is fantastic, it provides so much but I think that in large-scale applications we need to be defensive in how we use open-source code. Third-party libraries are created by some excellent and hardworking developers, many of whom do this work on top of their own, so I think we should be thankful for their work, but just be aware of how much we are using these libraries.