Switch off of module-deps

[tmcw]

The more I look at this problem, the more sure I am that documentation.js should no longer rely on module-deps, and instead implement dependency resolution via a Babel-based solution, or drop dependency resolution entirely.

Rationale:

• module-deps requires that we parse, transform, parse, and then re-parse JavaScript for every file. For small file trees, it's nearly half of documentation.js's runtime
• module-deps doesn't get us any closer to inferring whether something is public or private, whereas our current --document-exported flow can
• document-exported is essentially a close of module-deps, but for ES6
• module-deps is agressively async in a way that doesn't help documentation.js

[ianwremmel]

would pulling in something like detective-es6 help? or is that targeted at too-specific a use-case?

[tmcw]

It's certainly a consideration! (link to detective-es6 for reference).

One point of hesitation I do have though is that, like detective before it, detective-es6 walks dependencies by parsing them (with node-source-walk, which uses babylon) and outputs them as a string. Then documentation.js would need to re-load the files and re-parse them with babylon. I'd much rather keep a babylon AST around if we ever create one, to save the duplicated work.

[ianwremmel]

ah, good point. could node-source-walk be used as the documentation.js entrypoint? e.g. while processing each file for docs purposes, recursively do dependency resolution if appropropriate?