One of the joys of Perl is the rich community support that it has enjoyed over the years. Even today when other languages are surging in popularity, the Perl community is still going strong.
One of the things I ask myself every Preptember is "what will I do for Hacktoberfest?" This year, I decided that I wanted to spread the love out a little bit. In addition to banging away on some of my own projects, I also wanted to modernize at least one older CPAN module, and I also wanted to see if I could help out with one of the sponsors' issues.
Data::JavaScript is a module that I used waaaay back when. It hasn't had much love lately, and in light of JSON, many folks kinda view it as irrelevant. Many of its use cases do indeed seem duplicative of JSON, and there's already excellent JSON support. However, there are some folks still using this module, and with Perl 7 coming out it really needed a little bit of TLC. What TLC did it need? Well, I made a list!
1. Implement best practices
It needed to be updated to more modern Perl best Practices. In Perl, we have warnings, errors, but we also have Perl::Critic. I ran perlcritic and started hammering out issues until the issues stopped coming. Then I ran tests to make sure I didn't break anything.
2. Configure CI
It needs CI, with coveralls, that way I can make sure I don't accidentally forget to update tests. For this, I chose GitHub actions, as most of the other CI providers don't really support Perl terribly well (most of them never really did). I got this working, and now I can see that Coveralls shows I have 90% test coverage, which is pretty good. This level of code coverage should help me identify any breakages.
3. Review dependencies
Normally, you would review all of the dependencies in use. It's super important to make sure that a security review is performed for those dependencies, as out-of-date dependencies are one of the largest threat vectors for a piece of code.
Luckily for me, this module is almost entirely self-contained. I added a few dependencies as part of implementing CI and Perl Best Practices, but there were none when I started (and the ones I added are really common).
4. Develop a roadmap
Once you've finished dusting off the code in the prior steps, it's super important to develop a roadmap for the application. Since no application is never really finished until it's fully deprecated, you really want to spend some time coming up with functional improvements for the application. I like to use GitHub Issues for these, as it makes it clear to other people that I'm thinking about the module when they're considering whether or not they want to use it.
Conclusion
I think this is a pretty good pattern for reviving most legacy code. If you've got thoughts, I'd be happy to read them.
If you'd like to contribute to any of the modules I maintain, please review:
They're both opted in to Hacktoberfest.
Oldest comments (0)