Is the cache unreliable for everyone or just me?

[jaredkrinke]

Does anyone else have to periodically delete .parcel-cache to get Parcel to pick up changes?

I'm using Parcel 2.7.0 on Windows 10 (on my system drive), and I frequently encounter the following when developing locally (and I don't have any symlinks involved or anything like that--the file I'm updating is e.g. ./ts/something.ts in my project):

1. Update some code (I'm using HTML and TypeScript)
2. Go test the update (via parcel serve index.html)
3. Notice that the change didn't work as intended
4. Manually reload the page in my browser, to no avail
5. Kill Parcel, delete .parcel-cache, and restart Parcel
6. Now everything works as expected

I don't know anything about Parcel's cache, but it seems like this indicates that the cache isn't working as intended.

Unfortunately, I don't know how to trigger this sequence (or if parcel build has any effect), but it's happened to me probably at least 10 times in the last couple of months. I just switched my scripts to all use --no-cache to see if this problem recurs or not.

The only cache bugs/discussions I saw seemed to be related to symlinks or other fancier setups.

[devongovett]

I haven't seen this, but I have seen browser caches sometimes not get purged. Haven't figured out why yet. Sometimes Shift clicking the reload button in the browser fixes it.

[jaredkrinke]

I'm not 100% sure, but I think I tried Shift/Ctrl+Reload to no avail (as well as restarting Parcel). I'll also try InPrivate mode next time to see if that helps. I don't think it's a browser cache issue, however.

[Theelx]

I'm having the same issue with Parcel 2.6.x and 2.7.x, though I haven't tried it on earlier versions of 2.x.x. It worked fine on Parcel v1. I'm running a React+HTML+JS site on an Ubuntu 20.04 VPS, and there aren't any symlinks or other fancy file system things going on in the build directory. I just have a bash script to run the build process twice every time the site is updated, and it kills parcel, deletes .parcel-cache, and restarts parcel every time. Even doing all that though, it sometimes fails if I only build it once. So yeah, even the steps you're taking don't fix it for me 100% of the time.

[jaredkrinke]

I've never had an issue with deleting the Parcel cache and rebuilding, so I suspect something else is going on in your case (e.g. state is being left somewhere or maybe even impending hardware failure).

[newtriks]

We're on 2.5.0 and I get frequent reports from other team members of issues with caching since we upgraded to v2. These issues have to be resolved using a similar process mentioned above e.g. delete cache and restart parcel. It's a bit of a pain as it's not immediate that the cache is the issue, so some time does get wasted admittedly to the end up realising it's the parcel cache again. We have a monorepo setup, React based and primarily use Chrome if that helps @devongovett. Hard reload doesn't fix this for us.

[jaredkrinke]

One theory: is this triggered by NPM dependencies that are installed via relative paths?

The most recent time I hit this was I updated a package elsewhere in my monorepo. That package was a dependency (added by relative path) of the package I was building with Parcel.

[Theelx]

That theory sounds plausible, we have a monorepo too using relative paths.

[mischnic]

It would be great if someone could provide a reproduction (repo and/or steps. So something like: "delete the cache, build, do x, build, now Parcel is broken until the cache is cleared") for this situation where deleting .parcel-cache is required. Otherwise there's no way to figure out the problem and fix it.

[jaredkrinke]

I’m planning to test my theory above later today. If that triggers the problem, it should be trivial for me to provide a repro. If not, then I think the steps to reproduce are still a mystery.

[jaredkrinke]

Opened #8638 with more information and a link to this repro:

https://github.com/jaredkrinke/parcel-cache-repro

I'm fairly certain that this was the scenario I was hitting. Not sure about other reports in this thread, but it seems likely.

[AndrewKvalheim]

The cache has always been unreliable for me. Occasionally I try enabling it, get corrupted builds, and just disable it again.

[helgihg]

It's not just unreliable, it's outright broken and should be disabled by default.

This is my start command in package.json now, having wasted an infuriating amount of time on trying to fix things that turned out to just be cache shenanigans:

rm -rf .parcel-cache && parcel --no-cache