jsdf / browserify-cache-api

jsdf

github pages

browserify-cache-api's Issues

Package cache dead code?

I've been getting ready to fix some more bugs with browserify-cache-api, but I figured I should understand all of the existing code first and make unit tests for it before I changed too much so that way I wouldn't break anything without realizing it. I can't figure out what the invalidateFilesPackagePaths and invalidatePackageCache functions are for.

invalidateFilesPackagePaths removes things from cache.filesPackagePaths, but nothing else ever reads or writes to that object, so it's always empty. Same with invalidatePackageCache and cache.packages.
Additionally, prior to 37f700b, packagePathForPackageFile had a mistake in it so that it would always trigger an exception. I couldn't get the exception to trigger while using browserify-cache-api, and no one has reported it that I've seen, so it seems like the code has been completely dead for a while.

I assume it's incomplete code. Is it for invalidating the cache of files when their package.json files are changed? (I've made a failing test to track that issue here in a branch.) I can fix it up if that's the purpose of it; I just want to make sure there isn't some other purpose that I might unknowingly break in the process.

Is there a point to BrowserifyCache.getPackageCache? I'm convinced that it currently always returns an empty object. I'm not sure what type of object it's intended to return, or what it would be used for. BrowserifyIncremental doesn't use it. Any complaints if a future pull request of mine happens to drop that function?

CONCURRENCY_LIMIT leak detected

When will the next patch be released?

I see that this issue:

browserify-cache-api/index.js

Line 11 in f9d06fb

CONCURRENCY_LIMIT = 40;

Is resolved in master, but not in the 1.5.0 version currently released.

Support for "exposeAll" option

When I try to use browserify-cache-api on a bundle that has "exposeAll" set to true, it gives me an "ENOENT : no such file or directory" error that I don't get when I either set exposeAll to falso, or do not use cache-api. So I think cache-api does not support bundles with that option set to true right now.

Would that be easy to support? I'd do it myself if you gave me some hints what'd need to be changed.

using md5/sha1 for caches instead of / in addition to last modified time?

(Note: I'm using browserify-incremental CLI, which internally uses this module to create the cache)

The thing is that I use typescript sources that get compiled into new js files with new modified times even though the sources themselves do not change, which means that the incremental build always think they changed even when they actually didn't.

Could there be an option to switch from mtimes to md5/sha1 hashes?

Actually it could even be both for speed reasons:
if mtime did not change, file did not change
else if hash did not change file did not change and update mtime
else file did change and update mtime and hash

Helpful code

export const generateHashEntryAsync = (filePath) => {
  const hash = crypto.createHash('sha1');
  const stream = fs.createReadStream(filePath);

  return new Promise((resolve, reject) => {
    stream.once('error', (err: Error) => {
      reject(err);
    });

    stream.on('data', (data: Buffer) => {
      hash.update(data);
    });

    stream.once('end', () => {
      resolve(hash.digest('base64'));
    });
  });
};

Support per file cache to allow concurrent build

Currently, the cache file is a big monolithic file.

I would like to run concurrent builds that share a lot of file in common, and use the same cache for all of them.
A good way to do it would be to provide a cachePath option, in which browserify-cache-api would write files named by the hash of the original file path.

To allow concurrent run and prevent the use of partially written cache file, each file could be written as . and then, when the file is fully written, rename it to .
As rename operations are atomic file system operations, there won't be bad cached data.

Modified files cache invalidation

Hi,

ref: https://github.com/jsdf/browserify-cache-api/blob/master/lib/invalidateModifiedFiles.js#L16
Shouldn't it be mtimeNew >= mtimes[file] instead of mtimeNew <= mtimes[file]?