feat: allow providing custom runner per transform file thru codeshiftConfig

[kiprasmel]

depends on:

• https://github.com/CodeshiftCommunity/CodeshiftCommunity/pull/63
  • (base needs to be set to kiprasmel:patch-1 but cannot do that here), and regardless, we need to merge it first, before this one.

example on how it could be used:

• https://github.com/pipedrive/CodeshiftCommunity/pull/22
  • though note we might refactor into separate PRs, idk, preferably would use directly from upstream (you).

fixes a lot of cases for us:

1. we have a postcss codemod that we want to run, while still utilizing the @codeshift/cli.

though, i don't know if these changes will work if we're using a remote package, will they?

2. we'll want to do some global pre-processing on files before running our codemod.

though, there's still no way to provide the codemod as a function instead of an import path to jscodeshift, which will force us to do dependency injection instead of just passing the pre-processed results as an argument to a function.

this is where the considerations to fork jscodeshift come into play again:

• https://github.com/CodeshiftCommunity/CodeshiftCommunity/issues/67

[kiprasmel]

would be great to review if possible @danieldelcore 🙏

[danieldelcore]

Really interesting, could you give me some more background as to how this all fits together? As I understand it, instead of only being able to modify js / ts files you want to be able to provide a custom runner to begin to support other types of files like css?

Can you share an example codeshift.config with me?

Also i've just merged some fixes/improvements, you might want to rebase 😄

[kiprasmel]

@danieldelcore hey! yes, correct, we want to have independance from upstream (you) so that we don't need to wait to get some custom runner merged (sometimes it could be very specific even, and you might not even need it merged, and that's fine), while still utilizing your CLI w/o publishing our own, and this unlocks the door.

this could even be used if e.g. you want to do more steps before/after the codemod run, e.g. doing some pre-processing, or idk updating some npm dependencies -- you can basically add any code there. the value is that we don't need to create wrapper CLIs around it, and just use the @codeshift/cli as it is.

re: updates -- coolio, rebased smoothly.

an example I already linked to -- https://github.com/pipedrive/CodeshiftCommunity/pull/22

• codeshift.config.js: https://github.com/pipedrive/CodeshiftCommunity/blob/0f9fa7119abdc7afcd38022a7a235cf433be0030/community/%40pipedrive__convention-ui-react/src/codeshift.config.js
• the custom runner, for postcss this time: https://github.com/pipedrive/CodeshiftCommunity/blob/0f9fa7119abdc7afcd38022a7a235cf433be0030/community/%40pipedrive__convention-ui-react/src/misc-utils/runPostcssCodemod.ts
• & how we use the custom runner (by specifying the codeshiftConfig): https://github.com/pipedrive/CodeshiftCommunity/blob/0f9fa7119abdc7afcd38022a7a235cf433be0030/community/%40pipedrive__convention-ui-react/src/5.0.0/codemod.postcss.ts

and you can read on how to use the codemods (we have a simple wrapper run.js which by now the only unique functionality it has is shorthands.json; run.js is also the reason why i asked to change the config from .ts to .js! though, some community/ packages here still use the non-cjs export default instead of module.exports = . and it's also the reason why we got rid of require.resolve or path.resolve inside of codeshift.config.js, and would recommend applying this to packages here as well. (the config becomes almost like a json file at this point)):

• https://github.com/pipedrive/CodeshiftCommunity/tree/fork/community/%40pipedrive__convention-ui-react#readme

you can try running the demo files. i just added a new one for scss:

• https://github.com/pipedrive/CodeshiftCommunity/tree/fork/community/%40pipedrive__convention-ui-react/src/5.0.0/demo

the only concern is -- will this work if we publish our npm package? i haven't had a chance to try that; i need to first extract into a separate repository. but ideally we'd figure this out here before i do that.

and maybe a slight change i'd do is renaming codeshiftConfig to just codemodsConfig or codemodConfig or both. goes in line with the same idea that we should have an npm package codemods-cli that you could npx to, instead of @codeshift/cli.

wdyt? would be very useful.