Any opposition to making cacheDirectory default true?

[STRML]

Been fielding a lot of questions from webpack users about slow builds; enabling cacheDirectory usually helps a lot. Is there a good reason to keep it disabled by default?

[Couto]

My reasoning was that is not something that loaders do by default (in fact I only know babel-loader that has such option), and as such, users might not be aware of that option.

I'm not against turning it on by default, but I feel that it might be dangerous.

[STRML]

Understood - can you think of any instances in which it would be dangerous to do? Webpack (unfortunately) doesn't do file cache now but I believe it will in the near future of the 2.x branch. Plenty of other build tools do caching to /tmp, including npm itself.

Potentially we could run into a disk space issue, but properly-configured systems should be tmpreaping or something similar. Perhaps {cacheDirectory: NODE_ENV !== 'production'}?

[Couto]

Any ETA for Webpack 2.x ? It might not be worth the effort if they're planning to release it soon.
Otherwise, I'm open to PR ;) And disabling the cache when NODE_ENV is production sounds a safe measure!

[camjc]

Just realised that this option existed and got a big perf boost.

There will always be people using this package without reading through the readme (In my case I inherited the project, and I think the original was built using a scaffolder anyway).

Seems like this should be performant by default if possible.

[STRML]

Yeah I really don't see any reason to not make this default to /tmp.
On Jun 7, 2016 7:59 PM, "Cameron Chamberlain" notifications@github.com
wrote:

Just realised that this option existed and got a big perf boost.

There will always be people using this package without reading through the
readme (In my case I inherited the project, and I think the original was
built using a scaffolder anyway).

Seems like this should be performant by default if possible.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#199 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABJFP9o6i0HEFBqMj0tZz4mPfaC52_nHks5qJhPpgaJpZM4HDO1C
.

[kristianmandrup]

What are the use cases of cacheDirectory vs cacheIdentifier ?? can they be used in combination? See #324

[vjpr]

cacheDirectory defaulting to /tmp is a bad idea. So many issues caused by cache not being invalidated when it needs to be. Developer should always know exactly where their cache is.

[loganfsmyth]

I don't think I'm in favor of this. The cache doesn't invalidate well in all cases and means you're writing a bunch of files to disk that you might not actually want, like if you're doing a build for production.

[choskim]

@loganfsmyth, are there any downsides of setting cacheDirectory to true for only development? From my perspective, there's two potential problems. The first, that you mentioned, is cache invalidation. Do you have any examples of when this doesn't get done correctly? The second, when, if at all, does the cache get cleared?