Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zediah opened this issue Feb 26, 2023 · 3 comments
Open

Comments

@zediah
Copy link

zediah commented Feb 26, 2023

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
Copy link

GSBL commented May 4, 2023

we have the same problem

@JLHwung
Copy link
Contributor

JLHwung commented May 4, 2023

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.

@JLHwung
Copy link
Contributor

JLHwung commented Jul 11, 2024

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)

Thanks for the reminder, serializing options twice will be fixed in #909.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants