Update webpack + pack mode #189
Conversation
this makes sure that idle tasks are completed (like persisting cache)
Codecov Report
@@ Coverage Diff @@
## master #189 +/- ##
=========================================
+ Coverage 67.65% 67.7% +0.05%
=========================================
Files 12 12
Lines 575 576 +1
=========================================
+ Hits 389 390 +1
Misses 186 186
Continue to review full report at Codecov.
|
| @@ -54,8 +54,7 @@ module.exports = ( | |||
| type: "filesystem", | |||
| cacheDirectory: typeof cache === 'string' ? cache : nccCacheDir, | |||
| name: "ncc", | |||
| version: require('../package.json').version, | |||
| store: "instant" | |||
There was a problem hiding this comment.
If switching to the pack mode, should we also now ensure that the cache is a per-project cache in the node_modules folder instead of the single global cache?
There was a problem hiding this comment.
That would make sense.
Another option is to keep the cache location, but use a different cache.name for each directory.
Like this: name: hashOf(directory)
There was a problem hiding this comment.
The risk with the global cache with this new storage seems to be disk usage growth right?
I guess this can be mitigated with a simple eviction strategy in due course. But that was another argument for per-project caching.
The argument for global caching is that ideally it would be great if the global cache could be smart enough to know the hashes of the dependencies (yarn.lock again!), and thus share compilations.
Not sure which of the above you want to shoot for here, but will trust your judgement!
There was a problem hiding this comment.
The per-project cache is garbage-collected, so disk usage should increase only with the number of different entries used on a computer.
| name: "ncc", | ||
| version: require('../package.json').version, | ||
| store: "instant" | ||
| name: `ncc_${hashOf(entry)}`, |
There was a problem hiding this comment.
Should this not be a hash of the project directory, so that if the input changes the cache can still be used?
There was a problem hiding this comment.
I've thought about that, but decided against it.
This could be a problem when using ncc for multiple entries in a single directory. They would override the cached generated output files in the cache. This would slow down the rebuilds when switching between these these entries.
This configuration provides consistent fast rebuilds at the cost of high initial build for each entry.
But choosing the other way is also a valid trade-off. I assumed # of rebuilds >> # of initial builds and people may run ncc for multiple entries in parallel.
packstore mode (better performance)