New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prettier should be able to resolve symlinks when explicitly passed. #15723
Comments
lmao, what is the prettier team doing |
I addressed this issue in #15533. Please upvote or review there. |
@sosukesuzuki you are not reducing complexity, you are sabotaging developers, today. thinking that prettier is that solution, is comical. AI will replace you + this repo. |
Is it now possible to use symlinks or I should revert to 2.8.8 ? |
It's not possible. It requires some implementation work. |
can we expect it in future versions? |
I don't know. I made a PR and I'm not much of a JavaScript programmer. Maybe you can too? |
I don't understand either, but this was a deliberate choice. |
Environments:
Steps to reproduce:
This change was introduced here. #14627
Expected behavior:
Prettier doesn't seem to have a way for a user to supply explicit paths that should be allowed to resolve symlinks. There are a number of reasons why symlinks might be used. For my use case, I'm using
bazel
to build and test. One of the core things bazel does to ensure hermeticity is to sandbox each execution. A sandbox will only have the required inputs and outputs for each action. To create these sandboxes quickly on Mac symlinks are used not to copy the files all the time.Missed this in my CI system since Linux sandboxes in a slightly different way and creates hard links that then get cleaned up.
Actual behavior:
Fails when a symlink is passed.
It would be nice if there was a way to turn off this check as an option on the CLI or in the config. Since the issue, this was trying to fix where circular links cause a stack overflow, which won't happen if the symlinks are created in a reasonable way. Allowing a user to opt into turning off this check seems to me the correct way to go. When someone is setting up the tool for the first time they still have the default protection in default behavior but allowing this to be turned off allows for more complicated workflows that are currently broken.
The text was updated successfully, but these errors were encountered: