Create a codemod - Part 1 - Why?
Royston Shufflebotham is a Front-end developer and architect at i2, in Cambridge, UK.
He got his first taste of coding in 1981, and really hasn't stopped since then, working his way through backend and frontend jobs in text matching, web & PKI infrastructure and crypto, finance, web server software, laboratory automation and investigative analysis, journeying through Quick Basic, Perl, TCL, C++ (several times), Delphi, C#, Java (several times) and JavaScript.
He appears to have finally settled down as a Front-end developer, preferring to work in React and TypeScript.
He also has a very unhealthy fondness for fiddling round with, or writing, developer tools and DevOps instead of writing real production code.
NOTE: This is Royston's personal blog.
If you fancy some legal nonsense, here is some:
Whilst the author does take some care to ensure the information presented here is accurate and useful, he makes no claims or representations as to accuracy, completeness, correctness, suitability or validity of any information on this site, and refuses to be liable for any errors, omissions, or delays in this information or any losses, injuries or damages arising from its display or use. All information is provided on an as-is basis with no warranties, and confers no rights. There is no warranty that the site is free of viruses or other harmful components. It is the reader's responsibility to verify their own facts and to secure their own systems.
The views, thoughts and opinions expressed in this blog are those of the author only and do not necessarily reflect the official policy or position of any other agency, organization, employer or company, including, but not limited to, my employer.
These views are also subject to change, revision and rethinking at any time; please do not hold us to them in perpetuity.
Oh, and in case you're wondering, it's pronounced ˈrɔɪstən ˈʃʌfl̩boθəm (or ˈrɔɪstən ˈʃʌfl̩bəʊθəm if it's easier for you)(guide). Yeah, I'm definitely helping there...
So, you've got a nice big codebase full of code you're reasonably happy with.
Great!
But, of course, it's rotting.
If you've been coding with JavaScript (or most other languages, to be honest) for any amount of time, you'll have noticed that habits and best practices change over time. What was a cool way to do something six months ago isn't quite so cool any more:
- maybe there's some new syntax in JS or a new Babel plugin
- maybe there's a new library that makes it easier
- maybe one of your libraries or frameworks has introduced a cool new feature
What's stopping you adopting those new features or practices? Most likely it's your existing codebase.
Maybe you want to turn on a new eslint rule across your codebase, but you currently have a lot of violations. You could mark them all as excluded so that you can apply it to new code, but that old code simply isn't going to fix itself.
You want to improve your codebase, but as you get more and more of it, it feels harder and harder to change it. So it starts to fall behind. That's the rot.
Codemod it!
A codemod (code mod-ification) is a tool that automatically applies a set of changes to an entire codebase. So that little thing you'd like to add to your codebase that would make everything better suddenly becomes something you could actually consider.
Should I write a codemod or just make the changes by hand?
This is a great question, and the excellent XKCD comic has addressed this on... several... occasions.
It's a simple equation:
How long will it take you to develop the codemod? (Let's call that time
D.)Note that, like any code, getting something simple and basic working won't take very long, but making it cope with all the edge cases once it hits the reality of your codebase might increase this time.
How long will it take to make the changes manually, without the codemod? (Let's call that time
M.)Note that if this is an error-prone modification to make, the cost will be higher.
Is M > D? If so, the codemod will be worthwhile. If not, it's probably not going to be worth your time.
Writing a codemod might feel cool, but if you're only going to run it once, you either need to be able to write codemods quickly or your codebase had better be large enough - or you need to share your codemod with enough other people - to make it worthwhile.
So, as you can tell, the more efficiently you can write a codemod, the more value you'll get out of writing codemods.
That's why I've written this series of articles.
Summary
We've reviewed what a codemod is, why you might (or might not) want to write one. In part 2, we'll start to look into what they involve. Until next time!
