Node Less.js wrongly caches @imported file content between builds

[akx]

Heya,

I've just bumped into an intriguing problem which smells like Less.js caching @imported files between builds.

I have a chokidar-based watcher for LESS – nothing spectacular. Today I noticed that my stylesheets weren't getting updated when I edited an @imported file; Chokidar picks up on the change and has LESS rebuild the files, but the hashes remain the same. The guts of that watcher ended up in the minimal repro project you can find at https://github.com/akx/less-cache-bug .

The repro project basically creates an included file, compiles to CSS and prints the result's hash, edits the included file, compiles and prints the hash again. The hash should naturally change between the compilations, and it does not. There is no mention of a cache for the Node compiler anywhere in the docs, so I'll assume this is a bug.

However, it looks like you can work around this by creating your own LESS compiler instance (as less/lib/less-node does for each run.

EDIT: The same problem appears if the LESS compiler instances share the FileManager/URLFileManager objects, so it's gotta be them.

This is the output of the repro project:

Global LESS
Hash: 1887f95d518b56366082952717d3bffc7eac4b60
Hash: 1887f95d518b56366082952717d3bffc7eac4b60
New LESS per compilation
Hash: 1887f95d518b56366082952717d3bffc7eac4b60
Hash: 38ed2655f5251910b378e6945c1837ba1e32b395

[akx]

Also, here's a macOS fs_usage log of what's going on.

The global LESS instance doesn't even try to open included.less again (as assumed).

19:49:45.029615  open (_WC_T_)  ./included.less  # Test program writes included.less 1
19:49:45.032254  open (R_____)  ./style.less     # Global LESS opens style.less
19:49:45.045207  open (R_____)  included.less  	 # Global LESS opens included.less
19:49:45.055932  open (_WC_T_)  ./style.css      # Test program writes style.css
19:49:45.055938  open (_WC_T_)  ./style.css.map  # Test program writes style.css.map

19:49:45.056901  open (_WC_T_)  ./included.less  # Test program writes included.less 2
19:49:45.057286  open (R_____)  ./style.less     # Global LESS opens style.less
                                                 # <-- Global LESS does _not_ read included.less
19:49:45.059394  open (_WC_T_)  ./style.css      # Test program writes style.css
19:49:45.059611  open (_WC_T_)  ./style.css.map  # Test program writes style.css

19:50:19.574302  open (_WC_T_)  ./included.less  # Test program writes included.less 1
19:50:19.575975  open (R_____)  ./style.less     # LESS Instance 1 opens style.less
19:50:19.576740  open (R_____)  included.less    # LESS Instance 1 opens included.less
19:50:19.577809  open (_WC_T_)  ./style.css.map  # Test program writes style.css.map
19:50:19.577822  open (_WC_T_)  ./style.css      # Test program writes style.css

19:50:19.578338  open (_WC_T_)  ./included.less  # Test program writes included.less 2
19:50:19.579870  open (R_____)  ./style.less     # LESS Instance 2 opens style.less
19:50:19.580626  open (R_____)  included.less    # LESS Instance 2 opens included.less
19:50:19.581756  open (_WC_T_)  ./style.css.map  # Test program writes style.css.map
19:50:19.581830  open (_WC_T_)  ./style.css      # Test program writes style.css

[akx]

Ah, it seems it's the cache added to FileManager in 9fd1ef5 / 4272871 .

The original commit does say it's a WIP, so maybe the changes have slipped in as release-ready accidentally?

[akx]

Another workaround:

  less.environment.fileManagers.forEach((fileManager) => {
    if (typeof fileManager.contents === 'object') {
      fileManager.contents = {};
    }
  });

prior to compilation.

[matthew-dean]

Have you checked Less 3.5 beta 5? I believe this is a duplicate of a reported (fixed) issue, but I’m not at my PC. Please see if it’s addressed in the latest beta release.

…

On Jul 2, 2018, at 10:09 AM, Aarni Koskela ***@***.***> wrote: Another workaround: less.environment.fileManagers.forEach((fileManager) => { if (typeof fileManager.contents === 'object') { fileManager.contents = {}; } }); prior to compilation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[akx]

@matthew-dean Ah, yeah, I found #3185 / #3219 now.

Looks like this issue is indeed a duplicate and probably will be fixed in that version...

[matthew-dean]

👍