fix: inconsistent filepath separators

[seleb]

Hey there! Ran into the issue described in #3631 where filepaths are being formatted inconsistently on a windows dev machine, and this seems to prevent the dev server from updating to show new content.

Sample result from _globSearch when the server is started with test1.md, and then a new file test2.md is added:

[
  './content/blog/test1.md',
  './content\\blog\\test2.md',
]

The inconsistent format in the newly added file seems to be carried through all the way into the templates without ever being normalized.

This is a bit of a naive fix, but not sure if there's a better place upstream to place it. I'm not familiar with the specifics but it looks like historically there was transformation between templateGlobs and normalizedTemplateGlobs which may be related?

It's also possible this is a bug in fast-glob, which appears to be responsible for performing the actual search, but as this causes issues with the 11ty dev server I figured it'd be worth raising a PR where there's a known user-facing issue/possible fix and let the maintainers make that call.

[Ryuno-Ki]

Using path.sep would work here, too?

Instead of an IIFE for the promise I think it's okay to add another temporary variable.

Suggested change

	})).map(i => i.replace(/\\/g, '/'));
	const results = await this.fileSystemSearch.search("templates", globs, {
	ignore: this.uniqueIgnores,
	});
	return results.map(i => i.replace(new RegExp(path.sep, 'g'), '/'));

Untested, as I'm on Debian Linux.

[seleb]

I'll add the temporary variable for clarity, but path.sep would not work here without being escaped. I don't think there'd be any benefit in using it either: replacing linux path separators would not do anything.

[zachleat]

Testing a issue-3632 branch that makes use of our TemplatePath.standardizeFilePath utility from @11ty/eleventy-utils for this purpose:

Test run https://github.com/11ty/eleventy/actions/runs/13642618315
Issues https://github.com/11ty/eleventy/compare/issue-3632

[zachleat]

After a deeper dive into #3631 this wasn’t the root cause, though I appreciate the help and will still apply the (modified) change (TemplatePath.standardizeFilePath) you suggested!