You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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?
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:
The text was updated successfully, but these errors were encountered: