watch bug with logLevel: "debug" on Linux

[ehowe]

I believe I have found a bug that appears to be specific to linux. I'm unable to reproduce it on my Mac, but it happens every time on my Linux machine. I've made a minimum viable example to reproduce this:

app.ts:

const test = 'asdf'

console.log('test')

esbuild.js:

import esbuild from 'esbuild'

esbuild.build({
  entryPoints: ["app.ts"],
  outfile: "app.js",
  watch: true,
  logLevel: "debug",
}).catch((err) => {
  console.error(err);
  process.exit(1);
});

The issue is that the watch directory ends up traversing outside of the project directory and building infinitely:

> node esbuild.js

[watch] build finished, watching for changes...
[watch] build started (change: "../..")
[watch] build finished
[watch] build started (change: "../..")
[watch] build finished
[watch] build started (change: "../..")
[watch] build finished
.... and on and on forever and ever and ever

However, this doesn't happen if change logLevel to info.

esbuild version: 0.15.13
distro: Linux Mint 21 (Ubuntu 22.04 LTS)
node version: Probably doesn't matter but I reproduced on multiple node versions (16 and 19)

[evanw]

I think I can reproduce this on Mac if I run this in the terminal in my home directory:

while true; do touch foo; sleep 0.1; rm foo; sleep 0.1; done

So maybe your Linux system has some process that is repeatedly creating and destroying a file like this? I'll investigate this on the esbuild end of things.

[ehowe]

Thanks! The other relevant part of the reported issue is that the ../../ part is above the top level of the project, like it fails to properly identify the project root with debug set. I wouldn't be surprised if something was writing to that directory because its literally my entire home directory in this case.

[evanw]

It looks like this is caused by this code here:

esbuild/internal/resolver/resolver.go

Lines 918 to 923 in ba47710

	count := len(cached.entries.SortedKeys())
	entries := "entries"
	if count == 1 {
	entries = "entry"
	}
	r.debugLogs.addNote(fmt.Sprintf("Read %d %s for directory %q", count, entries, path))

When debugging is enabled, the path resolution subsystem is generating a log message that says something like "Read 20 entries for directory /home/user". This causes the file subsystem to add a dependency on the full list of entries in that directory since if that changes, the generated log message would also have to be updated.

Arguably the content of log messages could be considered not important as far as watch mode is concerned, so perhaps this code could "peek" at the file subsystem's state without it recording that the state was observed.