cacheDirectory option default to false is not honoured
I'm submitting a bug report
Babel Core Version: 6.x
Babel Loader Version: 7.1.2
Please tell us about your environment: Linux
Current behavior:
- I don't set
cacheDirectoryanywhere - I get a babel-loader cache located at
node_modules/.cache/babel-loader
Expected/desired behavior:
- I don't set
cacheDirectoryanywhere - I do not get any cache anywhere because the documentation says that the default is
false
I would also argue that the default localtion (in case of blank or true value for cacheDirectory) of node_modules/.cache/babel-loader is bad practice. Professional production deployments will have node_modules to be readonly after build anyway.
I suggest that this option could really have only two values: true or false. When true, the cache directory should be located in the OS default temp dir.
I'm not sure what to tell you, that option definitely only has an effect if explicitly set to a truthy value: https://github.com/babel/babel-loader/blob/1ca5c7856d2129a28d6ba031bd8a5759aa80b8eb/src/index.js#L163 Can you create a reproduction repository?
I would also argue that the default localtion (in case of blank or true value for cacheDirectory) of node_modules/.cache/babel-loader is bad practice.
You are free to set the cache location to any value you'd like. We follow the same pattern that the AVA test framework does. We could alternatively use a .cache in the project root itself but that's just one more folder you have to .gitignore and such. I also don't personally find the idea of putting the cache outside of the project itself very compelling, because then it's harder to know what files are being written where, and I may not want files related to my project being written to random other directories.
Professional production deployments will have node_modules to be readonly after build anyway.
We don't generally recommend using this option in production builds anyway because it can at times fail to invalidate its caches. I'd only ever use it during local development.
Unfortunately, I can't easily create a reproduction repo. I'll try, though, if I can't find the root of the issue. We're definitely not setting that option anywhere, in fact I had to set it to false explicitly.