This is a collection of development-related docs for working on the fossa-cli repo.
The HACKING doc describes our current dev tools and build practices, as well as providing some info about our CI setup.
Our Style Guide las out stylistic and idiomatic standards for all contributions. We are in the process of fully aligning to that guide, but any new contributions should follow the style guide.
Parsing in haskell requires a lot less boilerplate than may other languages, but comes with some caveats. The best practices guide illustrates some important information about how to write parsers correctly, and links to a few tutorials.
If a top-level component of a graph of dependencies is a test dependency, then its direct children are also test
dependencies, as are their direct children, and so on. In some cases, the build tool/manifest files/lock files will
tell us this information, but sometimes, we have to propogate these environments downwards ourselves. This is called
graph hydration, and is handled by the Graphing.Hydrate module.
Testing with hspec provides several useful assertion/organization methods. Wrtiting business logic with
fused-effects allows us to write expressive, convenient, and safe code. Testing those fused-effects-based
functions with hspec is a nightmare. In short, hspec is IO-only, and fused-effects operates on free-ish
monads (not really, but it does work similarly). To make this easier for us, we created the Test.Effect module,
and use that to mimic hspec for an effectful system. More details can be found here.
We also have a mocking framework specifically for API effects.
To allow the user to prevent us from including certain sets of results in an analysis, as well as trying to avoid the work involved, we allow users to filter at both the discovery level and analysis level. More details can be in the filtering document.
We have a release process that manages building our archives and updating our release notes. Read more about our releases here.