Prettier VS Code 3.0

Yesterday, I spent some time talking with @BPScott about how he and other developers (at Shopify and other places) use VS Code Prettier with the linters. After our discussion, we believe we have a path forward that will allow continued support for prettier + linters while also reducing the issues with the current implementation. Along with that change, we are proposing a few other changes to this extensions. Below are the main changes proposed for VS Code Prettier 3.0. Please let me know what you think.

No longer ship with linters in the extension

Shipping with the linters in the extension results in a lot of potential version conflicts. For example, we currently include prettier-eslint in the extension, however that is not compatible for eslint versions > 5. As a result, many people are installing eslint@6 and seeing this extension break. There isn’t really a great way to inform people of those type of conflicts.

In order to make it easier for developers to understand when different dependencies are incompatible, we will require you to install prettier, the linters, and the prettier/linter integrations in your local project (package.json) in order to use the Prettier VS Code + Linter features.

What this means is the linting functionality this extension provides will continue to work, however, in order to set it up you will have to do an NPM install. The benefit of this is if you do an NPM install on incompatible package versions, NPM will tell you and users can better understand the error.

Encourage use of local prettier

We believe that when using prettier in your IDE you should always have a scriptable way of executing prettier as well. The Prettier VS Code integration is really a convenience, but it should not be used on its own. Every project using prettier should support running prettier through a CLI (outside of the IDE) and ideally use something like precommit hooks to ensure that all code checked into source control will be formatted the same.

We will continue to ship prettier with the extension so that users have an easy onboarding experience and so they can use prettier for things like formatting JSON outside of a project, but we will change the documentation to encourage that everyone always installs prettier locally in their projects. We may also provide warnings in VS Code in certain circumstances if you are using the built-in version of prettier.

Reduce Duplicate Configuration

Today, you can configure prettier in VS Code settings, using the .editorconfig file, and using the Prettier configuration files. Additionally, the extension tries to actually merge these version configurations together and applies them in a certain priority order. We have found that this results in a lot of confusion. For example, if you set the global setting to use tabs, but then you clone a project that already has a prettierrc or editorconfig file that overrides this setting, you may not understand where the setting is coming from.

Supporting all of these types of configurations is also a maintenance issue. Every time prettier changes a setting, people ask us to add it to VS Code settings. Additionally, we get requests to add other settings like ESLint, etc.

As such, version 3.0.0 of this project will ONLY support settings through the default prettier configurations. This includes the .editorconfig and prettier configuration file. All prettier duplicate VS Code settings will be deprecated.

Note, some settings will remain like the ignorePath as those provide configuration that is passed to prettier before it runs.

---

Work

• Use prettier getFileInfo to resolve which formatter to use as default instead of VS Code. This will resolve many issues such as not formatting graphql, etc.
• Use prettier getFileInfo to determine if a file is ignored
• Do not ship linters with extensions (require package.json install)
• Remove support for older versions of prettier (<1.10.0) and show error
• Deprecate vs code configuration and add helper to generate .prettierrc from existing config
• Add Prettier: Initialize command to add .prettierrc file (or whatever format the user wants)
• Rewrite logger to improve debugging and error handling
• Warn when using old version of prettier
• Warn when using invalid linter/prettier combinations
• TESTS: Resolution of configuration files
• TESTS: Resolution of ignore files
• TESTS: Linter configurations
• Automatically resolve the use of linters (no longer require vscode config)

Release Plan

Because this is going to release as several beta versions and is going to be a large breaking change, I am going to release this version as a new publish (prettier). This is also something we have wanted to do anyway for a while to make it more official.

Initially, I will maintain both versions 2.x on the current publisher and version 3.x on the new publisher. Once version 3.0 is stable and sufficiently tested, I will publish a new version of 2.x that will simply depend on the new extension - thus moving everyone to the new extension.

[ntotten]

The preview version 3.0.0 is now live on the marketplace for anyone who wants to try it. There will be bugs and there are still more breaking changes coming, so I wouldn’t use it as your main formatter yet. You can use VS Code insiders and install this extension to keep your main VS Code clean. https://marketplace.visualstudio.com/items?itemName=Prettier.prettier-vscode

[Kureev]

Anything community can help you with? I’m interested in upgrading eslint to 6.x and would love to invest some time to make it possible without breaking prettier-vscode 😃