feat(drivers): enhance drivers with typed options for get, set, remove, and list operations via generation

[schplitt]

Resolves #660

This is the discussed solution for typed options and would replace PR #661 and should be a very good fit with #610.

A Driver can specify a <driverName>Driver interface with set, get, remove and list options typed.
This can be used to Infer the complete operation options via the driver name so that we have strongly typed internal driver development.
This Driver is added to the generated _driver.ts and exposes all set, get, remove and list options from all drivers collectively.
Additionally there are now common operation options which all drivers can implement if they support them (like ttl for set).
Please check that get, set, remove and list make sense as common options or if we need to add/remove some.

I added a utility type to mimic the safeName from the gen-drivers.ts file. Drivers need to also respect that the options could be passed in via the safe name. I am unsure if this is the best solution. Let me know if you have any suggestions.

Please also see the Storage type to see how the new types are used.

This should not be a breaking changes as we still allow any other untyped properties on the root object like before.

If you have any questions, please feel free to ask right away.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.45%. Comparing base (70310f9) to head (46293c6).
⚠️ Report is 43 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #662      +/-   ##
==========================================
+ Coverage   59.99%   62.45%   +2.45%     
==========================================
  Files          42       43       +1     
  Lines        3657     3891     +234     
  Branches      590      660      +70     
==========================================
+ Hits         2194     2430     +236     
+ Misses       1460     1458       -2     
  Partials        3        3              

☔ 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.

[schplitt]

Docs are currently missing. Will write them once the changes are final 😄

[pi0]

This is not easily doable in runtime to pass { 'deno-kv': { ... opts } }, we should instead use { denoKV: {} } to be easier with JS objects.

[pi0]

PS: We could simplify the interface to the drivers to actually accept a custom option. We can start by denoKV as an example, but then we need to allow actually tOpts.denoKV.*.

Like discussed, inference of name could be in followup PR. This is mainly to document a "bag of possibe options" for get/set/etc

[schplitt]

Sorry for continuously having to ask back.

We could simplify the interface to the drivers to actually accept a custom option

I assume you are talking about another Generic Type Variable?

We can start by denoKV as an example, but then we need to allow actually tOpts.denoKV.*.

The type variable should not be restrained to any type (which makes sense)

Like discussed, inference of name could be in followup PR. This is mainly to document a "bag of possibe options" for get/set/etc

Inference of name in another PR for sure, inference of options in internal drivers via generic type maybe in this?

[schplitt]

@pi0 is there anything still missing?