babel-loader icon indicating copy to clipboard operation
babel-loader copied to clipboard

cacheDirectory option default to false is not honoured

Open vincenzo opened this issue 7 years ago • 2 comments

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:

  1. I don't set cacheDirectory anywhere
  2. I get a babel-loader cache located at node_modules/.cache/babel-loader

Expected/desired behavior:

  1. I don't set cacheDirectory anywhere
  2. 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.

vincenzo avatar Oct 16 '18 14:10 vincenzo

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.

loganfsmyth avatar Oct 16 '18 15:10 loganfsmyth

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.

vincenzo avatar Oct 16 '18 20:10 vincenzo