🐛 Fail to run with symbolic linked files under dir

[mizchi]

Environment information

Arch: Mac M1(Darwin-arm64)
Install: `npm i -g rome@next` (2022/04/11)

What happened?

Rome formatter failed to run on symbolic link under directory.

$ ls -al lib/
lrwxr-xr-x  1 kotaro.chikuba  staff    57B  4 11 19:52 foo.ts -> ../foo.ts

$ rome format lib/
lib/foo.ts: error[IO]: unhandled file type
Error: errors where emitted while formatting

My work around

$ rome format lib/**.ts

Rome ignores it.

Expected result

No error with format or just ignore. In any case, I need consistent behavior

Code of Conduct

• [X] I agree to follow Rome's Code of Conduct

[leops]

First of all I should note that symlink are not currently supported to avoid having to track for loops (since that would hinder the performances of directory traversals), but I admit the error message is not as explicit as it could be about that point.

Onto the error at at hand now, this might be a macOS-specific issue since on Linux (well WSL at least) the formatting is correctly failing on all cases: directory traversal format dir/, shell-based glob expansion format dir/**.ts and explicit file format dir/foo.ts (although in the last two case it's reporting "no such file or directory" so still not the correct error)

[ematipico]

I propose to update the website and add paragraph saying that at the moment we don't support symbolic links. What do you think @leops ?

It doesn't seem we plan to support symbolic links immediately?

[leops]

I propose to update the website and add paragraph saying that at the moment we don't support symbolic links. What do you think @leops ?

It doesn't seem we plan to support symbolic links immediately?

I agree we should update the documentation along with the error message to make it more explicit that symlinks are not supported at the moment. But I also think someone should take a closer look at it on macOS since apparently the error message is not being printed correctly in some cases (and maybe on Linux as well since the error I'm getting might be a WSL thing)

[ematipico]

I will take a look, I have macOS

[IWANABETHATGUY]

I could reproduce on linux, ubuntu 21

[IWANABETHATGUY]

I found that prettier also doesn't support handling symbol link.

[ematipico]

Running format and format --write on a symbolic link on macOS doesn't yield any errors. The command works as expected.

[leops]

Running format and format --write on a symbolic link on macOS doesn't yield any errors. The command works as expected.

One thing I'm concerned about is the coherence of the behavior of the CLI in different scenarios:

• Running the CLI on a symbolic link to a file
• Running the CLI on a symbolic link to a directory
• Running the CLI on a directory containing a symbolic link to a file
• Running the CLI on a directory containing a symbolic link to a directory

The last two are supposed to fail, but the first two may be OS dependent

[ematipico]

Then I suppose we should try to be consistent across OS?

More findings:

• I just tried using prettier on a single symbolic link to a file and it worked. (macOS)
• I just tried running rome and prettier on folder that contains a symbolic to a file and they worked. (macOS)

[leops]

I think the behavior we should implement consistently on all OS is that running the CLI on a symbolic link to a file should work, but running the CLI on a symbolic link to a directory or a directory containing a symbolic link should fail

[leops]

I improved the diagnostic emitted when a symbolic link is encountered in #3332, so there's at least a better explanation of why it fails now. I'm still going to leave this open until we get the platform inconsistencies sorted out.

[leops]

Fixed in #3706