What if our code mods were easier to write?

[willklein]

I think we could turn this: https://github.com/Workday/canvas-kit/blob/master/modules/codemod/lib/v6/deprecateCookieBanner.ts

Into this:

mod.imports({
  where: {
    source: ['@workday/canvas-kit-react', '@workday/canvas-kit-react/cookie-banner']
  },
  transform: {
    specifiers: [
      {
        input: 'CookieBanner',
        output: 'DeprecatedCookieBanner',
        default: true,
        transformNamedImports: true
      },
      {
        input: 'CookieBannerProps',
        output: 'DeprecatedCookieBannerProps'
      }
    ]
  }
}) 

mod.types({
  where: { importDeclaration: {
    source: ['@workday/canvas-kit-react', '@workday/canvas-kit-react/cookie-banner'],
    specifier: 'CookieBannerProps'
  }},
  for: ['TSTypeReference', 'TSInterfaceDeclaration'],
  transform: {
    identifier: {
      input: 'CookieBannerProps',
      output: 'DeprecatedCookieBannerProps'
    }
  }
})

mod.jsx({
  where: { importDeclaration: {
    source: ['@workday/canvas-kit-react', '@workday/canvas-kit-react/cookie-banner'],
    specifier: 'CookieBanner'
  }},
  for: ['JSXIdentifier', 'MemberExpression'],
  transform: {
    identifier: {
      input: 'CookieBanner',
      output: 'DeprecatedCookieBanner'
    }
  }
})

I found that our usage of jscodeshift was extremely repetitive and verbose. We have a few very common transforms, like updating imports, type identifiers, and JSX components & props. I'd like to create a helper library to write those transforms more declaratively. I think it's worth abstracting away some of the AST details too, which is part of what makes our current code mods verbose.

I could really use some input on what we'd like the syntax to look like for an abstraction over jscodeshift, as well as how we'd like to manage the package, because I'd like to publish it on NPM.

[willklein]

It's worth mentioning that if we just wanted utilities specific to Canvas Kit, we could simplify the syntax even further. I would prefer to make it a general purpose tool that works for other projects though.

[anicholls]

Love the look of this approach. I like the idea of keeping it generic as well. IMO it's important to think about how we could make these functions as flexible as possible, rather than catering too much to our most common use cases.

First question at a glance: How would I perform multiple transformations in jsx or types? Do I need to make multiple calls to these functions? Or could identifier also accept an array of objects similar to specifiers in imports?

Some additional functionality/common use cases I'd like to propose:

• Adding/removing imports (instead of just swapping). Maybe:

mod.imports({
  where: {
    source: ['@workday/canvas-kit-react', '@workday/canvas-kit-react/cookie-banner']
  },
  add: { // or remove
    specifiers: [
      {
        output: 'Default',
        default: true
      },
      {
        output: 'Named',
      },
      {
        output: 'Named', // {Named as Foo}
        local: 'Foo'
      }
    ]
  }
}) 

• Some sort of hook to add custom processing code for the matched nodes. Particularly for the jsx function, where we may want to alter props, etc. We've already done the work to find the node - no reason to make me do it again haha
• Moving from a default import to named (e.g. Foo to {Foo}), or a locally named import to a regular named import (e.g. {Foo as Bar} to {Bar})
• Replacing a type/interface with string literals (e.g. FooBar to 'foo' | 'bar')

[willklein]

Great input already!

I like the idea of reducing calls as much as possible. My current mental model is to co-locate a "set of related transforms" under a given function, in the case of imports, jsx, and types. I'm not certain that's ideal, but it's what I gravitated towards as I iterated from solving for one case, then two, then three or more.

Given a set of transforms around a certain type of AST node, I like the idea of a single call to the appropriate function, and loading in as much as possible in the transform definition (the object literal). So accepting an array of objects or string values depending on the situation, wherever one can be useful, makes sense.

Your suggestion for adding imports is spot on!

I was also thinking about how to re-use a node query! I am less worried about the "work" being performed multiple times, but the code being repeated is a smell to me. We can certainly define variables to consolidate a consistent query (the where properties in my proposed API), but if there's another way to improve the API, I'm interested in exploring it. I'm thinking of something similar to jQuery objects, but that adds some complexity out of the gate.

I like those additional transform suggestions too! My next step is to check our other code mods and prioritize what we are already doing, but if any seem particularly different or valuable for shaping the API patterns, please point them out.

[alanbsmith]

Worth a look: https://www.codeshiftcommunity.com/