f69d63e8be
* fix(NA): windows ts_project outside sandbox compilation adding tsconfig paths for packages * chore(NA): missing @kbn paths for node_modules so types can work * chore(NA): missing @kbn paths for node_modules so types can work * chore(NA): organizing deps on non ts_project packages * chore(NA): change order to find @kbn packages on node_modules first * chore(NA): add @kbn/expect typings setting on package.json * chore(NA): fix typechecking * chore(NA): add missing change on tsconfig file * chore(NA): unblock windows build by not depending on the pkg_npm rule symlink in the package.json * chore(NA): add missing depedencies on BUILD.bazel file for io-ts-list-types * chore(NA): remove rootDirs configs * chore(NA): change kbn/monaco targets order * chore(NA): update kbn-monaco build Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| src | ||
| .babelrc | ||
| BUILD.bazel | ||
| jest.config.js | ||
| package.json | ||
| README.md | ||
@kbn/babel-code-parser
Simple abstraction over the @babel/parser and the @babel/traverse in order
to build a code parser on top.
We have two main functions parseSingleFile (sync and sync version) and the
parseEntries (only async version). The first one just parse one entry file
and the second one parses recursively all the files from a list of
start entry points.
Then we have visitors and strategies. The first ones are basically the
visitors to use into the ast from the @babel/traverse. They are the only
way to collect info when using the parseSingleFile. The strategies are
meant to be used with the parseEntries and configures the info we want
to collect from our parsed code. After each loop, one per entry file, the
parseEntries method will call the given strategy expecting that
strategy would call the desired visitors, assemble the important
information to collect and adds them to the final results.