Parcel: Two distinct files with the came content hash
🐛 bug report
Hi everyone! First of all, I wanted to thank you for making Parcel. It's perfect for my use case (a simple static site), except for this one issue that I've been running into recently. Unfortunately the issue is serious enough that I may have to switch to another application bundler if there isn't an easy fix.
The issue manifests itself in the form of file hashes not being computed correctly for CDN caching, resulting in fatal file naming collisions. This has affected me in production several times.
First, I'll describe the problem and show how to reproduce it with a simple example. I have three files: index.html, index.css, and an image called background.jpg (any image will do for this example).
index.html:
<html>
<head>
<link rel="stylesheet" href="index.css" />
</head>
<body>
Hello, World!
</body>
</html>
index.css:
body {
background-image: url("background.jpg");
}
Let's do a build:
parcel build index.html
✨ Built in 201ms.
dist/background.1bfa1abe.jpg ⚠️ 3.47 MB 12ms
dist/scratch.7b2665dc.css.map 204 B 3ms
dist/index.html 106 B 6ms
dist/scratch.7b2665dc.css 102 B 9ms
Ok, everything looks good! The generated dist/scratch.7b2665dc.css file will be relevant. Here's what's inside:
body{background-image:url(/background.1bfa1abe.jpg)}
/*# sourceMappingURL=/scratch.7b2665dc.css.map */
Now, let's change the image and do a fresh build. I changed the image by overwriting it with a different image:
$ cp other-image.jpg background.jpg
Now for a fresh build:
$ rm -rf dist && parcel build index.html
✨ Built in 585ms.
dist/background.f863f21b.jpg ⚠️ 2.29 MB 400ms
dist/scratch.7b2665dc.css.map 204 B 4ms
dist/index.html 106 B 6ms
dist/scratch.7b2665dc.css 102 B 8ms
As expected, the image now has a different hash. The generated CSS file has changed accordingly to point to the new image:
body{background-image:url(/background.f863f21b.jpg)}
/*# sourceMappingURL=/scratch.7b2665dc.css.map */
Wait—if the generated CSS file is different from before, it should have a different hash as well. But the hash hasn't changed; it's still 7b2665dc! This is the problem that this GitHub issue is about.
One might argue that this isn't a serious issue because even though the generated CSS is different, the source CSS hasn't changed. I will try to explain why this is in fact a serious issue. So, like most Parcel users (I imagine), I am aggressively caching the generated files with a CDN. Imagine the following sequence of events:
- I deploy the original version of the site described above (the one in which the CSS file points to
background.1bfa1abe.jpg). - The CSS file is cached by the CDN.
- I deploy the modified version of the site described above (the one in which the CSS file points to
background.f863f21b.jpg). - A user loads the site in their browser. Since the old CSS file and the new one both have the same URL, which version the user gets depends on whether the request is a cache hit or cache miss from the CDN. Suppose it's a cache hit and the user gets the old version. It points to
background.1bfa1abe.jpg, which is no longer being hosted by the server. If the CDN doesn't happen to have a cached version of that image, it will be a 404.
This leads to images failing to load in the browser. I'm not sure if this issue only affects images, or if other resource types could also break in this way.
This happened to me a few times in production. I spent a lot of time debugging it with my CDN, but eventually I traced the issue back to Parcel.
🎛 Configuration (.babelrc, package.json, cli command)
In the simple example above, I have no configuration files.
🤔 Expected Behavior
The hash of a generated file should change if the contents of the generated file change.
😯 Current Behavior
In certain situations (described above), the file hashes do not reflect changes. This behavior appears to interact poorly with CDNs.
💁 Possible Solution
I am not familiar with the internals of Parcel, but I'm hoping we can change the way file hashes are computed to prevent this issue.
🔦 Context
See above. Happy to clarify anything as needed.
💻 Code Sample
See above.
🌍 Your Environment
| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.12.4
| Node | 14.4.0
| npm/Yarn | NPM 6.14.5
| Operating System | Ubuntu 18.04
stepchowfun
All 5 comments
I don't think the Parcel devs are maintaining Parcel v1 anymore. I have fixed this problem myself by disabling content hashing using --no-content-hash (but obviously that's not an optimal solution).
101arrowz
on 28 Jun 2020
Huh—I'm using the latest version of parcel-bundler from NPM (https://www.npmjs.com/package/parcel-bundler), which I installed using the instructions in the Parcel documentation.
The Parcel devs aren't maintaining the latest version?
stepchowfun
on 28 Jun 2020
Nope, it's not the latest version. The latest version is parcel@next. Check the documentation in the README of the v2 branch (should be the default when you open this repository).
101arrowz
on 28 Jun 2020
Oh wow. The Parcel website should really be updated to point to the v2 docs by default if people are supposed to be using that version. Or if the v2 docs aren't ready (as is suggested by the website), then v1 should still be supported until v2 is ready.
stepchowfun
on 28 Jun 2020
This is definitely already fixed in v2.
devongovett
on 12 Oct 2020
Related issues
davidnagli
·
3Comments
davidnagli
·
3Comments
mnn
·
3Comments
jsftw86
·
3Comments
jzimmek
·
3Comments
Most helpful comment
Oh wow. The Parcel website should really be updated to point to the v2 docs by default if people are supposed to be using that version. Or if the v2 docs aren't ready (as is suggested by the website), then v1 should still be supported until v2 is ready.