# ZEPENDENCIES (name TBC)

## User Experience

* User would mark crates that should no longer be used.
* Dependents to said crate would be displayed as some kind of tree.
* User can access information like repository, docs, etc. to each crate.
* User can supply filters on the fly.
* User would mark crates as "done", which would remove them from the tree.

* There would be indicators to display which crate only requires a dependency optionally.
Conditionally (on hover?) display the condition.
* Outdated dependents would (by default) only be displayed if there are dependents to it.
* Collapse chains of crates if they are each the only node (similar to how IntelliJ does it)?

## Usecases:

These are the following actions possible with this tool:
- Retrieval of all crates with filters applied and displayed in a tree form
-

## Design

* any queries are performed as lazily as possible: we don't need to build the entire dependent-tree, the user won't see it all.

### Single vs Multi-User

* single user
- would allow us to use frameworks like tauri
- would be easier to do
* multi user
- would allow collaboration
- application could be hosted online

### Handling Multiple Users

- either the frontend's download is rather large (the entire compressed database dump is 250MiB, though that one contains more than what we need)
- or we perform most processing on the backend side and only send the results back

## Implementation

* we would have a sqlite database (or maybe something else) containing all the relations between crates.

### Concerns

* wait if the rdep tree is fetched each time while the markings and notes remain static couldn't they get outdated?
* Where do we store users' notes and marks?

## Future Scope

* auth if needed for collaboration
* Import "legacy" crates from RUSTSEC
* Smartly handle optional dependencies: if a feature flag is not enabled, conditionally ignore the rdep?