feat: support sync cache creation

[denkan]

Please check if the PR fulfills these requirements

• Followed the Contributing guidelines.
• Tests for the changes have been added (for bug fixes/features) with 100% code coverage.
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Add non-async createCache() that caching() uses to set up methods (keep current functionality intact).

Having createCache() as addition to caching() allows devs to create cache instances synchronously, and i.e use as default params in methods:

/** Awesome service that will use memory store as default cache, if nothing else specified */ 
class MyItemService {
   constructor(public cache = createCache(memoryStore())) { }
}

[douglascayers]

I'm a consumer of this lib like you, and for what it's worth, your changes look good to me, thanks!

We recently migrated from v4 to v5 and were a bit surprised that the method to create a cache became async. Your change will make those migrations easier, plus the benefits of when needing to instantiate the cache in a sync environment (e.g. constructors)

[jaredwray]

@denkan - can you add in an update to the readme on how to use this?

[denkan]

@denkan - can you add in an update to the readme on how to use this?

Updated readme with short section about createCache() / synchronous creation.

[codecov-commenter]

Codecov Report

Merging #598 (bb1ddda) into master (66246e9) will not change coverage.
The diff coverage is 100.00%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff            @@
##            master      #598   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines          292       313   +21     
  Branches        75        77    +2     
=========================================
+ Hits           292       313   +21     

Files	Coverage Δ
src/caching.ts	100.00% <100.00%> (ø)

[jaredwray]

@denkan - thanks so much for doing this. One thing I was thinking is that we might want to change it to be createMemoryCache as a simple helper function. The reason is that it could be confusing to do this function as sync when if they put in an async store it will cause issues.

You could even simplify and not require them to put in the in-memory store if you wanted.

Can you change that over and update the branch to latest? If you are good with these changes and update it we can check this in. 🎉

[casey-chow]

One thing I was thinking is that we might want to change it to be createMemoryCache as a simple helper function. The reason is that it could be confusing to do this function as sync when if they put in an async store it will cause issues.

The main point of this PR is to allow synchronous creation of a cache as opposed to creation of synchronous cache. That's to say, even if I were using redis, I would still want that to be a synchronous cache since some redis drivers will lazy connect on first access. The main use case here is that it's quite annoying to have to write things like await (await cache).get('key') rather than just await cache.get('key').

[alfonsograziano]

I'd love to use this feature as well!

[jaredwray]

@casey-chow - we are ready to merge this. Can you do the following:

• update your branch to the latest and resolve conflicts
• make sure you are at 100% test coverage
• make sure documentation with how to use this is updated

🍻

[jaredwray]

@casey-chow are you able to update the branch?

[denkan]

@jaredwray and others,
Sorry I dropped the ball on this one (as I mostly use another github account for daily work nowadays).

✅ I've rebased and resolved conflicts.

@denkan - thanks so much for doing this. One thing I was thinking is that we might want to change it to be createMemoryCache as a simple helper function. The reason is that it could be confusing to do this function as sync when if they put in an async store it will cause issues.

You could even simplify and not require them to put in the in-memory store if you wanted.

I don't really want to do this, as it's not actually limited to memoryStore? I could easily define custom store that doesn't require async initialization.

And I think it's better to let the user of the lib define a shorthand if needed:

export const defaultCache = () => createCache(memoryStore({ /* my options */ })); 

// later
class MyItemService {
   constructor(public cache = defaultCache()) { }
}

Let me know your thoughts or if it's ready to merge 🍻