Babel-loader Cache - unable to cache in changing directory environment

[zediah]

I'm submitting a feature request
Webpack Version:
5.75.0

Babel Core Version:
7.20.2

Babel Loader Version:
9.1.0

Please tell us about your environment:
Windows 11

Current behavior:
When babel-loader creates the hash for the cache filename, it always takes into account the 'options' object. This object contains all the options used as well as details such as the current full path (e.g. cwd property). That means when creating the hash file, it is sensitive to any changes to the fully qualified path and the hash will change if this path changes.

Note: passing a cacheIdentifier does not bypass this behaviour. See this line where the options object is passed in anyway https://github.com/babel/babel-loader/blob/main/src/cache.js#L73 . Is this maybe a bug? Should babel-loader be serialising options twice to generate the hash? (once for default cacheIdentifier, once again for the line mentioned)

Expected/desired behavior:
In an environment where the fully qualified path changes between each run (but not the path relative to the project itself), it would be great to be able to still have a cache for these files.

What is the motivation / use case for changing the behavior?
We currently use Heroku as our all-in-one platform for our product and the build system within it runs the build under a new directory on every run (i.e. /tmp/build_${buildNumber}). Due to the nature of how the hash is created, it's impossible for us to utilise the babel-loader cache between builds, making them take a lot longer than necessary :(

I'm really not sure the best path to follow for a solution here - it could be as simple as not passing in options and trusting the cacheIdentifier when creating the hash. But there's probably a good reason that's being passed in too. It could also be about adding the ability to have it use relative paths for the caching hash.

[GSBL]

we have the same problem

[JLHwung]

In an environment where the fully qualified path changes between each run (but not the path relative to the project itself), it would be great to be able to still have a cache for these files.

In this situation, babel-loader can't trust the cache and assume the output is stable, because:

1. A full qualified path has impact on sourcemaps generation
2. A Babel plugin can read the file path and emit it to the output, either as a string literal / comment.

The loader is very much agnostic about plugins/options, so it has to be conservative: A cache miss does mean longer build time but we can't risk incorrect build due to invalid cache.