Feature/transitions builder

Closes #113

Work to be done still:

[x] Merge into one flat machine
[x] Human readable names while avoiding manual specification in all cases (sequence)
- [ ] Allow for manual specification of nodes? (i.e. instead of autogenerated beforeAll etc.)
[x] Figure out top level struct (i.e. start/end game and appropriate logic - e.g. complete())
[x] Implement for every game handler and verify behavior
[x] Remove purely transitory nodes
- Limit the scope of this - only if a node has no logic and only has one source / target
[x] Fix self-pointing nodes in flatten
[x] Break into multiple packages
[ ] Add documentation and prepare for launch (i.e. set package.json version, add changelog, publish manually once merged)
[ ] Finalize uppercase / lowercase naming convention
[ ] Review code

Postponed: (Note that changes in the generated state will be breaking changes as the stored states will break)

[x] (stretch) Generate mermaid diagram
- [ ] Include in wikis? Typedoc?
[ ] Hide direct access to state, waiting, players handlers
[ ] Scoped controller (i.e. deck resets at the start of the round or deals out, points reset, counter ticks up)
- This should likely be some sort of 'usesController' property on loop / game configs that accepts an object of providers (which we can merge together as a providers structure)
- [ ] Can the type checking present a read-only / used view of this?
[ ] Standardize testing mocks/constructs between these tests and the driver tests
[ ] Clean up signatures of each handler
- [ ] BeforeEach / afterLast / sequence / wrap type idiosyncrasies
- [x] Handle first response
- [ ] Build action types in
- [ ] Message handling?
[x] Figure out how handleRoundRobin will track state
- Currently we just tell it which controller to use a la can-i-have-that
- If so, is there a way to prevent changes to that controller?
[ ] Consider if necessary to remove empty nodes or if these can be avoided outright
- Main concern is naturally around loops where we don't currently want an end node to be conditional
- Possibly we can use some placeholder flag if need be
[ ] Should guards be generic? (E.g. playerWaiting)
[ ] Extra-strong typing? (Include actual node names in the output?)
[ ] Useful constructs
- [ ] Game types (i.e. point based game) / game over message
- How do teams fit into this?
- [x] Coalesce / cascading response handler
- [ ] Trick controller
- Larger story here about trick messages needing to be common as well - new package?
- How do teams fit into this? Likely as some sort of teams config property that specifies the behavior w/ no teams being default

johnameyer / cards-ts

Feature/transitions builder #121

⚠️ No Changeset found