Workaround for #65. Prevents fatal error when a non-string literal require is in a try/catch block

[TikiTDO]

Summary

This the simple workaround for #65, as mentioned by @cpojer

Test plan

Process:

1. Configured react-native to use attached code for extract-dependencies.js

2. Added failing moment version 2.18.1 to project package.json

3. Ran: react-native bundle --entry-file index.ios.js --platform ios --bundle-output /tmp/test.js

Result

Without fix - Bundle fails

With fix - Bundle succeeded. Resulting bundle file contains all necessary code.

[cpojer]

Oh, this makes the visitor significantly more complex and possibly slower. I was thinking that we could instead just look at the parent node and check whether the type is a try-block. Would that not work?

[TikiTDO]

The way traversal works is that every step through the AST the type of each node is used as an index into a visitors object. In modern JS engines the difference between an object with 1 and 3 keys shouldn't actually change the performance of accessing said object, since both will internally be identically sized hashmaps. Benchmark.

There will be a minor performance cost each time it hits a function declaration or a try block, but similarly there is a performance cost if we need to walk up the tree to search for a try block. However, in both situations the performance cost of running the extra steps will be negligible compared even to the cost of the of calling the traverse the tree in the first place.

Given that, I feel the visitor approach is more future-proof, because I expect the visitor logic to get more complex as better solutions are thought of (especially if there is any level of interest of detecting when someone aliases the require method). That said, I'm not particularly attached to my approach either; it was just the most obvious way for me to do it.

[cpojer]

I think this is overly complex for the problem we are trying to solve, and just looking at the direct parent of the require call is sufficient. We can make it more complex when we actually need to, and apply YAGNI (you aren't gonna need it) here :)

[TikiTDO]

I'll take a look at this next week when I have some time. However I would note that perhaps the proper approach for the primary gatekeeper to using react-native should adopt an approach that attempts to preempt issues before they happen, especially when it comes to fatal errors in systems that may be mission critical to a myriad of other organizations.

[cpojer]

See #69