fix: refactor install method to instead be free functions

[wschurman]

Why

Asked claude extended thinking to analyze the installExtensions monkey-patching strategy we went with in #410 and compare it to other typescript ORM libraries.

It said essentially that it was ok, but most modern libraries choose not to do it that way, and instead recommended "free functions" (TIL about that term) to instantiate the loaders. (knexLoader(BlahEntity, vc))

Working with it even more, I came up with an even better method on top of free functions to keep the BlahEntity.knexLoader(vc) syntax. The strategy is to:

1. Convert to free functions (this PR).
2. Add PostgresEntity/ReadonlyPostgresEntity subclasses that application entities can extend that implement the static extension methods.
3. Revert the codemod change from this PR to keep the codemod to prefer the BlahEntity.knexLoader(vc) syntax since most applications should use the subclasses (though it's not strictly necessary if they prefer the free function at callsites).
4. Revert the codemod in the integration tests to express better syntax pattern.

How

Claude did most of this, but broadly speaking the strategy is to have the free functions, and then instead of patching the prototypes/classes for singleton caching, use a WeakMap where the core package singleton is the key and the value is the new knex-specific object.

Test Plan

Run all tests.

[wschurman]

• fix: update integration test to use BlahEntity.knexLoader syntax #444 : 2 dependent PRs (#446 , #448 )
• fix: revert change to codemod now that Entity.knexLoader is supported again via subclass #443
• feat: add PostgresEntity/ReadonlyPostgresEntity classes that expose knexLoader methods #442
• fix: refactor install method to instead be free functions #441 👈 (View in Graphite)
• fix: Add default for TSelectedFields for application-instantiated types #438
• fix: pass in augmentable classes to installation #437
• feat: Add pagination max page size configuration #436
• feat: Add ilike and trigram similarity search to pagination #431
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (3d4aa0e) to head (8f2c103).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##              main      #441    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          109       107     -2     
  Lines        16142     15713   -429     
  Branches      1419      1412     -7     
==========================================
- Hits         16142     15713   -429     

Flag	Coverage Δ
integration	23.05% <98.71%> (-4.24%)	⬇️
unittest	95.02% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ide]

The main tradeoff that comes to mind is (lack of) multiple inheritance. Maybe it doesn't matter because entities are backed by only one type of database.

[wschurman]

It's a valid tradeoff and one that if it is important enough for an application they can opt to just use the free functions added here instead of the base classes (they're equivalent as shown by the tests in the PR that adds the subclasses). For Expo's server, we use subclasses already for all our entities.

It'd be cool if mixins were officially supported in TS/JS. The other option is a higher-order component function (closest thing to mixins), something like:

class BlahEntity extends Entity { ... }

export default withKnexLoaders(BlahEntity)

But the key is that these approaches all require the free functions added here, and for now the subclass approach matches most closely to what the Expo server will need.

[wschurman]

Merge activity

• Feb 16, 8:58 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 16, 9:11 PM UTC: Graphite rebased this pull request as part of a merge.
• Feb 16, 9:14 PM UTC: @wschurman merged this pull request with Graphite.