Our Codemod

This time, we're going to write a codemod that rewrites array construction.

Let's say you've just inherited a large old JS codebase that contains lots of code like this:

var myArray = new Array(1, 2, 3);
var myOtherArray = new Array('x', 'y', 'z');

Note the explicit array constructor: new Array(). That's generally a pretty unnecessary thing to be doing (in those forms), and can actually be very confusing. We're going to write a codemod that changes those array construction calls into plain array syntax

i.e. to convert the above into:

var myArray = [1, 2, 3];
var myOtherArray = ['x', 'y', 'z'];

Aside

Array construction

A brief interlude for a quick pop quiz...

Do you know what new Array(5, 'b') does? You probably know, or can guess, that it creates a two-element array containing 5 and b. It's more simply written as [5, 'b'].

What about new Array(5)? Some readers may be surprised to hear that it doesn't create a one-element array; it creates a five-element array, initialized all as empty. Its equivalent is [,,,,,].

There are many JS developers who don't know about that one-argument special case, and it's easy to fall into it accidentally even if you do know (e.g. by removing the b element from the first example).

So, it's usually better to use the array syntax [5, 6] instead of explicit Array construction (new Array(5, 6)). The codemod we develop on this page will perform that change automatically across an entire codebase.

Building the codemod

We'll work through the development steps we listed last time.

1. Figure out what we want to change

We want to convert any calls that look like new Array('a', 'b') with or without parameters, into plain array literal syntax ['a', 'b']. The array literal will contain the arguments from the new Array call as its contents, even if they're complex expressions.

2. Figure out what we don't want to change

• It's important that we don't modify any one-parameter new Array(5) calls. new Array(5) is absolutely not replaceable by [5].
• We don't want to modify the construction of any other type, only Array

Aside

Actually, things are a little more nuanced than this. The special case Array construction behaviour only happens when the single parameter to new Array() is a number.

If we know that a single parameter isn't a number (e.g. new Array('a string')), or if we had access to type information from, for instance, a TypeScript parser, we could be smarter, but we'll leave those as 'extra credit' exercises.

3. Construct a testbed

We'll develop the testbed shortly, but first, let's look at what happens if our testbed is a little... lacking.

It's very easy, when first writing codemods, to rush into targeting a very precise piece of syntax. In our case, we want to target

new Array('a')`

so let's look at the AST for exactly that. It's:

It would be easy to conclude, from that code and diagram that we should be looking for an ExpressionStatement containing a NewExpression with the appropriate callee.

Let's look at a very similar piece of code:

const x = new Array(3, 4);

The AST for that is

Notice that there's no ExpressionStatement in that tree.

It turns out that the original ExpressionStatement was only there because the new Array code was at the root of our source file. It's actually only the NewExpression that we're interested in. The ExpressionStatement was a red herring.

How do we avoid making this mistake?

"Use it in a sentence"

Imagine you're in an elementary spelling bee competition and you're asked to spell the word 'pair'. Of course, in such a competition you only hear the word spoken, so you're not sure whether they said 'pair' or 'pear' (or 'pare' or 'pere' )?

You can't ask them to spell the word to clarify, so what do you do? You ask the caller to use the word in a sentence. If they respond with "I'm going to peer through the window.", you know you completely mis-heard originally, but you now know what the word is.

Similarly, if we're trying to figure out the AST structure for a piece of code, we can easily make bad assumptions if we only look at one example with no context.

So, when collecting interesting cases to match, try to 'use them in a sentence' to get a more realistic AST. In fact, use them in multiple different ways that are close to how your actual code uses them.

We'll create a set of sample code that illustrates our positive and negative cases and doesn't simply leave the new Array at the top of the source file:

// Empty array case
// -> const x = [];
const x = new Array();

// Complex arguments case
// -> somefunc(['a', 3 + 4]);
somefunc(new Array('a', 3 + 4));

// Single argument case; leave it alone
somefunc(new Array(5));

// Not Array case; leave it alone
somefunc(new NotArray('a', 5));

That includes things we want to change and similar things we don't want to change. Good!

4. Build a target profile

Follow this link to AST Explorer and it'll take you directly to a pre-configured AST Explorer with that code in it.

The configuration is simply to do 'JavaScript parsing' and to use 'recast' with the 'esprima' parser, and be set up for JSCodeShift transformations.

It also includes the same skeleton codemod from last time ready for us to develop, namely:

export default function transformer(file, api) {
  const j = api.jscodeshift;

  return j(file.source)
    .find(j.Identifier)
    .forEach(path => path.node.name = 'Foo')
    .toSource();
}

Explore the AST

Click around the code and get a feel for the syntax tree.

You'll discover that we're looking for NewExpression nodes where the callee is an Identifier with a name of Array:

5. Fire tracer bullets

Let's update our .find() call to target those nodes.

We'll also need to tweak our .forEach(): we were previously targeting Identifiers and could simply set their name property. We're now targeting NewExpressions and they don't have name property; it's their callee that does.

export default function transformer(file, api) {
  const j = api.jscodeshift;
  return j(file.source)
    .find(j.NewExpression, { callee: { type: 'Identifier', name: 'Array' } })
    .forEach(path => path.node.callee.name = 'Foo')
    .toSource();
}

That's an excellent start. We're targeting all the new Array calls:

// Empty array case
// -> const x = [];
const x = Foo;

// Complex arguments case
// -> somefunc(['a', 3 + 4]);
somefunc(Foo);

// Single argument case; leave it alone
somefunc(Foo);

// Not Array case; leave it alone
somefunc(new NotArray('a', 5));

We're still incorrectly targeting the one-argument new Array(5) call. Can we extend the find call to locate that? Sadly not. If we wanted to look for a NewExpression that had an arguments property with a length equal to 1, we could do it, but we want only those with a length not equal to 1.

It's time to introduce another JSCodeShift function that gives us more power: .filter(). But to make sense of that, we firstly need to introduce the concept of Paths.

Paths

Let's take a look at a simple bit of code and its syntax tree:

new Array(3, 'q')

The NewExpression AST node has a callee property which points at an Identifier (with a name of Array). It also has an arguments property, but this doesn't point at an AST node object; it points at an array object which contains some nodes.

When processing ASTs we often discover candidate target nodes and want to 'walk around the tree a bit' to confirm that we've found the correct pattern. But navigating around trees like this can be very difficult:

• There are no 'parent' pointers from a node to its parent.
• For nodes such as the NumericLiteral and the StringLiteral, what is their parent anyway? Is it the NewExpression or the containing array?
• Even if there was a 'parent' pointer, we often want to know which property we would come through from parent to child (e.g. left or right side of a + operator?), and a simple 'parent' pointer wouldn't provide that.
• It's tricky to inspect all of a node's child nodes (e.g. to recurse through a tree): you'd have to examine all the properties and deal with any arrays you came across. Examining the properties safely (without tripping over internal implementation properties, potentially triggering infinite loops) requires knowledge of the properties available on each node type.

This is where Paths come in. Path objects are a feature of the recast library, which JSCodeShift uses.

Recast builds a tree of Path objects parallel to, and pointing at, the tree of AST nodes:

Amongst the properties on a Path object are:

• value: the corresponding entry in the syntax tree. Note that Path objects don't always point at syntax _Node_s. Path objects are also created for intermediate containers in the syntax tree, such as arrays, in which case the value property would point at the array.
• parentPath (not shown on the above diagram, for simplicity): this enables us to walk up the tree
• name: the 'property' (or numeric index for array Path objects) that was traversed when moving from parent Path object to child Path object
• node: the containing syntax tree node. That is, if a Path object's value property is pointing to an array for the arguments property of a syntax tree node, the node property will point at the syntax tree node itself

Filtering

When we work with a chain of commands in JSCodeShift (e.g. .find(j.Identifier).forEach(...)), the chain is actually operating on a collection of Path objects, not simply nodes.

In our particular case, we have found all the NewExpression syntax tree nodes, and are manipulating the Path objects that point at them. We want to keep only those Path objects whose NewExpressions have an argument count !== 1.

So we add a new .filter call as follows:

export default function transformer(file, api) {
  const j = api.jscodeshift;

  return j(file.source)
    .find(j.NewExpression, { callee: { type: 'Identifier', name: 'Array' } })
    .filter(path => path.node.arguments.length !== 1)
    .forEach(path => path.node.callee.name = 'Foo')
    .toSource();
}

The result is

// Convert this to
// const x = [];
const x = Foo;

// Leave this alone
somefunc(new Array(5));

// Convert this to
// somefunc(['a', 5]);
somefunc(Foo);

// Leave this alone
somefunc(new NotArray('a', 5));

The difference this time is that, as we'd hoped, the single-argument new Array(5) call is now left alone.

That's taken care of all the 'negative' cases that we don't want to change. We now need to replace the array with something more useful than merely 'Foo'.

6. Apply changes

Last time our codemod didn't do very much: it just changed the name of an existing Identifier. This time, we want to replace, completely, a NewExpression with an array.

Let's start by replacing them with an empty array, to keep things simple.

What does an array look like - what AST structure do we need to create? We can repeat the same exercise we went through to find the structure to target (remembering to "use it in a sentence").

We need to create an ArrayExpression node like this:

.replaceWith()

Thankfully, JSCodeShift provides a neat little function called .replaceWith(). It can be called on a collection of Paths, and it uses the navigation smarts that we outlined earlier to replace the Paths' nodes with ones we specify.

We're going to start by using .replaceWith() to replace all our target nodes with empty arrays. But how do we actually create those nodes?

JSCodeShift provides us with a whole suite of AST node factory functions.

AST Node Factories

By now, we're used to writing j.Identifier or j.NewExpression to indicate a type of node to search for. JSCodeShift provides a parallel set of functions, starting with lowercase letters, which construct nodes.

e.g. j.identifier('Foo') will create an Identifier with the name property set to 'Foo'.

In our case, we need to create an ArrayExpression, so we'll need to use j.arrayExpression(). Let's try it:

export default function transformer(file, api) {
  const j = api.jscodeshift;

  return j(file.source)
    .find(j.NewExpression, { callee: { type: 'Identifier', name: 'Array' } })
    .filter(path => path.node.arguments.length !== 1)
    .replaceWith(path => j.arrayExpression())
    .toSource();
}

Our output?

no value or default function given for field "elements" of ArrayExpression("elements": [Expression | SpreadElement | RestElement | null])

Uh oh. That's not good. We've obviously missed out a value for elements, whatever that is. We can get a clue by looking at the typing information in the j.arrayExpression() constructor:

It's expecting to be given an array of AST nodes for the array elements, but we didn't provide that.

Let's try again, providing an empty array of AST nodes:

export default function transformer(file, api) {
  const j = api.jscodeshift;

  return j(file.source)
    .find(j.NewExpression, { callee: { type: 'Identifier', name: 'Array' } })
    .filter(path => path.node.arguments.length !== 1)
    .replaceWith(j.arrayExpression([]))
    .toSource();
}

The result is

// Empty array case
// -> const x = [];
const x = [];

// Complex arguments case
// -> somefunc(['a', 3 + 4]);
somefunc([]);

// Single argument case; leave it alone
somefunc(new Array(5));

// Not Array case; leave it alone
somefunc(new NotArray('a', 5));

That's looking good. 3 of the 4 cases are now correct. We just need to fix the case where there are actually array parameters.

.replaceWith(j.arrayExpression([])) replaces all of the found nodes with the same expression. We want to examine each Path being replaced, and create an appropriate ArrayExpression for each Path.

The good news is that .replaceWith also accepts a transformation function which is expected to transform a Path object into a replacement expression. We want to transform a NewExpression of a series of array parameters into a literal array containing those same parameters.

Moving nodes around

Of course, we don't want to replace new Array(1, 2) with []. We want to replace it with [1, 2]. How do we construct all the correct array parameters? They could be anything, not just simple numbers.

Well, the good news is that we already have them. The arguments property to the NewExpression already contains exactly the nodes that we need.

Our transformation ends up being surprisingly simple: instead of creating a new ArrayExpression with an empty array of AST nodes, we reuse the AST nodes that were the arguments to the NewExpression:

export default function transformer(file, api) {
  const j = api.jscodeshift;

  return j(file.source)
    .find(j.NewExpression, { callee: { type: 'Identifier', name: 'Array' } })
    .filter(path => path.node.arguments.length !== 1)
    .replaceWith(path => j.arrayExpression(path.node.arguments))
    .toSource();
}

The result is our final correct desired output:

// Empty array case
// -> const x = [];
const x = [];

// Complex arguments case
// -> somefunc(['a', 3 + 4]);
somefunc(['a', 3 + 4]);

// Single argument case; leave it alone
somefunc(new Array(5));

// Not Array case; leave it alone
somefunc(new NotArray('a', 5));

Hooray!

Summary

We developed our understanding of codemods quite a bit this time. You should now have some familiarity with

• the Path object tree
• .find()ing and .filter()ing Path collections
• creating replacement AST trees using AST node factory functions such as j.identifier()

We also discussed why it's a good idea to 'use it in a sentence' when trying to understand an AST tree.

Next time, we'll talk about Scopes.

There's quite a bit to get through in this part: we're going to examine an AST and construct a complete - albeit simple - codemod, little-by-little.

Our Codemod

To keep this particular article at a reasonable length, we'll develop a very simple codemod. It'll simply rename a method in all JavaScript classes it sees. Specifically, it'll rename componentWillUpdate to UNSAFE_componentWillUpdate. (This change forms part of a Codemod for React but you don't need to know anything about React to follow this tutorial.)

Writing a Codemod

I've found this set of steps handy when developing codemods. If you don't do these things you can easily develop a codemod that changes the wrong code or changes the right code in the wrong way. The TL;DR is "think before you code, and have some tests".

1. Figure out what we want to change
   • Ensure you understand precisely what structures you want the codemod to change, and precisely what you want it to change those things into.
2. Figure out what we don't want to change
   • Do you always want to make the change, or only when you're extending a particular class?
   • Do you always want to make the change, or only when there aren't any parameters?
   • Find structures similar to what you think you want to target and decide if you want those to change too
3. Construct a 'test bed'
   • Develop one or more 'test' files containing examples of positive (things you do want to change) and negative (things you don't want to change) sample code
4. Build a target profile
   • Identify the AST structures you want to change and construct
5. Fire tracer bullets
   • Write codemod code that targets the structure you're hoping to reach, and makes a tiny change there. Don't attempt to make the full final change straight away. Focus initially on targeting.
   • You may need to evolve your testbed as you do this
6. Apply changes
   • Now that you're targeting the correct nodes, write codemod code that makes the desired changes
7. Use the codemod
   • And be sure to check the output for unexpected changes!
8. Evaluate
   • Was it easier/quicker/better than making the changes by hand?

Let's work through those steps for our codemod:

1. Figure out what we want to change

That's easy. We want to find all class methods called componentWillUpdate and rename them to UNSAFE_componentWillUpdate. We don't need to change structure; we're just changing the name of an identifier.

2. Figure out what we don't want to change

Let's think about things similar to what we want to change, to identify related things we don't want to change.

A convenient way to do this is to take the thing we want to target and create variants of it, changing one thing at a time:

• Our start point is that we want to change methods called componentWillUpdate.
• We don't want to change methods that aren't called componentWillUpdate.
• We don't want to change all functions that are called componentWillUpdate; only class methods.
• We don't want to change static class functions that are called componentWillUpdate; only instance methods.
• We only want to change the name of the componentWillUpdate method. None of its contents should change.
• Do we always want to change methods called componentWillUpdate? If we were sharing this codemod publicly and therefore wanted to be super-careful, we should probably only change that method if it's on a class extending React's Component class, but let's just assume for the sake of this tutorial that we don't need to worry about that because we happen to know there are no uses of componentWillUpdate outside of our React components.

3. Construct a testbed

We now write some sample code to illustrate all the above positive and negative matches:

class Class1 {
  // This should be renamed
  componentWillUpdate() {
    // This code should not be lost
    return false;
  }

  // This should not be renamed
  notComponentWillUpdate() {
  }
}

// This should not be renamed
function componentWillUpdate() {
}

class Class2 {
  // This should not be renamed
  static componentWillUpdate() {
  }
}

As we develop our codemod we'll run it against the above code to gain confidence that it's changing the correct pieces of code.

4. Build a target profile

We need to identify the AST pattern we want to target. A particularly easy way to do this is to use the excellent AST Explorer web site to explore the AST.

JSCodeShift uses the recast library, so make sure that's the selected option.

Here is a link to AST Explorer with the above code already entered, and the correct options selected: https://astexplorer.net/#/gist/4ba8eac986f73baf39c5c9683af03b93/10917053e0e1b9b41cc3dd9b806f0cec69d9ac00

Go take a look at that. I'll wait. Make sure you click around the sample code (on the left) and examine the appropriate parts of the syntax tree (on the right). Look to see what sorts of AST nodes we're going to be interested in.

After a little clicking around we can see that we're interested in MethodDefinition nodes whose key is an Identifier with a name of componentWillUpdate.

Aside

One area of difficulty when working with these ASTs is that different parsers produce slightly different AST structures. The esprima parser generates MethodDefinition nodes whereas the babylon7 parser calls them ClassMethods.

For this reason, it's vital to ensure you're using the exact same parser configuration in AST Explorer that you'll be using when running your codemod.

Note in particular that recast is merely a layer on top of a real parser, so when we use recast in AST Explorer, it's important to choose the appropriate parser from the recast settings.

5. Fire tracer bullets

This is where things get interesting.

At this point, we're actually going to create and run a real codemod. The neat thing is that we can do it directly inside AST Explorer.

Click the 'Transform' button in AST Explorer and select 'JSCodeShift'. The two-window display will change into a four-window display. The two new panes at the bottom are the codemod source (bottom-left) and the resulting output (bottom-right).

AST Explorer gives us a sample codemod that reverses all of the identifiers in the source. That sample is a little more complex than we need, so replace the codemod code with this simpler skeleton:

1. export default function transformer(file, api) {
2.   const j = api.jscodeshift;
3. 
4.   return j(file.source)
5.     .find(j.Identifier)
6.     .forEach(path => path.node.name = 'Foo')
7.     .toSource();
8. }

It's only 8 lines long but it is a complete codemod! Let's walk through it, line-by-line:

• 1: The codemod consists of a single exported function called with the current file and the JSCodeShift API.
• 2: We extract the jscodeshift helper from the API and call it j as we will be using it a lot.
• 4: Here we begin a multi-line chained operation passing objects from one function to another: we start by parsing the current file. JSCodeShift will return a wrapper around the file that allows us to perform sophisticated search and replace operations.
• 5: We search for anything of type Identifier. Note the uppercase I in j.Identifier: this references the type Identifier.
• 6: We tweak each (Identifier) node, changing its name to Foo. We'll cover the path business in detail in the next article, so for now, just focus on the fact that we can write path.node to get the node in question.
• 7: We regenerate the output code from our modified tree by calling .toSource().

If you look at the output pane you'll see that our code has been heavily transformed to:

class Foo {
  // This should be renamed
  Foo() {
    // This code should not be lost
    return false;
  }

  // This should not be renamed
  Foo() {
  }
}

// This should not be renamed
function Foo() {
}

class Foo {
  // This should not be renamed
  static Foo() {
  }
}

Every Identifier - every mention of x, somefunc, Array and NotArray - has been changed into Foo, as we said it should in the code.

That's not (of course) what we want from our final codemod, but it serves to show how powerful codemods are, and it provides a good basis for developing our codemod. It'll require remarkably few changes to turn that into our final codemod!

Target the correct thing

Firstly, we don't want to target all Identifiers. From our AST investigations earlier, we know we want to start by finding all the MethodDefinitions. Our tracer bullet will simply be to set the name of the method to Foo. That's achieved by setting the .name property of the method's .key property.

i.e.

1. export default function transformer(file, api) {
2.   const j = api.jscodeshift;
3. 
4.   return j(file.source)
5.     .find(j.MethodDefinition)
6.     .forEach(path => path.node.key.name = 'Foo')
7.     .toSource();
8. }

The output:

class Class1 {
  // This should be renamed
  Foo() {
    // This code should not be lost
    return false;
  }

  // This should not be renamed
  Foo() {
  }
}

// This should not be renamed
function componentWillUpdate() {
}

class Class2 {
  // This should not be renamed
  static Foo() {
  }
}

We're now renaming all methods on classes, and we're not renaming the classes or functions.

But we're still hitting methods we don't want: we're renaming methods whose name is not componentWillUpdate and we're renaming static methods.

Happily, the .find() method takes a second parameter that supports property-based filtering.

We only want to target:

• methods named componentWillUpdate. We're looking for methods whose key property is an object with a name property equal to componentWillUpdate.
• methods which are not static. We're looking for methods whose static property is false.

We adjust our .find() call as follows:

 1. export default function transformer(file, api) {
 2.   const j = api.jscodeshift;
 3. 
 4.   return j(file.source)
 5.     .find(j.MethodDefinition, {
 6.       key: { name: 'componentWillUpdate' },
 7.       static: false
 8.     })
 9.     .forEach(path => (path.node.key.name = "Foo"))
10.    .toSource();
11. }

which produces the transformed output:

class Class1 {
  // This should be renamed
  Foo() {
    // This code should not be lost
    return false;
  }

  // This should not be renamed
  notComponentWillUpdate() {
  }
}

// This should not be renamed
function componentWillUpdate() {
}

class Class2 {
  // This should not be renamed
  static componentWillUpdate() {
  }
}

That's perfect. We're now targeting exactly the one method we want to, and leaving everything else alone.

6. Apply changes

For this codemod, this bit's easy. We don't need any information from the existing node. We just want to set its name to UNSAFE_componentWillUpdate, which merely requires us to change from setting Foo to UNSAFE_componentWillUpdate:

 1. export default function transformer(file, api) {
 2.  const j = api.jscodeshift;
 3.
 4.  return j(file.source)
 5.    .find(j.MethodDefinition, {
 6.      key: { name: 'componentWillUpdate' },
 7.      static: false
 8.    })
 9.    .forEach(path => (path.node.key.name = "UNSAFE_componentWillUpdate"))
10.    .toSource();
11. }

So the output is now:

class Class1 {
  // This should be renamed
  UNSAFE_componentWillUpdate() {
    // This code should not be lost
    return false;
  }

  // This should not be renamed
  notComponentWillUpdate() {
  }
}

// This should not be renamed
function componentWillUpdate() {
}

class Class2 {
  // This should not be renamed
  static componentWillUpdate() {
  }
}

That looks perfect!

7. Use the codemod

At this point, we'd run it across our codebase and carefully check the output. We've done some due diligence so we're hoping it'll work well, but there are often more edge cases that we've missed.

8. Evaluate

This isn't a fabulous codemod. It only replaces one method name, and it doesn't rename existing references to that method. And to be honest, with what it actually does, we could probably have achieved the same thing with a regular-expression-based search and replace.

If this was a codemod we'd be sharing with others, it would be worth turning our sample code into a repeatable unit test, but we won't cover that here.

Of course, our main objective here was to illustrate how to create a simple codemod, and it hopefully served that purpose. Let me know?

Summary

We've covered how to use JSCodeShift to create a simple codemod from scratch, but, as importantly, we've covered a process for developing more reliable codemods.

Have fun developing some codemods, and let me know how you get on!

In part 3, we'll cover a more advanced codemod which involves moving existing code around.

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:

1. 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.

2. 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!