Attempt to track cache dependencies for synchronous loaded resources

[rjgotten]

Modification Proposal

The Less loader uses a custom implementation of the Less implementation's FileManager API to support Webpack-based resolution of paths and application of loader pipelines; etc.

Less relies on synchronous loads in a few places. Notably: in the built-in data-uri function; but also in any custom function added to Less via Less compiler plugins - which can also be inlined via the @plugin import keyword. (Because Less functions can't return async results.)

Webpack stopped supporting synchronous resolves and synchronous loads. And so, the Less loader implements a file manager that explicitly signals to Less it cannot support synchronous loads and that it should be skipped (and the default manager should be used). As part of this workaround, it also means any file loaded by data-uri or by custom Less functions will not be tracked as a dependency within Webpack. This means cached build output from Webpack will be kept and will not be refreshed when only the synchronously loaded file is somehow changed.

I would propose to modify this behavior slightly:
We still can't do synchronous resolves and loads properly; but at the least, we could have the Less loader's file manager implement synchronous file loading by delegating back to the default (rather than signaling synchronous loads are not supported) while also asynchronously resolving; loading; and tracking the dependency. Basically; you get a list of secondary 'cache dependency' promises running next to the main Less compiler in the loader. And the loader's overall compilation result is not returned until all of it is done.

The results of these resolves would basically be thrown away; but at least it would start correctly counting everything as cache dependencies for the 99% use case where there are no custom resolvers or loaders at play. (Which logically there wouldn't be; because they wouldn't apply correctly to the Less files being compiled anyway, and users would experience that as an error and would back out of doing what they're attempting to do because it would be functionally broken.)

Expected Behavior / Situation

Even if synchronous file loads are not supported, they are tracked as build & cache dependencies.

Actual Behavior / Situation

Synchronous file loads are not supported and are not tracked as build or cache dependencies, leading to failure to properly rebuild Less files when Webpack's persistent cache is enabled and only the untracked dependency is chacnged.

Please paste the results of npx webpack-cli info here, and mention other relevant information

Packages:
    css-loader: ^6.7.1 => 6.7.1
    less-loader: ^11.0.0 => 11.0.0
    webpack: ^5.74.0 => 5.74.0
    webpack-cli: ^4.10.0 => 4.10.0
    webpack-dev-server: ^4.11.0 => 4.11.0
    webpack-sources: ^3.2.3 => 3.2.3

(NOTE: further information including system details withheld because functionally irrelevant and I have a policy to not leak system or environment details publicly unless absolutely necessary.)

[alexander-akait]

Last time when I tried it, it did not work due bugs in Less, if you have time and working example - PR welcome.