1.0 release

[mitermayer]

Creating this issue to track down users features / feedback that they would like to have done on vim-prettier 1.0. I will be creating a 1.x branch where I will keep iterating towards the major release. Thing I will be tackling are:

• finalizing async support for neovim (Add support for neovim async #99)
• Add configuration to use default prettier settings (we currently use default FB settings)
• Add configuration preset support (allow users to select FB settings)
• respect indentation of visually selected formatting (Respect indentation for visually selected ":Prettier" #78)
• backport segfault fix (Fix PrettierAsync segmentation fault #138)
• custom plugin support ([WIP] feat($plugins): start the work on supporting custom plugins #120) with rebase on (Rebasing vim-prettier plugin Pull Request 120 to 1.0 branch #155)
• Updated documentation on vim-prettier and on prettier for vim integration
• Add entry on the README explaining that we already support prettier configuration overwrites via files (.prettierrc, prettier.config.js, etc..) and also on the project package.json
• make release/1.x default git branch and move old "master" branch to release/0.x branch

Some stretch goals will be:

• adding support for different prettier CLI's (Using prettier-eslint-cli #42 and Support for 'prettier-standard-formatter' #20)
• Create a FAQ area
• Errors that are not based on syntax should give user more information (maybe stacktrace)
• cleanup TODO's

---

If you guys have any suggestions of features or things you would like us to work on please leave a comment on this issue.

[sheerun]

Could you also support specifying prettier configuration in configuration file? https://prettier.io/docs/en/configuration.html Maybe even discovering prettier configuration by reading scripts in package.json

[mitermayer]

Hi @sheerun ,

This is already supported! you can already create a .prettierrc file on your home directory or project and vim-prettier will respect it. We should probably add this information to the README.md since this is not the first time that someone has similar questions around it.

Added the above as another task for 1.0 release. Feel free to submit a PR for it as well :)

[mitermayer]

Just to give a heads up, will start work on this today, will aim to have release done in 2 weeks!

[docwhat]

@mitermayer Is there an issue for Add configuration to use default prettier settings (we currently use default FB settings)?

If there was an issue with a rough description of how you'd like things, I could start submitting PRs to help you out. I've written a wrapper to strip out --no-editorconfig, so this would be interesting to me.

[mitermayer]

Hi @docwhat ,

Been flooded with work this week will start working on it during the weekend.

Please feel free to start submiting PR's, I think we can merge a lot quicker on the 1.0 branch and we can iterate on it until it get on a good stage for release.

[mitermayer]

I have created the branch "release/1.x"

[zfwf]

How to enable .editorconfig support? Prettier supports it out of the box but vim-prettier does not respect it.

[mitermayer]

Hi @chhschou,

I have just created a issue to track that #141, but the reason why did not support it on the past was due to a bug on prettier itself when using .editorconfig and config-precedence , I will investigate a bit more around it and add more information on the issue #141.

If that flag is no longer required I should be able to do a new vim-prettier release soon to cover it!

[ELLIOTTCABLE]

So, I don't think vim provides first-class support for this; but I'd love to see continuous, fluid reformatting of the code to the current window-size, followed by automatic saving in a fixed-width (100-column) format, regardless of buffer contents.

If you're interested, I brought this up on the vim StackExchange, in the interests of pursuing said behaviour for refmt. Thought y'all might be interested, if you're rearchitecting!

[mitermayer]

Hi @ELLIOTTCABLE,

Thanks for bringing that up! will definitely have a look into it!

[mitermayer]

I will resume working on vim-prettier in 2 weeks, been very busy at work at this stage as I am about to go on paternity leave in the next 2 weeks

[ELLIOTTCABLE]

@mitermayer life before open source.

[fatso83]

I have tried adding a .prettierignore to projects to avoid formatting them, but this plugin seems to ignore that. That's quite unfortunate, so maybe something for 1.0? Screw that. I was using NeoFormat ...

[sandangel]

is that possible to use prettier_d with vim-prettier ?

OK I just need to set the prettier cli path.
let g:prettier#exec_cmd_path = "~/.yarn/bin/prettier_d"

[sandangel]

and could you please help me with how to use fzf for quickfix with vim-prettier?

[RilDev]

Hi there,

Would it be possible to add the close-empty-jsx-elements option like in VS Code's Prettier?
prettier/prettier#5442 (comment)
So that <div></div> becomes <div />.

If I understand it well, the option should look like this:
let g:prettier#config#close_empty_jsx_elements = 1

Thanks!

[mitermayer]

Hi @CyrilAntoni,

Sure thing, do you want to create an issue to track that? I am happy to work on it during the weekend

[RilDev]

@mitermayer thank you that's very nice of you to do it, during your weekend on top of that!

[mitermayer]

Pasting here response of the above convesation thread with @CyrilAntoni on the issue: #202

Hi @CyrilAntoni

Loking into prettier CLI i can't see any option for close-empty-jsx-elements, it does not seem to be part of upstream. I even try to dig up history to see what has happened and followed threads such as

• Add jsxSelfClosing option prettier#6240
• Auto-closed JSX tags are really annoying during development. I would like to propose a one-way option that could provide "development" and "commit" stages prettier#5442
• Add jsxSelfClosing option prettier#6240

Unfortunetly I won't be able to support this feature in here until it is supported on the prettier cli plugin itself.

If that functionality gets added to it, please then feel free to reopen this issue

[mitermayer]

I acknowledge there are still some follow ups to be done for release/1.x but this branch has been open for way too long, I have also been dog-fooding this branch all throughout, so Then decided to merge it today to master.

Master is now set as version 1.0.0-alpha, will be listening to feedback and applying fixes/patches as needed and once stable will move it to beta and final release stages.

The older master version can still be accessible by release/0.x branch in case folks need for compatibility reasons