Config file (.eleventy.js) dependencies in watch/serve mode are found but not reloaded

[TigersWay]

Describe the bug It seems that any change over .eleventy.js dependencies - like filters, shortcodes, etc - is detected but not reloaded. The change is not applied.

To Reproduce With this kind of line: eleventyConfig.addFilter('outside_filter', require('./site/filters.js').outside_filter);, any change to the file while running in watch/serve mode, will be logged: [11ty] File changed: site\filters.js as expected. But the old code is "still cached".

repo

[zachleat]

HMM, your test case works for me on Mac OS Monterey. Can anyone else confirm? Are you on Windows?

[TigersWay]

Was on Windows 10 last time. Now on Windows 11 with the exact same result! The change is logged but the modification is not there (cache maybe?).

[TigersWay]

Just in case.... I'm usually working with VSCode with the terminal set as "Git bash", and script-shell=C:\Program Files\git\bin\bash.exe in .npmrc. I'm also using pnpm not npm.

I tried all the possible combinations I could imagine down to bare "windows cmd" and npm for the exact same result: Both changes to index.md or filter.js are detected, only the index.md ones are served in the same run.

[lukeliasi]

Getting the same issue on Linux, think this is related https://github.com/11ty/eleventy/issues/1052

The fix for this will ship with 2.0.0-canary.11

[kentaroi]

The cause of this bug is that file paths in EleventyWatch are platform-dependent style and those in the other parts of Eleventy, in this case EleventyWatchTargets, are posix style.

This inconsistency makes this.watchManager.hasQueuedFile(dep) returns always false on Windows (Eleventy.js#L677), which makes _shouldResetConfig() return false. https://github.com/11ty/eleventy/blob/e9ca971210fa06efd2af3a7931ef368dcb085a79/src/Eleventy.js#L665-L687

(this.watchManager.activeQueue is [ "./site\\filters.js"] on Windows, but dep is "./site/filters.js" at Eleventy.js#L677, when you change ./site/filters.js in the provided project.)

I wonder if the platform-dependent style of paths in EleventyWatch is intentional or not.

If it is intentional this should be fixed in hasQueuedFile() in EleventyWatch, for example.

However, if the platform-dependent style of paths in EleventyWatch is a mistake, it will be fixed in addToPendingQueue() in EleventyWatch by replacing path = TemplatePath.addLeadingDotSlash(path); with path = TemplatePath.addLeadingDotSlash(TemplatePath.normalize(path));. https://github.com/11ty/eleventy/blob/e9ca971210fa06efd2af3a7931ef368dcb085a79/src/EleventyWatch.js#L97-L102

[TigersWay]

Just did a quick test hoping one/some of the last commits would have solved the problem.... It did!!!

Can anyone else confirm? I would love to close this 😃

[zachleat]

I believe this was a dupe of #1312

[druskus20]

I believe I still have this issue. I add all my shortcodes in a loop as follows:

.eleventy.js

config.addWatchTarget('./_includes/shortcodes/*.js');
const shortcode_files = require("fs").readdirSync("./_includes/shortcodes");
for (const file of shortcode_files) {
  const shortcode = require(`./_includes/shortcodes/${file}`);
  config.addShortcode(shortcode.name, shortcode.function);
}

_includes/shortcodes/myshortcode.js

module.exports = {
    name: "myshortcode",
    function: myshortcode,
};

function myshortcode() {
    return "MYSHORTCODE"
}

My eleventy version is 2.0.0-canary.23. I must add that I am running Windows 10, I will try tomorrow from Linux

Basically, I have to stop eleventy serve and re-run the whole thing for it to update the website

[zachleat]

@druskus20 2.0.0-beta.2 has some additional fixes for config reloads, please retest! Via #2773

[druskus20]

Seems to work now, thanks for letting me know!