github pages
browserify-cache-api's Introduction
browserify-cache-api's People
Forkers
snaptv justjake fatman2021 ahdinosaur dantman macil olegskl evenius vancoding redhatter oroce congelli501 lwoydziak ilmarinen100browserify-cache-api's Issues
CONCURRENCY_LIMIT leak detected
When will the next patch be released?
I see that this issue:
Line 11 in f9d06fb
Is resolved in master, but not in the 1.5.0 version currently released.
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'));
});
});
};
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?
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]
?
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.