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

requireConfig setting #96

Closed
daniel-liuzzi opened this issue Jan 21, 2018 · 10 comments
Closed

requireConfig setting #96

daniel-liuzzi opened this issue Jan 21, 2018 · 10 comments

Comments

@daniel-liuzzi
Copy link

daniel-liuzzi commented Jan 21, 2018

I have auto format on save turned on in both Sublime Text and VSCode. This works great for new files (i.e. files that already comply to Prettier's style) but older files are a pain: saving those results in literally hundreds of changes that I have to undo. With prettier-vscode, setting "prettier.requireConfig": true fixes this problem rather neatly (relevant PR).

Unless I'm missing something, a similar option doesn't seem to exist in SublimeJsPrettier. So what I end up doing is (1) disabling SublimeJsPrettier, (2) saving, and (3) re-enabling SublimeJsPrettier. This of course gets old really quick.

Are there any plans to bring this setting to SublimeJsPrettier? Thanks!

@jonlabelle
Copy link
Owner

jonlabelle commented Feb 5, 2018

@dliuzzi I read through the vs-code discussions on the topic. And I'm of the opinion (at least for now) that such a setting, adding a prettier.requireConfig (or similarly named) preference isn't indicative ~~~enough~~~ of the suggested intention and behavior - ignore all files when auto-format on save is turned on... and a prettier config file is NOT discovered.

That said, I'm not ruling it out as future enhancement.

@ianstormtaylor
Copy link

ianstormtaylor commented Feb 7, 2018

Just ran into this exact issue. @jonlabelle are you just opposed to the naming? Or to the feature itself?

I'm unsure how to ever make use of the auto_format_on_save feature unless you also have the require_config (with whatever name) feature to go with it. Otherwise this plugin can only ever be used in code you have control over, because editing codebases that don't have pretty will result in crazy changes that muck things up.

Would you reconsider?

@ianstormtaylor
Copy link

Further, this feature has been requested in 4 different issues in this plugin already, so there is a clear want for the functionality from users:

And the equivalent VS Code issue even further shows that this helps a lot of people.

@jonlabelle
Copy link
Owner

jonlabelle commented Feb 8, 2018

Okay, I'm sold. Will work on introducing it this weekend.

Though the setting definitely needs a more meaningful name. I was thinking...

auto_format_on_save_requires_prettier_conifg: true|false

@ianstormtaylor
Copy link

@jonlabelle thank you!! I much prefer that name, it's super clear.

@jonlabelle
Copy link
Owner

Question... can I assume a valid path to Prettier exists in the current environment, or specified in JsPretter Settings?

Just trying to avoid introducing a considerable amount of bloat trying to resolve Prettier config locations (and changes/additions to the config spec) - and simply run the native config resolve command (which is the current behavior of the plug-in).

@ianstormtaylor
Copy link

@jonlabelle honestly I'm not sure. Seems like it would be nice and simple if so though.

@antoinerousseau
Copy link

there is a typo in the setting name (conifg => config).

also, it seems to ignore my prettier settings now. for example I have semi: false and suddenly some semicolons are added on save. i just upgraded the plugin.

@jonlabelle
Copy link
Owner

Typo fixed.

@lock
Copy link

lock bot commented Aug 1, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants