Rewriter doesn't actually rewrite

[jackbsteinberg]

At this time the rewriter when run processes the file, determining what the rewritten output would be, but doesn't use that output to actually rewrite the file.

The code needs to be updated to reflect the requirement of actually rewriting, and should get an integration test for this at the same time.

[fergald]

I don't think anyone will ever want to overwrite their original code with the new code. We need to support outputting to a different directory (and if necessary, creating the same directory hierarchy on the output side as we find on the input side - but only for directories that have output files).

[domenic]

Hmm, overwriting the source file is pretty common in the JS rewriter ecosystem, given the existence of source control etc. (See e.g. jscodeshift or prettier.)

If you think we should also have a feature that outputs to a different directory, then let's open a separate issue for that, and figure out how to prioritize it.

[fergald]

I don't think this is JS-world vs others. I just don't think rewriting the input file is useful for get-originals. It makes sense for a reformatter to overwrite the source because you actually want to continue on with the rewritten code as your human-edited code (and clang-format supports this) but you're never going commit the original-ified version of a script as a replacement for the naive source and then work with that going forward, are you?

Chrome's build process definitely needs this (I think most build processes do not like steps that modifies the inputs). So #59 filed.