This change decomposes the project from a single crate into a number of crates. The decomposition is not complete, but it's enough to extract unused_finder as a separate library from good_fences.
The motivation for this change is to allow debugging unused_finder with LLDB without linking against node. before this change, any code that referenced napi would require linking against node, which is difficult to implement in vscode's development tooling. Instead, this change restructures the code so that subsets of it can be compiled and executed without linking against node, for the sake of debugging that functionality.
In this case, unused_bin is introduced as a CLI entrypoint to unused_finder, used only for debugging it against a project. The launch configuration in .vscode/launch.json is set up to run unused_bin with against some on-disk --config-path argument, which is expected to be manually confiured by the user, or generated by project-specific build tooling.
This change decomposes the project from a single crate into a number of crates. The decomposition is not complete, but it's enough to extract unused_finder as a separate library from good_fences.
The motivation for this change is to allow debugging unused_finder with LLDB without linking against
node. before this change, any code that referencednapiwould require linking againstnode, which is difficult to implement in vscode's development tooling. Instead, this change restructures the code so that subsets of it can be compiled and executed without linking against node, for the sake of debugging that functionality.In this case,
unused_binis introduced as a CLI entrypoint tounused_finder, used only for debugging it against a project. The launch configuration in.vscode/launch.jsonis set up to rununused_binwith against some on-disk--config-pathargument, which is expected to be manually confiured by the user, or generated by project-specific build tooling.