Add types for query, remove type assertions and switch to inference where possible

[calirvine]

Connects #13

Sorry about the formatting changes 🤔 I think they're just prettier defaults. I'll try to revert them all to the previous style (unless you want to add a prettier config, then I can just apply that to the branch).

Notes on changes

• I introduced an invariant fn for asserting on types returned from the cloudflare API
  • Made invariant checks a bit optimistic, as I thought looping over the whole dataset might get expensive 🤷‍♂️
  • Invariants throw, but accessing malformed data will probably also throw later, so I figure that's ok.
• Based types on documentation, haven't tested them.

Hopefully changes aren't controversial, but let me know.

[calirvine]

@benvinegar These types should work, but the prettier changes make this un-reviewable 😅 will revert them tonight before marking this ready for review. These types can probably be more ergonomic than this, but it's better than any.

[calirvine]

Flakey test, reported in #27

[codecov]

Codecov Report

Attention: 48 lines in your changes are missing coverage. Please review.

Comparison is base (aaca36b) 71.68% compared to head (888df60) 71.21%.

Files	Patch %	Lines
app/analytics/query.ts	68.91%	39 Missing and 7 partials ⚠️
app/lib/utils.ts	90.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #26      +/-   ##
==========================================
- Coverage   71.68%   71.21%   -0.47%     
==========================================
  Files          18       18              
  Lines        1695     1831     +136     
  Branches      110      124      +14     
==========================================
+ Hits         1215     1304      +89     
- Misses        474      514      +40     
- Partials        6       13       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[benvinegar]

I spent a solid 30 minutes going over this, mostly because my TypeScript experience is pretty basic, and I had to read up on a bunch of concepts (like user-defined type guards).

I think this hardens the API-calling surface a ton, so +1 from me.

(Also should probably just put some Prettier rules in here already and add it to the pre-commit stuff.)

[benvinegar]

Also – thanks! You've made the first external contribution, which I'm super glad for, because this project isn't going anywhere with just me 😬

[calirvine]

Invariants are nice, they're basically the same as as X but they add a runtime check. The one I included (and which I usually use) is a paired back version of tiny-invariant.

[benvinegar]

FYI I had to revert this PR in 6c7108 because #30. I didn't do any deep debugging but I agree with the reporters that the invariant code seems likely, and we should probably have more tests to cover these range of cases.

Let me know if that's something you wanna poke at – I'm happy to, but I also want to make room for folks.

[calirvine]

First contributor, first to break everything. Casual 😅 . Agreed it's the invariants, though they should be throwing very clear errors. I wonder where those are getting swallowed 🤔 .

I see which invariant is broken, it's getVisitorCountByColumn.

I was working last night on improving that method to infer the return type based on the name of the column passed in, I'll update that branch to be a bit less aggressive in enforcing type correctness.