---
robots: noindex, nofollow
tags: pitch
---

# CodeMods - Streamlining the creation process - July/August

### Problem
Now that our codemod package has a small suite of utilities, it's time to put the mods into action! This project will focus on the creation of codemods to be run on production code. The codemod writing process will need to be shown to potential codemod developers and streamlined to most easily strike a balance between efficacy and ease of use.

### Appetite

3-4 weeks. This project has two main components. On one hand, when the codemods are run on production code, they'll uncover any functionality gaps in the current utilities. This may further uncover limitations in the ts-morph library.

Once the utilities have been polished, the next step is to sample the codemod writing process among developers and get feedback to improve the process.

### Solution
Use the [ts-morph](https://ts-morph.com/) library to:
1. Fix any functionality gaps in the current renameProp() utility by running it on production code.
2. Well-document cases for the user that might be impossible or infeasible to handle by the codemod (i.e. if ts-morph has no support for a case).
3. Improve the developer expereince in writing codemods both from an implementation standpoint and an efficiency one by moving towards a data-driven implementation for simpler renaming cases. This will involve sampling developers with codemods to get feedback on their experience.

Hypothetical example of a codemod using the prop-renaming utility:

    
import {
  SourceFile
} from "ts-morph";
import { utilities } from "../utilities/utilities";
import {ICodeMod} from '..'

// Example of a data-driven prop file accessible to devs.
const propDataFile = 'propNames.json';


export function renameRenderCoinProp(file: SourceFile) {
  // Hypothetical utility to return a collection of files
  // that use the props we want to rename.
  let filesToChange = utilities.getFilesByPropName(file, propDataFile);
  let jsxElems : (JsxOpeningElement | JsxSelfClosingElement)[] = [];
  filesToChange.forEach(file => {
   //findJsxTagInFile is a utility that Jon has a working version of!
   jsxElems.concat(utilities.findJsxTagInFile(file, deprecatedPropName));
  });
  jsxElems.forEach(elem => {
    // Working utility: given the JSX elem, identify and rename the prop.
    utilities.renameProp(elem, deprecatedPropName, newPropName);
  })
}

### Risks (Rabbit holes)
Given the work that I've put into the utility so far, it will be difficult to gague when or if an edge case is out of scope. The ts-morph documentation is not comprehensive, so I worry that I could waste time looking for a potential solution to a problem that simply might not be supported yet. With regards to developer expereince, I need to ensure that I get adequate feedback from potential codemod users to ensure that my streamlining efforts are in sync with what developers expect.

### Out of scope (No-gos)
This project will probably not be the end of the codemod interface. The primary scope is to get the utilities into a place where they can be easily and effectively deployed into codemods. I believe attempting to finalize a developer experience in this project (i.e. try to make everything data-driven) would be out of scope.