Skip to content

Expose a way to recover when using unsafeCache (for file extension changes) #8277

@saifelse

Description

@saifelse

Feature request

What is the expected behavior?
Renaming a file from *.js to *.ts extension should not break webpack's watch mode.

What is motivation or use case for adding/changing the behavior?
By default, webpack is configured to use "unsafeCache", which generally speeds things up, by avoiding hitting the filesystem continuously. The docs say that this is rare, but in actuality, it can be quite common when gradually porting files over from one language to another (e.g. *.js --> *.ts). When a developer ports a single file, all other developers that pull in this change are forced to restart webpack, which can be a big productivity drain.

Disabling unsafeCache is one workaround, but the performance regression is quite notable.

How should this be implemented in your opinion?
In an ideal world, I think every plugin that uses this sort of caching, should tap a compiler hook to clean up its cache so that on next compile it can recover. It's a bit odd that an object can be passed into unsafeCache to allow the caller to control this particular cache, but other caches involve reaching into internals to recover.

Note that up until #7348, all necessary information was actually available for one to write a plugin that does this recovery (and in fact broke a custom plugin that I've been using):

A quick fix that re-enables this functionality is to expose methods for resetting normalModuleFactor's dependencyCache.

Are you willing to work on this yourself?
yes

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions