Since the registry should be fixed, this should be the last time that we
need to search and replace those resolutions in this file to avoid merge
conflicts and unnecessary staging of `package-lock.json` changes which are
otherwise unrelated to our changes.
(Though to be clear, the registry setting always takes precedence over the
resolutions in this `package-lock.json` file so the scheme was already
strictly enforced to `http` unless the user's local npm configuration had
been manipulated to behave otherwise.)
Ref: https://npm.community/t/some-packages-have-dist-tarball-as-http-and-not-https/285/50
* refactor: switch `json-stable-stringify` to `fast-json-stable-stringify`
* chore: drop `@types/json-stable-stringify`
* Update CHANGELOG.md for #2065.
This also re-enables the Expiration tests for this library, though I think I
will continue to leave the testsuite decomposed into more granular methods
for readability and future growth.
Note that this doesn't implement the same default `300` second TTL as the
other Memcache and Redis implementations currently do (a very debatable
default we should re-consider in the future).
While it is certainly our current implementation, I'm not sure that the true
spirit of an in-memory key-value store is to only map strings to other strings.
While enforcing `<string, string>` might be necessary for some distributed
cache stores, it seems we shouldn't enforce it for `InMemoryLRUCache`.
By changing the `KeyValueCache` to default to `string` but allow other
options, we can allow the user to decide exactly how the RHS of this store
should be typed.
This does require a bit more flexible implementation of the `length`
calculator which is used for cache ejection, but that implementation will
become immediately useful when we start storing parsed ASTs in this KV store.
Rather than crutching on the `return`, this logic reads more concisely with
a full `if` / `else` pattern.
I say this because two people looked at it and weren't immediately aware,
which really shouldn't be the case from such a brief piece of code.
This test harness is intended to be relatively temporary, but it seems
fruitful to start picking from where these types are already defined rather
than re-implementing them in multiple places.
This change came up in a larger feature implementation and should otherwise be
a no-op but was worth surfacing as its own commit in case that feature never
lands.
