[ANN] First releast of Rotor: a multi-file refactoring tool

It is our pleasure the announce the first release of ROTOR: a tool for refactoring multi-file OCaml codebases. Currently, it just performs renaming of value bindings, but the intention is for ROTOR to support a full range of refactoring tasks, and to be the go-to refactoring tool for the OCaml community.

ROTOR has been developed at the University of Kent, with the support of Jane Street, as part of a research project on trustworthy refactoring.

It is available now on OPAM:

> opam install rotor

This release is an alpha version, and so we’d love you all to try it out and give us your feedback. Since it is still a prototype, we are certainly not making any claims that it works perfectly in all cases, but we think it is at a stage where it can start to be useful to the community, and where it will be useful for us to seek community feedback.

Please raise any issues on the gitlab page. Please also email us to report on your experiences.

Currently, ROTOR is invoked from the command-line:

> rotor rename [options] <from-id> <to-id>

ROTOR can determine the files that comprise your codebase using .merlin files, and outputs a diff patch which can be applied to effect the renaming. For the future, we are looking at integrating within IDEs, which will make it easier to use.


A small request if I may: flagging dead code would be a much appreciated future feature.


Thanks, @perry - noted. Perhaps you can raise a ticket on the gitlab page? Thanks

I requested already at the GitLab, but duplicating here, just in case it was missed. Following the discussions about deprecating Pervasives in OCaml, I think it might be beneficial to define/implement a general way to autodetect and autofix deprecations through dune plugin. A good example how this can be done is Rust’s cargo fix.

I am very excited for this. I’ve been looking at your project for some time now.

I hate to be this guy but did you consider moving to github? I suppose there are certain advantages of gitlab and that’s why you chose it. That said, the social aspects are incredibly important for any OSS project and github, because of the community size alone, wins here.

I use both github and gitlab. Knowing one, it takes virtually no time to make use of the other. I also think there’s inherent value in keeping some small amount of decentralization, so all our eggs aren’t in one basket. (Finally, I prefer git lab, both because of their feature set and commitment to OSS).