Support for an advanced “persistentCache”#124
Conversation
…utside of the current memory.
readme.markdown
Outdated
| } | ||
| if (isInCache()) { | ||
| return cb(null, { | ||
| source: fs.readFileSync(file, 'utf8'), // String of the fully processed file |
There was a problem hiding this comment.
Since this is the "in cache" case, the example should probably show the contents coming from somewhere other than fs.
There was a problem hiding this comment.
It does now.
readme.markdown
Outdated
| // optional (can be null) stream that provides the data from | ||
| // the hard disk, can be provided in case the file data is used | ||
| // to evaluate the cache identifier | ||
| stream = fs.createReadStream(file) |
There was a problem hiding this comment.
Can there be a better example here, since this is what I expect fallback to be doing.
There was a problem hiding this comment.
I updated the example. it now uses a db.
index.js
Outdated
| fromSource(file, body.toString('utf8'), pkg, fakePath); | ||
| })) | ||
| ; | ||
| self.persistentCache(file, id, pkg, function fallback (stream, cb) { |
There was a problem hiding this comment.
Is it possible to move the fallback function somewhere other than an inline parameter here?
There was a problem hiding this comment.
Moved it to an outside scope.
- Used database instead of filesystem in the cache example. - Moved the fallback handler to a method one scope out.
|
@terinjokes Thank you for your review! I updated the PR. One thing to mention: I changed the implementation. Now the fallback takes an optional string instead of a stream. This change might seem odd, I came to the conclusion that this would be the better API when I tried to implement a cache. The cache could read the source in order to create a Key but if it did that with streams (i.e. to create a hash) then it would need to keep all the file data in memory and create yet another stream off of the in-memory data which would just make the impl. more complex without a real win for the module-deps. |
|
@terinjokes Thank you for approving the PR, how good are the chances for a merge? |
|
I'd prefer to have someone else take a look first. |
|
Whom would be good to ask? |
|
Looked into the |
| return true; | ||
| } | ||
|
|
||
| function toStream (dataAsString) { |
| } | ||
| }); | ||
|
|
||
| function getDeps (file, src) { |
|
|
||
| this.basedir = opts.basedir || process.cwd(); | ||
| this.persistentCache = opts.persistentCache || function (file, id, pkg, fallback, cb) { | ||
| setImmediate(function () { |
There was a problem hiding this comment.
͓̞̦̼͎. ̖̱̗̝͉͈Z̧̬͎̥͕̻̜AḺ̡̼G̝͓͘O̴̫̹̰̯͕!͈̱̟͈̕
Edit: let me extend: Since the implementation expects an async handler it felt only appropriate to uphold the contract in the default implementation
index.js
Outdated
|
|
||
| function persistentCacheFallback (dataAsString, cb) { | ||
| var stream | ||
| if (dataAsString) { |
There was a problem hiding this comment.
ternary? also semicolon styles missing here;
index.js
Outdated
| source: src, | ||
| package: pkg, | ||
| deps: deps.reduce(function (deps, dep) { | ||
| deps[dep] = true |
| // then you can pass `null` instead of the source and the fallback will | ||
| // fetch the data by itself. | ||
| // | ||
| fallback(fileData, function (error, cacheableEntry) { |
There was a problem hiding this comment.
where did fallback come from here? is missing from above description of function arguments.
test/cache_persistent.js
Outdated
| p.on('error', function (err) { t.equals(err.message, 'foo') }); | ||
| }); | ||
|
|
||
| test('allow passing of a different stream', function (t) { |
There was a problem hiding this comment.
what stream? do you mean a different string to fallback?
There was a problem hiding this comment.
Yes, it used to be a stream :)
|
Thanks for the review @ahdinosaur! Pushed a few fixes to the PR in regards to the linting. |
|
Two approved reviews 😃 |
|
@terinjokes @ahdinosaur Are the chances of a merge higher now with two Reviews? 😅 |
|
Note: I published an implementation of persistentCache here: https://github.com/martinheidegger/browserify-persist-fs |
|
Thanks everyone for reviewing this and going back and forth. Published as 4.1.0. |
|
We should also ping @jsdf and @royriojas upstream to make sure they know about this patch so they can make the best use of these changes. |
|
@martinheidegger hey, so the persistent cache breaks when using |
There are a few implementations of persistent caches for browserify such as
persistifyorbrowserify-incremental. But looking at each implementation it seemed like they struggle with the interface given bymodule-depsto cache: which is just an object lookup. This PR adds an additional cache interface tomodule-depsthat should make it possible to implement not just resource-efficient but also less hacky caching solutions for browserify.