Use content-hash to invalidate cache #1006
Conversation
fvictorio
force-pushed
the
content-hash-cache
branch
from
b97a581
to
2097d23
Compare
| throw new Error("Couldn't read cache file, try running the clean task"); // TODO use HardhatError | ||
| log("There was a problem reading the cache"); | ||
|
|
||
| return new SolidityFilesCache({ |
There was a problem hiding this comment.
This will clean the cache as soon as the user upgrades, right?
There was a problem hiding this comment.
I mean, because of the change in the cache file format.
There was a problem hiding this comment.
Yes, I forgot to add a comment about this.
I think in an ideal world we would handle changes in the files format in a graceful way. For example: detecting that the file has the format v1 but the code expects format v2, and acting accordingly. But in this case, just ignoring everything and starting over is both easier and (I think) correct. We might need to change this approach in the future, but for now I think this is enough.
| contentHash: string | ||
| ): ParsedData | null { | ||
| if (this._solidityFilesCache === undefined) { | ||
| return this._cache.get(absolutePath) ?? null; |
There was a problem hiding this comment.
What if we use the content hash instead of the absolute path here? I think it will be more robust. I can imagine using the absolutePath bringing issues for things like the hardhat-watcher plugin.
| const cacheEntry = this._solidityFilesCache.getEntry(absolutePath); | ||
|
|
||
| if (cacheEntry === undefined) { | ||
| return this._cache.get(absolutePath) ?? null; |
You mean we keep the |
No description provided.