Serialize function AST instead of source

[josephfrazier]

Hey @borisdiakur, thanks for the module! I was wondering if you'd be willing to accept a patch that would allow the comments/formatting of a function to change, without invalidating the cache. The idea is that instead of hashing the source code of the function, we would use a parser like babylon to build an AST (abstract syntax tree) of the function that represents its semantic behavior while disregarding comments/formatting/etc. The AST would be serialized into JSON and then included in the hash.

[borisdiakur]

Hi @josephfrazier. Sure. Creating the syntax tree itself may be expansive and changing the current behaviour would require a major version bump. So you’d probably make it an option and call it 'ast' or what ever.

[josephfrazier]

Great, I'll see what I can come up with. I agree that it should be an option.

Note to self: Ideally, this would eventually be resistant to variable renaming within the function, but that would require a more sophisticated analysis (using something like http://esprima.org/demo/rename.html).

[borisdiakur]

Thanks @josephfrazier!

[josephfrazier]

Thanks for the quick merge/release! How would you feel about the astBody feature automatically looking for cached file paths generated without astBody set, and migrating them to their new location? This would make it easier to start using astBody without busting pre-existing caches.

[borisdiakur]

My gut tells me that migration tasks should be avoided in production code. They should rather be implemented in a deployment pipeline.

[josephfrazier]

That makes sense. In order for such a migration to be possible, I think we should export getCacheFilePath(). What do you think?

[borisdiakur]

Yes, that sounds reasonable.