https://github.com/dave/dst

It makes no sense for the user to be able to add the same import more than once, so we should make it behave like a set.

The following code should add the import only once:

imports := file.Imports()

imports.Add("errors")
imports.Add("errors")

If a function has a parameter of type *codemod.Repository we could pass an object representing the repository to it.

What happens at the moment

If we are applying a codemod to a repository and an error happens, we stop traversing the files immediately and don't apply the codemod to the rest of the files nor create a pull request.

What we want

If we are applying a codemod to a repository and we encounter an error, we probably should just let the user know that something went wrong and keep going to the next file.

Situation where this could be useful:

• We have a 100 files that would be affected by a codemod and one of them causes an error for some reason

If we ignored the file that causes an error, we would still apply the codemod to 99 files which is probably closer to what the user wants instead of applying the codemod to 0 files if a file causes an error even though the codemod would work for the rest of the files.

if we are executing too many codemods or codemods that take a long time, that user may think that thinks are frozen.

• Add logs to let the user know what we are doing at the moment

Example:
Log that we are cloning a repository
Log that we are applying a codemod
Log that we are creating a pull request

Vendor folder should never be modified.

• Use strings.Contains to check if the path is in the vendor folder and if it is, ignore it.

Part of #95

It could be interactive.

• User is shown the repository name and asked if the repository should be kept.
• User types n if they do not want to apply codemods to the repository.
• User types y if they want to apply codemods to the repository.
• User types a if they want to apply codemods to every repository found.

• Update README and examples folder if necessary

• Get package name
• Modify package name

There's a return statement instead of a continue statement in

if len(filesAffected) == 0 { }

Add methods to deal with switch statements and its branches.

Test code transformations like rust tests compile errors:

Allow user to have a file, say expected_output.go and let the user compare it with the source code generated by applying the codemod.

If we have a codemod that only cares about the repository and does not care about individual files like:

func addCodeOwnersFile(code codemod.Project) {
  ...
}

we should not traverse through every file in the repository.

• Method to check if file contains import path
• Method to remove specific import path

• Malformed files should be ignored

The user should be able to write and run a codemod in their own machine.

I think it should be easy to do this, since all we need to do is to skip the repository cloning, branch creation e remote pushing.

At the moment, when comparing the source code generated after applying a codemod, we are removing every space and ignoring the indentation.

It should not be like this since indentation should be preserved.

We need to:

• Preserve indentation as much as possible
• Take indentation into account when making comparisons in tests

If we apply a codemod locally using apply.Locally the value in codemod.Project.ProjectRoot will be the temp folder instead of the local folder that we are applying the codemod to.

Example:

I want to find a CODEOWNERS file and add/remove users from it

Something like:

SourceFile.Path() // "src/some/path/file_name.go

I want to apply transformation for every repository in an organization that matches a target regex:

The following example would replace the email that belongs to user_1 with the email that belongs to user_2.

Note that the -y flag does the replacement and creates the pull requests without asking asking for user interaction.

apply_codemod -org=github.com/org_name -search=user_1@email.com -replace=user_2@email.com -y

If we ran the replacement without the -y flag, the user would be asked if they want to proceed for each repository(if a match is found in the repository).

apply_codemod -org=github.com/org_name -search=user_1@email.com -replace=user_2@email.com -y

Related issues

#97
#98

At the moment, we are visiting one repository at a time it makes things take too long.

• Clone more than once repo and apply codemods to it at the same time

Implement run=... as described in #95

User should be able to run arbitrary commands.

Show how to apply a codemod to a local directory.

It's possible we will need to do something more than just comparing two strings when checking if source code has been modified correctly.

• Create a function, check(*testing.T, a, b string) for example, that will abstract the source code comparison making changes to the comparison.

When a set of codemods is ran, we could show the user two lists:

• A list of pull requests urls

• A list of repositories that weren't affected because not a single codemod was able to change a file

It may be useful for imports:

file.Imports().Add(fmt.Sprintf("%s/some/package/path", file.Module().Name()))

The api to apply a codemod to several remote repositories is kinda of annoying at the moment if we have a lot of repositories.

• Simplify it.

• Download package using go get
• Delete folder that contains the package files in the repository
• Replace import paths that use the folder that contains the package files in the repository with the newly installed package
• Run go mod tidy

It must customizable/reusable
It must be usable by someone that has now idea how it works

If it works, create a migration tutorial.

Allow the user to access file ast so the user can use it as a work around for features we have not implemented yet.

Example:

User wants to modify something that is not accessible using the methods we provide.

By allowing the user to access the file ast, the user can access whatever they want by inspecting the ast itself.

In an ideal world, the user would never need to access the raw ast to find something.

It is possible that a repository doesn't have any changes that the codemod needs to do, so we shouldn't create branchs and pull requests for these.

Document using comments so we can generate a doc page using godoc.

Make sure to include examples.

Definition of better in this case:

Someone that doesn't know what a codemod is should be able to create one after reading the README.

Important points:

What's a codemod? Make the person interested, probably using an example.

Explanation of how it works, talk about ast?

A bunch of examples and maybe a gif showing a bunch of codemods being applied.

Step by step tutorial on how to use the tool.