Bundling fails without read permission to parent directories

[mitschabaude]

Hi, I am trying to use esbuild on an Ubuntu VPS where my $HOME directory is /usr/home/<USER>, but I don't have read permission to the parent folder /usr/home.

This causes bundling to fail with Cannot read directory ... permission denied

The error can be reproduced on any machine by mimicking the permissions layout:

sudo mkdir forbidden && sudo mkdir forbidden/repo
sudo chmod o-rw forbidden && sudo chmod a+w forbidden/repo
cd forbidden/repo
npm init -y
npm i esbuild react
echo 'import "react"' | npx esbuild --bundle

Output:

 > error: Cannot read directory "..": permission denied

 > <stdin>:1:7: error: Could not resolve "react" (mark it as external to exclude it from the bundle)

From my (ignorant) viewpoint it seems unnecessary to read anything above the package root when resolving node modules, so I thought esbuild could possibly prevent tripping up in this situation. (E.g. Webpack bundles without errors in the same situation.)

[kzc]

I did notice something similar for output file paths. Here's a contrived example for demonstration purposes:

$ esbuild --version
0.9.0
$ echo 'console.log(1 ? 2 : 3)' > 0.js
$ tty
/dev/ttys000
$ esbuild 0.js --minify --outfile=`tty`
console.log(2);

  ../../../../../dev/ttys000  16b 

⚡ Done in 2ms

Side note... not crazy about the need for the extra typing needed to disable the verbose output:

$ esbuild 0.js --minify --outfile=`tty` --log-level=error
console.log(2);

Although I'd prefer the way esbuild used to work with UNIX-style "silent by default except for errors", might you consider having --silent to be an alias for --log-level=error? Rollup is also verbose by default now (ugh) but it does feature a --silent option.

[nettybun]

@kzc Don't use --outfile=`tty` and it'll be silent.

$ esbuild --version
0.9.0
$ esbuild 0.js --minify
console.log(2);

[kzc]

@heyheyhello I prefaced my comment with:

Here's a contrived example for demonstration purposes:

[nettybun]

Yeah and your contrived example is great to show the ../../../../../ weirdness ✅ but if you care about esbuild's stdout for unix-pipe reasons then it should be good about that by default?

[kzc]

It was a side note based on the previous command. Here's a simpler example:

Compare the length of this command:

$ esbuild 0.js --outfile=out.js

  out.js  24b 

⚡ Done in 4ms

to this one:

$ esbuild 0.js --outfile=out.js --log-level=error
$ 

Once anyone has used esbuild once they never need to see the verbose output again and will have to type --log-level=error in all their build scripts for future projects to not clutter the console or their log files. Is it a big deal? No, it's not. It's just a minor annoyance. I just prefer more succinct commands and explicit opt-ins for nonessential information.

[nettybun]

I think the use case you're imagining is very different than a lot of developers... Personally I want to see the build size everytime I build. When esbuild used to not show it the first thing I'd do after was an ls -lh. I guess "essential" is subjective. I agree about adding a --silent flag though

[evanw]

This causes bundling to fail with Cannot read directory ... permission denied

Thanks for reporting this issue. I'm aware of the issue and it's come up once before here: #803 (comment). I gave fixing it a quick try then but I was unable to reproduce the issue myself (didn't try too hard at the time) and gave up. Even your repro instructions fail to cause the issue for me. I can give it another shot though.

The underlying reason is that esbuild makes heavy use of caching to avoid huge performance issues with node's path resolution algorithm. The algorithm is inherently inefficient because it involves making potentially hundreds of file system queries to resolve each individual import path (check all implicit file extensions * check package.json and implicit index files * check node_modules in all parent directories).

My implementation caches file system syscalls in the resolver to try to make this as efficient as possible. The cache in the resolver currently works by ensuring the parent directory is cached before caching a child directory, but that doesn't work if a parent directory is off-limits. Without investigating this myself first, I'm not totally sure what would need to change about the caching strategy to fix this problem correctly. But I agree that it should be fixed.

[mitschabaude]

Cool, thanks for the explanation!

@ Repro: For context, the commands above were run on Ubuntu 20.10, several times with the unreadable directory at different levels above the root, and always caused the issue for me.