-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modularization #923
Modularization #923
Conversation
- Dependency and DependencyInjection - Ast and Console
- Result and Ast
- OutputFormatter and Ast (this one is a silly hack since deptrac does not recognize transitive dependencies yet, if it did, this refactor would not fly)
- Analyser -> Console
- DependencyInjection -> Console
- OutputFormatter -> Console
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, we should probably discuss the namespace changes in an Issue. Otherwise we run the risk of moving code around every so often. I'd much rather have an issue we can refer to for why the directory/namespace structure is the way it is, in case someone proposes changes.
Sorry for taking so long to review this. Looks good to me. 👍 Just as a heads up, I might revert your change in the DependencyEmitters switching from |
Closes #924
The idea is to split the application into independent parts. Clearly define the stable public API. Along the way, dogfood our own features like private collectors and sample extensions.
I have build this PR to be reviewed commit by commit, otherwise I think it will be too large to review.
The best place to start on the first commit is the
deptrac.yaml
file. One layer per directory, no fancy collector magic.