denosaurs / cache

🥌 Deno cache library

cache

Cache library, compatible with deno module caching.

import { cache } from "https://deno.land/x/cache/mod.ts";

const file = await cache("https://example.com/file.json");

const text = await Deno.readTextFile(file.path);
console.log(text);

Maintainers

• Filippo Rossi (@qu4k)
• Elias Sjögreen (@eliassjogreen)

Other

Contribution

Pull request, issues and feedback are very welcome. Code style is formatted with deno fmt and commit messages are done following Conventional Commits spec.

Licence

Copyright 2020-2023, the denosaurs team. All rights reserved. MIT license.

cache's Issues

Suggestion: function instead of class?

I am working with cached files in this project and needed a way of caching a file and all its dependencies like deno cache does by default.
I wonder if it would be a better idea to have functions to resolve the path and cache files instead of a Cache class

import { cache, resolve } from "https://deno.land/x/cache/mod.ts"
await cache("https://deno.land/std/path/mod.ts")
const filePath = resolve("https://deno.land/std/path/mod.ts") // output: /user/username/library/cache/deps/https/deno/deno-land/72ee5916977ca9d8801c801f642353d811373786e51e3d7574cca966634b4f97

I think this would be more deno style. What do you think?

File processing support

This could allow for downloading a for example compressed file and decompressing it before it is cached like described in esbuild#936.

It should be rather trivial to implement and could look like this:

const file = await cache("https://example.com/file.zip", (stream: ReadableStream) => {
	return stream.pipeThrough(unzipTransformStream);
});

Use `sync` variant of file operations

readFIle --> readFileSync
... and any others

This could be seen as quite a file-heavy module, so i think speed can be a concern. By nature, async operations are slightly slower to process than sync operations (as in awaiting those). Alongside this, I have seen time and time again (and ive just tested this again), that Deno's sync methods are faster than the async variant (about 400% faster when comparing readFile and readFileSync)

So thats why i think it would be a good idea to do this, and there's no loss - maybe even some methods may not even need an await

Saving files with original extension in the cache is incompatible with Deno

The change introduced in this commit f93fdd0 makes this library to behave differentlly from Deno.
Sharing the same cache with Deno makes the file to be download twice because Deno doesn't recognize the file with the extension.
If the issue with Deno.openPlugin still persists, it would be possible to have this behaviour configurable?

file:// URLs resolved incorrectly on Windows

A typical file:// URL on Windows looks like this: file:///C:/Users/Liam/Downloads/foo.txt.

Currently, in file_fetcher.ts, file:// URLs are translated to paths by just taking the pathname. However, on Windows this leaves the aforementioned path as /C:/Users/Liam/Downloads/foo.txt, which is an invalid path and causes an error.

Instead of just taking the pathname, I think using fromFileUrl from std/path/ should fix this.

bug: file urls are not resolved as absolute paths