Webpack 5 Custom Unsafe Resolver Cache Issue with File Extension Changes #18089
Replies: 3 comments
-
Hello, we have
We have the Anyway if you create a small reproducible example I can look and give advices more deeply, thank you |
Beta Was this translation helpful? Give feedback.
-
Thank you for your suggestion to use the As requested, I've created a minimal reproducible example to demonstrate the issue. Let me know what you find, and thanks again! https://github.com/jpbriggs408/Webpack-UnsafeCache-ModuleBuildError-Repro |
Beta Was this translation helpful? Give feedback.
-
I wanted to share an update on the Webpack 5 caching issue we've been experiencing. After thorough investigation, we discovered that our custom Proxy cache object is being overwritten. Specifically, the In As such, I have opened an issue with some more details. Looking forward to discussing how we can best solve this, if you are open to changing this behavior. |
Beta Was this translation helpful? Give feedback.
-
Hello Webpack Team,
We've encountered an issue while upgrading to Webpack 5, specifically related to our implementation of a custom object for
resolve.unsafeCache
to handle file extension changes without causing build failures.Background
In Webpack 4, we faced challenges with
resolve.unsafeCache
. We raised those issues with the Webpack team at the time and the feedback was received positively, resulting in an update to Webpack's documentation. See here for more context: #10771.The TLDR is that turning it off resulted in slow reload times, while having it on caused build failures when a file was moved or renamed due to the cache pointing to a non-existent file. We found a workaround by implementing a custom cache object and passing it to
resolve.unsafeCache
, which checks for the existence of a file on a cache hit and deletes the cache entry if the file does not exist. This solution maintained performance benefits without leading to file not found errors.Issue
After upgrading to Webpack 5, we've continued using our custom cache object strategy. However, we're experiencing similar build failures that we had initially aimed to avoid with this approach. It seems the custom object is not functioning as intended with Webpack 5's handling of the cache.
Example Configuration
Questions
Have there been a change in Webpack 5 that could affect the behavior of a custom cache object passed to
resolve.unsafeCache
?Are there recommended practices or alternative approaches for handling dynamic file extension changes (e.g., JS to TS) in Webpack 5 to avoid such build failures without sacrificing build performance? Our users are unable to rename files, switch branches, etc. without restarting the service.
Previous Context
This approach was initially adopted to mitigate issues encountered in Webpack 4. Our journey and the challenges faced were discussed in these GitHub issues: webpack#10771 and webpack#7976 (comment), which provide additional context and related discussions.
Environment
Webpack version: 5.89.0
Node.js version: 16.13.2
Operating System: CentOS 7
We are seeking guidance on how to adapt our custom cache strategy for Webpack 5 or if there are new recommended approaches to handling this scenario. Any assistance or insights would be greatly appreciated.
Thank you for your time and support.
Beta Was this translation helpful? Give feedback.
All reactions