Publishing codemods to the registry is especially useful for framework/library builders. With features like shareable codemod deep links and Codemod CLI & IDE extenion, your users can adopt your latest releases with one click, straight from your migration doc.
Supported codemod engines
Codemod platform currently supports the following codemod engines:ast-grep
, filemod
, jscodeshift
, ts-morph
, and piranha
.
Required codemod package structure
To make your codemod package compatible with Codemod platform, it needs to have a.codemodrc.json
configuration file in the project root and conform to one of the structures, depending on the codemod engine used.
.codemodrc.json reference
.codemodrc.json reference
Specifies the slugified name of the codemod published to the codemod registry.
Specifies the current codemod version. Should follow the SemVer scheme.
The version field must be bumped every time the codemod is published.
Can be used to set the codemod visibility to
private
.By default, when a codemod is published without a namespace, visibility will be set as public
.
If a codemod is published under a namespace, such as @codemod/my-codemod
, visibility will be set as private
.Specifies the engine used to run the codemod.
Can be any of:
filemod
jscodeshift
ts-morph
ast-grep
piranha
(requires additionallanguage
field that specifies one of the supported piranha languages:java
,kt
,go
,py
,swift
,ts
,tsx
, orscala
)recipe
(requires additionalnames
field, which is an ordered array of codemod names that will be executed)
Can be used to override the default glob pattern for files that will be processed by the codemod.
The applicability field is an object with
from
and to
keys that are both arrays of tuples.
This field can be used to specify the dependencies and versions this codemod is made for.Specifying the applicability criteria of your codemod helps:- Reduce false positives
- Proactively recommend the codemod to users who might need it
- Improve codemod performance, as it will only process projects that make sense
- Allow daisy-chaining codemods (e.g., migrating from v1 to v3 by combining v1-to-v2 and v2-to-v3 codemods)
- a library name
- a comparison operator (
<
,>
,<=
,>=
,=
) - a version number (SemVer compatible)
Can be used to specify dependencies to be installed after successful a codemod run.
You can also specify a package to be removed by prepending it with a
-
sign.
Each dependency should be a string in one of the following formats:package-name@version
-package-name
package-name
If your codemod requires arguments, you can specify them in this field.
Specifies additional information about your codemod for discoverability purposes.
Specifies custom paths for the build input and output files.
Example of a valid configuration file:
.codemodrc.json
Publish with Codemod CLI
Once your codemod package is compatible with Codemod platform, you can use Codemod CLI to publish a local codemod to the codemod registry.1
Login to Codemod platform
Login to Codemod platform by using:You will be redirected to Codemod platform login page. Upon successful login, our CLI will automatically authenticate you.
2
Build your local project
This will build a JavaScript project using
esbuild
and create a dist
directory in your project root. If your codemod is not using a JavaScript engine, you can skip this step.3
Publish your codemod
Publish your codemod by using the following command inside your project’s directory: