Prettier-vscode: The road to v2

[RobinMalfait]

The road to v2

NOTE: There might be controversial things in this issue. I am 100% certain that you won't like every thing in this issue. Try to read trough it, give it a minute or two and let it sink in. Once you processed it all, then but only then you are allowed to comment. 😘

We have come very far using this extension. I would like to start with a big thank you to all the contributors. I would also like to thank all our users. And last but not least I would also like to thank the whole prettier team.

That being said, I think it is time that we write our road map to the 2.0.0 release.

Plugins

Plugins are still in beta, but I think that they can be very useful.

What if we make sure that plugins are automatically resolved correctly. According to the docs they should be loaded automatically when they start with @prettier/plugin- or prettier-plugin-. We probably have to resolve these based on the used prettier version.

Here are some crazy thoughts:

• What if we remove the eslint integration and write it as a plugin?
• What if we remove the tslint integration?
• What if we remove all integrations and purely rely on plugins? 🤔

NOTE: This will allow us to focus on core functionality and keep the code fast and clean.

Configuration

Currently we have a bunch of options, and people want even more options. Options are not fun, trust me.

Configuration options also have some problems, e.g.: The goal of prettier is to let teams write code however they want and prevent nitpicking on issues. But what if you have the option "prettier.semi": true, and your colleague has the option "prettier.semi": false,. You just introduced nitpicks on all your PR's, so here is a suggestion.

What if we remove most of the options in the VSCode extension, and we just read from the configuration from a local (or a parent one if you have multiple projects) prettier config like .prettierrc.

It might be a good idea to keep the _core_ options in place, I don't know yet.

Advantages:

• Your team is in sync, yay!
• You don't have to wait for an update on the extension to use your favorite option.
• We don't have to support those options anymore. 🎉

Disadvantages:

• You have to create a config file in your current folder / project. (Only if you want to use custom configuration options!)

Feature list

• [ ] Better error management (notify the user when there are actual errors with the plugin, not your code. This shouldn't be a linter).
• [ ] Make it easier to report issues with action / debug logs and all settings used for prettier.
• [ ] ...

Thanks

Thank you for reading, feel free to list other features.

[gimenete]

+1 to rely only in .prettierrc. Having the team in sync is key. You have to create a config file but it's minimal and makes all your tooling aware of your config options.

[rgaino]

I’m all in for a local config file. Multiple team members with different configs goes against the basic concept of prettier.

[David-Else]

If people want to change their prettier config they will do it via the vscode interface or a local .prettierrc file if needed. I am not sure how simply making it slightly harder to do via the file resolves the issues of teams staying in sync?

The only real solution is to have zero options, which nobody wants. Having just the core options in the extension seems like the most sensible comprimise:

  // Prettier formatting extension
    "prettier.singleQuote": true,
    "prettier.trailingComma": "all",

Also, I suspect the majority of people using the extension are not in teams and appreciate the added convenience of having a setting in the interface, especially new programmers.

Personally, having another config file in my local directory would be another little annoyance... I am trying to bung as many as possible into the package.json... but I am an OCD tidy freak :)

[kofno]

Prettier config can live in the package.json, too --> https://prettier.io/docs/en/configuration.html

[jquense]

I guess this is tough since formatOnSave is a vscode command but I'd really like to be able to only run prettier on save if there is a local .prettierrc, or package.json config. Manually configuring per workspace is a bit annoying

[gimenete]

totally agreed with @jquense too. Right now I have editor.formatOnSave: false and I have to change that in a per-workspace basis to enable it on those projects where prettier is actually used.

[CiGit]

@jquense @gimenete "prettier.requireConfig"

[suchipi]

I don't think you should need to implement plugin loading yourselves; we added a getFileInfo API recently to facilitate this. @kachkaev is probably more familiar with the details; they added it for use in the Atom plugin.

[kachkaev]

There is an ongoing work by @robwise to simplify Atom plugin: https://github.com/prettier/prettier-atom/pull/404

Perhaps, you could use the same design principles and a similar approach?

[RobinMalfait]

@kachkaev interesting, they are simplifying it as well. Nice!

[rattrayalex]

If global settings are removed from prettier-vscode, I would recommend changing prettier.requireConfig to be true by default. It would be a bit obnoxious to have prettier's default styles applied to every file you touch.

Separately, it might be worth releasing a "warning" version of the extension first which could offer to add a .prettierrc with your prettier-vscode settings at your project root when prettier-vscode is used without a config.

[eamodio]

I'm all for using the .prettierrc file, but I think with multi-root workspaces it will need to respect the .prettierc from the workspace the file is in. Because if I have multiple projects open they might have very different prettier rules.

[kachkaev]

And if .prettierrc is not found in the current project, a global instance of prettier with all its plugins is picked (or a built-in vscode prettier if a global prettier is not installed)

Use case: a workspace where one project is a node.js one (with local prettier) and another one is php/python/elm etc (no local npm packages -> global prettier + corresponding plugins)

[clozach]

Perhaps this is covered elsewhere already, but I'd really like to be able to customize not just _whether_ prettier auto-formats a given language file, but also customize the _indentation level_ per-language.

[RobinMalfait]

@clozach that is already possible if you override the tab-width per language.

[ntotten]

These are great suggestions and i have incorporated them into the planning and discussion for version 3.0. Lets continue the conversation there: #958

[github-actions[bot]]

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