As a general follow up of #179 (closed) , it would be nice to explore if we can trim down the number of forks we use in the project. I'm counting, at the time of writing, 8 forks for just the ones that Alp created a while ago to smooth out the integration with the libraries, but there are many more.

The problem with forks is that they tend to go out of sync with the main repo, unless we merge the changes upstream or we pay the toll of keeping our forks up-to-date with upstream, which seems fairly laborious. Another problem with forks is that they prevent upgrading to newer GHCs or (in case of stack) a new LTS (if they conflicts with some other package).

Typically one makes a fork for a few reasons:

1. The package is obsolete/unmaintained and it doesn't build alongside the other dependencies / version of GHC in use;
2. The package doesn't provide a needed feature, so it's forked so a feature can be added;

Typically 2. is where things go wrong most of the time, because for particularly stubborn/picky maintainers, the changes in the fork are not "good enough" to be ported upstream, or they require more upfront design work, or <put-your-favourite-reason-here>.

When I've tried to build gargantext, stack pulled 479 dependencies (between direct and transitive, of course).

I would suggest we do a dependency audit in order to identify:

• Which packages we can drop; if we are depending on a package only for one of two functions, as crazy as it might seem, it might be more practical to simply crib what we need, move it into our source tree and stop depending from the underlying package;

• Which forks can be dropped because now 1. doesn't hold anymore (i.e. the package has been upgraded);

• Which forks have any hope of going away because we can push the changes upstream (see 2.);

This work will not only help with building times, but will also lower the contribution barrier (i.e. see #179 (closed)).