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

Fixed the order of arguments for Prettier with svelte #381

Merged
merged 1 commit into from
Oct 30, 2021
Merged

Fixed the order of arguments for Prettier with svelte #381

merged 1 commit into from
Oct 30, 2021

Conversation

sheodox
Copy link
Contributor

@sheodox sheodox commented Oct 30, 2021

See #375. When making changes and then saving an unsaved buffer (like one would do with a BufWritePre autocmd to format on save) on a Svelte file the changes that haven't yet been saved get undone.

I noticed the Svelte formatter used a different order of prettier arguments than all of the other formatters that use prettier. The --stdin-filepath argument had a couple other arguments before the file path. I reordered them so the file path immediately follows --stdin-filepath and that seems to have fixed the issue for me.

I'm pretty sure what's happening is that Prettier ignores the buffer passed as stdin because it doesn't see the file path in the arguments as the value to --stdin-filepath, but instead as the file path to the file to format, so it just ignores the buffer text sent over stdin and loads the file from the filesystem which naturally won't have the buffer's changes as they haven't been saved yet. (You can see this by running the commands in the two different orders with --loglevel debug to see what it interpreted the cli arguments as.)

The current order is doing something like this:
image

The changed order is doing something like this:
image

See #375. When making changes and then saving an unsaved buffer (like one would do with a BufWritePre autocmd to format on save) on a Svelte file the changes that haven't yet been saved get undone.

I noticed the Svelte formatter used a different order of prettier arguments than all of the other formatters that use prettier. The `--stdin-filepath` argument had a couple other arguments before the file path. I reordered them so the file path immediately follows `--stdin-filepath` and that seems to have fixed the issue for me.

I'm pretty sure what's happening is that Prettier ignores the buffer passed as stdin because it doesn't see the file path in the arguments as the value to `--stdin-filepath`, but instead as the file path to the file to format, so it just ignores the buffer text sent over stdin and loads the file from the filesystem which naturally won't have the buffer's changes as they haven't been saved yet. (You can see this by running the commands in the two different orders with `--loglevel debug` to see what it interpreted the cli arguments as.)
@sbdchd
Copy link
Owner

sbdchd commented Oct 30, 2021

Thanks!

@kodiakhq kodiakhq bot merged commit 6b28df6 into sbdchd:master Oct 30, 2021
@sheodox sheodox deleted the svelte-undoes-unsaved-changes branch October 30, 2021 16:19
nikvdp pushed a commit to nikvdp/neoformat that referenced this pull request May 15, 2022
See sbdchd#375. When making changes and then saving an unsaved buffer (like one would do with a BufWritePre autocmd to format on save) on a Svelte file the changes that haven't yet been saved get undone.

I noticed the Svelte formatter used a different order of prettier arguments than all of the other formatters that use prettier. The `--stdin-filepath` argument had a couple other arguments before the file path. I reordered them so the file path immediately follows `--stdin-filepath` and that seems to have fixed the issue for me.

I'm pretty sure what's happening is that Prettier ignores the buffer passed as stdin because it doesn't see the file path in the arguments as the value to `--stdin-filepath`, but instead as the file path to the file to format, so it just ignores the buffer text sent over stdin and loads the file from the filesystem which naturally won't have the buffer's changes as they haven't been saved yet. (You can see this by running the commands in the two different orders with `--loglevel debug` to see what it interpreted the cli arguments as.)

The current order is doing something like this:
![image](https://user-images.githubusercontent.com/3468630/139522331-e805670f-bf0e-488a-a3e5-6d0232d8696a.png)

The changed order is doing something like this:
![image](https://user-images.githubusercontent.com/3468630/139522352-74da6539-c4bd-4812-b9b0-e64fcb545b3d.png)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants