Skip to content
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

VS Code extension #129

Open
bluebrown opened this issue Jul 22, 2023 · 4 comments
Open

VS Code extension #129

bluebrown opened this issue Jul 22, 2023 · 4 comments

Comments

@bluebrown
Copy link

bluebrown commented Jul 22, 2023

Hi, I created a VS Code extension wrapping yamlfmt: https://marketplace.visualstudio.com/items?itemName=bluebrown.yamlfmt. Maybe you could mention it in your README.

If you have ideas for adjusting this to your liking, I am open for it.

@braydonk
Copy link
Collaborator

Hi @bluebrown very cool! Thank you for making this, I will add it to the README soon.

I think it would be great if there was a way to have it look in the project directory for a .yamlfmt file. I don't know much about developing VSCode extensions so I am not sure how feasible this is, but the editorconfig extension seems to do this somehow.

Also, would being able to load JSON for a yamlfmt config make it possible to have yamlfmt config embedded into settings.json? Cause that would be a pretty easy feature to add, and would be another cool way to be able to configure the extension.

Thank you very much for making this, and I will mention it in the README soon!

@bluebrown
Copy link
Author

bluebrown commented Jul 22, 2023

Hi, thanks for the feedback.

I made it so that it runs with the workspace folder as current workdir for yamlfmt. So that would be the project dir, I guess. VS Code supports multi root workspaces, so each workspace root can have its own .yamlfmt file.
So for the standard user, dropping a .yamlfmt at their project root is enough.

Additionally, the file can be put in the usual places like XDG_CONFIG_HOME

And I have it so that you can pass extra args to binary, so it's possible to use -conf or -formatter flag, globally or per project.

Regarding embedding the config in the settings.json. I have thought about it but decided against it. I guess the rationale is similar to something like ESLint, which also uses an external config file. It's because that allows to still run it standalone. And not everyone is using VS Code. So if you want to support your teammates workflows, it's probably better to use an editor agnostic way of configuring it.
However, one could think of still allowing it and set these values with the -formatter flag, as overwrites kind of.

@bluebrown
Copy link
Author

You can see the different ways of configuring it here in the testdata folder https://github.com/bluebrown/vscode-extension-yamlfmt/tree/main/test/suite/testdata

@bluebrown
Copy link
Author

Also, would being able to load JSON for a yamlfmt config make it possible to have yamlfmt config embedded into settings.json? Cause that would be a pretty easy feature to add, and would be another cool way to be able to configure the extension.

Yes, that could be done as well, but one would need to decide what takes precedence when both exist. It would also help if it could read the config from stdin because that way we can grab it from settings.json and pass it directly to the binary instead of having to write it to some temp location.

Another issue is, that VS Code allows to simply open a file. Then, it doesn't belong to a workspace, so it is ambiguous what the current workdir should be. Currently, I am falling back to setting the parent dir of the file as cwd, so yamlfmt would find a config file right next to it. However, one could think of traversing upwards, all the way to home or root and find a .yamlfmt file. EditorConfig is doing this, but it has also a key in the config named root, indicating that this is the end of the traversal. I didn't do it as of now because I am not sure if that behavior should be part of yamlfmt itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants