What I built
Dep Tree is a CLI tool that is meant to be used either in CI systems or in the users local machines. It takes a JavaScript/TypeScript project as an input and validates/renders its file dependency graph.
Category Submission:
Maintainer Must-Haves
Dep Tree was designed to be used in CI systems in projects with a lot of people collaborating.
It is very common to setup some other static analysis tools like linters for automatically checking that contributors are following some established rules regarding code style.
Dep Tree does the same, but analything the file dependency graph in the project, failing the CI workflow if a contributor introduces a dependency in the code that couple things that should be decoupled.
App Link
https://github.com/gabotechs/dep-tree
Screenshots
Description
dep-tree is a cli tool that allows users to render their file dependency tree in the terminal, or check that it matches some dependency rules in CI systems.
It works with files, meaning that each file is a node in the dependency tree:
- It starts from an entrypoint, which is usually the main executable file in a program or the file that exposes the contents of a library (like src/index.ts).
- It reads its import statements, it makes a parent node out of the main file, and one child node for each imported file.
NOTE: it only takes into account local files, not files imported from external libraries.
- That process is repeated recursively with all the child files, until the file dependency tree is formed.
- If rendering the dependency tree in the terminal, the nodes will be placed in a human-readable way, and users can navigate through the graph using the keyboard.
- If validating the dependency tree in a CI system, it will check that the dependencies between files match some boundaries declared in a .dep-tree.yml file.
Link to Source Code
https://github.com/gabotechs/dep-tree
Permissive License
Background (What made you decide to build this particular app? What inspired you?)
I work at propeldata.com, and our backend relies heavily on TypeScript.
As the company evolves, so does the code, and we had no way for ensuring that parts of a project that where initially designed to be decoupled, remain decoupled as more people contribute to the codebase.
We use dep-tree not only for better understanding the dependency flow in our applications, but also for validating in CI pipelines that new commits do not break any dependency rule.
How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)
The project is written in Go, and it ships an executable binary with a CLI interface.
It's pipelines heavily rely on GitHub Actions for testing, linting and automatically releasing new versions of this binary. Each commit in a PR gets tested and linted, and on a merge to main, a new tag and a GitHub release is created (homebrew tap included).
dep-tree even ships its own GitHub Action https://github.com/gabotechs/dep-tree-action, that people can use out-of-the-box in their GitHub Actions pipelines.
The biggest lesson I got from setting up all this workflows was to be able to ship cross-compiled binaries for all the architectures and packaging them in a homebrew tap. GitHub Actions combined with https://goreleaser.com/ made this extremely easy.
Additional Resources/Info
I have another blog post here with some sample use cases that have proven to be relevant in our daily workflow: https://dev.to/gabotechs/dep-tree-a-tool-for-rendering-and-linting-your-projects-dependency-tree-in-the-terminal-25om
Top comments (0)