feat(s3): add `getInstance` to expose some utils

[sandros94]

Missing getInstance for the S3 driver, this should allow to presign urls based on the existing driver options.

[43081j]

can you add a test too?

similar to the one in the redis tests:

      it("exposes instance", () => {
        expect(driver.getInstance?.()).toBeInstanceOf(ioredis.default);
      });

[sandros94]

I'm noticing that the can access directly with / separator test is failing on my end, but it is probably caused by the fact I'm using a mostly-compatible S3 I have available

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 60.05%. Comparing base (4d61c78) to head (a87d1f1). Report is 169 commits behind head on main.

Files with missing lines	Patch %	Lines
src/drivers/s3.ts	0.00%	1 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #592      +/-   ##
==========================================
- Coverage   65.05%   60.05%   -5.01%     
==========================================
  Files          39       42       +3     
  Lines        4055     3655     -400     
  Branches      487      590     +103     
==========================================
- Hits         2638     2195     -443     
- Misses       1408     1457      +49     
+ Partials        9        3       -6     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[pi0]

Regarding tests, it seems good change here but it is not right that we always have potential to miss this. i think we should probably add a (required) option to testDriver to provide getinstance check. drivers don't can use () => true to bypass but more explicit. (idea for another PR)

[pi0]

I'm also thinking if it is too early to expose a "client" off s3. If you check aws4fetch implementation, we mainly use it for signing. Many of other functionalities are internal.

Changing the return type after we expose it would be a breaking change also..

We could perhaps return an object like { getURL } to expose limited functionality but explicit interface so if later we change internal library it won't be a breaking change.

[sandros94]

Changing the return type after we expose it would be a breaking change also..

We could perhaps return an object like { getURL } to expose limited functionality but explicit interface so if later we change internal library it won't be a breaking change.

Oh, indeed.

I'll study this and propose a few potentially useful utils. One for sure being getUrl (for pre-signed urls) as it will be a useful one IMO