Tackler is accounting engine and reporting tool for text based double entry accounting system.
Hi, here are some answers and comments to your comments and questions:
The community of Tackler is next to non-existing, that's true. However Tackler is actually used based on OSS-repository statistics and stats are increasing over time. So there is some traction of it e.g. e257/accounting/tackler#2
Tackler core itself is actually really small, few thousand lines of code, so with all the tests it should be fairly easy to take over it. Also used Scala code is pretty straightforward. These should provide some insurance against small community.
It would be ok-ish to have some java code with Tackler, if reason is good and well justified. One example would be in-memory Git repository writer: GitDB On the other hand, Scala is really nice language and it's possible to move from Java to Scala in gentle way (I did that - Tackler isn't very die-hard Scala).
Separate reporter and/or web-server project based on Tackler would be really cool thing to have. I have a prototype done with Play Framework for server side and scalajs-react + ScalaJS + Tackler Client API on client side. Sprint Boot is also an interesting option. At the moment I think it would make most sense to have the server as separate project, but that is not set in stone. As about languages, I won't accept Node.JS or heavily Javascript based solutions for Tackler, because of untyped nature of the Javascript. Same goes for Python.Python utilities are totally ok, but core functionality of Tackler can't be implemented with Python.
If you could point worst places where documentation is lacking or provide patches, that would be really awesome.
Easy requirements for contributions are that everything is signed-off (e.g. every single commit) and it would be really nice if you could also PGP sign commits. Please see CONTRIBUTING, it has some information.
Then the more difficult and vague stuff about contributing:
There are some reason why tackler exists in first place and some high level goals in README. At the moment aim of Tackler is to have really narrow focus, but that minimal feature set should be done extremely well and trustworthy.
Also all features must be tested really well. This is unbreakable rule for Tackler. I won't accept any changes (my own or someone's else) if it degrades seriously test coverage. There might be exceptions if it's truly too difficult to test reasonably, but it should be exceptional situation.
I also like to see Tackler developed DDD/TDD way, so that all features are defined to some extend first, as are test cases for those features. Please see list of TEPs, e.g.: TEP-1009 and TEP-1010
Tackler's idea is to be minimal core and cli interface is "reference implementation" of those features of core, but not necessesary full CLI UI. For example, I have several applications where all kind of business domain specific filters are defined in shell script and fed to tackler via --api-filter-def as base64 armored ascii strings. But those filter combinations are not implemented as CLI options for above reason.
On the other hand, if the idea is cool, then by all mean let's have it in the Tackler (e.g. accounting checksums and geo location).
My plans for tackler are: It will be maintained and extended as needed. (ATM I have tag support on the pipeline). Tackler's README has some high level ideas for future. I typically work with Tackler during nothern hemisphere winter and not so much during summer. However, this winter has been exception. Tackler probably won't ever have as many options and features as ledger, hledger or beancount. And it won't have ledger-compatible format.
If you think it would make sense, we could create a separate, more relaxed repo for tackler examples, like jgit Cookbook
I like this one, yes
Do you think we could compile the scala code to a typescript library as well ?
I honestly don't know from technical point of view. From project's point of view, probably not. Tackler's core has few quite big java depencies which have non-trivial functionalities (e.g. JGit), so those might not translate to Typescript or Javascript so well. It would be also be a substantial amount of work to maintain core in two different implementation language, even when the translation would be done by compiler/plugins (all command line test, unit and integration tests would have to be duplicated for Typescript target).
I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts
That sounds really cool. Especially if you have feedback how handy or not git storage backend is for your use case, that would be interesting to hear.