Add transform docs in the readme

[ssutar]

No description provided.

[pzuraq]

I'm not sure we should be tiering based on type of object, but instead based on features required for a given class to be transformed. Any one of these classes could require decorators, mixins, or class fields, so it's not enough to delineate by class type.

Additionally, it'll be hard to figure out what category subclasses belong to, and this strategy could result in half transformed files where one class is transpiled, but the other isn't.

I think instead we should add support for globbing, where users can define a folder or pattern that they want to apply the transforms to. This means that we always transform a whole file, no matter how many classes are part of it, but it also allows us to transform roughly by category (e.g. to transform all Routes, you would pass --include "routes/**/*").

[ssutar]

The jscodeshift has support for glob. As per the issue here: facebook/jscodeshift#215 it relies on the shell to expand the glob. So I don't think any thing is needed from the codemods to support that, since the files passed to transform function will already be matched against the path (or pattern) passed.

I like the idea of transforming by types, but as you mentioned it might be difficult or we might be in a state where part the file can be transformed and rest can not.

The current state of codemods is designed with command line options:

1. Transform simple objects (no options needed)
2. Transform object with decorators (Use --decorators=true)
3. Transform object with mixins (Use --mixins=true)
4. Transform object with decorators and mixins (Use --mixins=true and --decorators=true)

To support types - my initial approach would be to add additional parameter --type=Controller|Route|Service|.. Using this parameter we can add different transform, for example route-transforms would have --type=route set by default. I haven't fully explored this approach yet, but I see there might be some cases where it is difficult to identify the type of the object.

[ssutar]

Added #12, it matches the path to resolve the type.