Starting to write down some thoughts on what it would take to get this package to it's 1.0 release.
I've been digging back into the codebase as of late, and I'm starting to see some cracks in the design of hijacking the babel-plugin architecture to collect this metadata. I still think babel visitors are the right way to capture this information, but I don't think we need to do the collection work as part of babel transpiling the source code.
More on why we shouldn't do this during babel transpilation...
The TL;DR is that we can't guarantee that our plugin will run before any others, so for example if the source project is running the transform-runtime plugin, we may see additional imports for the runtime helpers in the output which might be fine, but there could also be other changes to the code that we don't want to capture.
So if we're not doing this work during babel transpilation, when should we do it? My current thinking is that we should recommend that projects run it in parallel with Babel, or at least run it before they publish so library consumers can pull in the metadata after installing the package.
Does this mean we need to re-write the whole thing? Not necessarily 🙂 See architecture below.
Architecture
Babel visitors still feels like the right approach to capturing this metadata (mostly because I can't think of an alternative to them that I know enough about 😄 ), luckily it's fairly easy to setup a node script that can traverse files with babel.
From a high level view, the new architecture may look like:
- Collect the files we want to collect metadata from
- For each of those files...
- Read in the content
- Pass to
parse from babel
traverse the ast from parse- Write out the metadata file
We may want to consider chunking up this work, and distributing across workers if possible (see architecture from https://github.com/ds-pack/ast-crawler for inspiration).
Starting to write down some thoughts on what it would take to get this package to it's 1.0 release.
I've been digging back into the codebase as of late, and I'm starting to see some cracks in the design of hijacking the babel-plugin architecture to collect this metadata. I still think babel visitors are the right way to capture this information, but I don't think we need to do the collection work as part of babel transpiling the source code.
More on why we shouldn't do this during babel transpilation...
The TL;DR is that we can't guarantee that our plugin will run before any others, so for example if the source project is running the transform-runtime plugin, we may see additional imports for the runtime helpers in the output which might be fine, but there could also be other changes to the code that we don't want to capture.
So if we're not doing this work during babel transpilation, when should we do it? My current thinking is that we should recommend that projects run it in parallel with Babel, or at least run it before they publish so library consumers can pull in the metadata after installing the package.
Does this mean we need to re-write the whole thing? Not necessarily 🙂 See architecture below.
Architecture
Babel visitors still feels like the right approach to capturing this metadata (mostly because I can't think of an alternative to them that I know enough about 😄 ), luckily it's fairly easy to setup a node script that can traverse files with babel.
From a high level view, the new architecture may look like:
parsefrom babeltraversethe ast fromparseWe may want to consider chunking up this work, and distributing across workers if possible (see architecture from https://github.com/ds-pack/ast-crawler for inspiration).