[RFC] Editor Integration

[vjeux]

Editors are the main place where we want people to use prettier, in order for it to be a great experience it should have the following properties:

• Use the version of prettier that the project uses. If not, fall back to an arbitrary version.
• When saving, use the options specified by the project, otherwise fall back to an arbitrary configuration.
• When reading a file that is inside of a project using prettier, and if an option is enabled, reformat the code using the local user preferences.

Proposal

Allow people adding their configuration options inside of prettier in package.json:

{
  ...

  "prettier": {
    "bracketSpacing": false,
    "trailingComma": "all"
  }
}

How to find a package version of prettier?

Given a file with a path a/b/c/d/e.js, we want to crawl up the tree up until we find a file package.json.

It should check in this order:

• a/b/c/d/package.json
• a/b/c/package.json
• a/b/package.json
• a/package.json
• package.json

If it doesn't find one, then the file isn't inside of a prettier repo.

If it finds one in a/b/package.json, then look at the file a/b/node_modules/.bin/prettier. If it finds one, then use this prettier binary.

How to deal with caching?

This is a fair amount of io to be done for each invocation. If you want to add caching, you want to be careful, here are the things to watch out for:

• a/b/package.json is updated
• a/b/node_modules/.bin/prettier is updated
• a/b/c/package.json or a/b/c/d/package.json is created

How to find the configuration associated to a package version of prettier?

Given that a package version of prettier is always in a/b/node_modules/.bin/prettier and the package configuration is always in a/b/package.json, we can inside of prettier check if ../../package.json exists, and if it does read it and use the prettier key.

If prettier is being used as a CLI with require('prettier'), I'm not sure how to find it and if it's even a good idea to.

How do you resolve conflicting rules?

I suggest that we merge rules one by one and the order they are loaded in/override each other is:

• First load package.json rules
• Then load CLI arguments which override the one above

For example,

// package.json
{ "prettier": {"trailingComma": "all", "singleQuote": true} }

prettier --trailing-comma es5 --parser flow

would result in

{singleQuote: true, trailingComma: 'es5', parser: 'flow'}

How to make it fast?

Because all the integrations now have to use the cli and can no longer just use the local require version, we're going to pay js/node startup time on every single invocation.

I recommend adding an option to prettier bin --json-rpc. With this, you can open the prettier process once and send formatting commands through stdin/stdout without having to restart it every time.

A sample connection looks like this:

-->
Content Length: xxx
{"jsonrpc": "2.0", "method": "format", "params": ["abc", {"trailingComma": "es6"}], "id": 1}

<--
Content Length: xxx
{"jsonrpc": "2.0", "result": {"formatted": "abc;", "error": null}, "id": 1}

Conclusion

Let me know what you think :)

[vjeux]

cc @jlongster @robwise

[robwise]

Wow, great work writing all of this up.

How to find a package version of prettier?

This is something a number of users are requesting on prettier-atom. We haven't implemented yet, but what you're describing sounds about right to me.

If prettier is being used as a CLI with require('prettier'), I'm not sure how to find it and if it's even a good idea to.

I believe @kentcdodds solved this issue in a similar case where he needed to find the ESlint configuration for prettier-eslint. He solved it by optionally passing the filepath of the file as an option. Then the tool knows where to start recursively checking from.

I suggest that we merge rules one by one and the order they are loaded in/override each other is:

First load package.json rules
Then load CLI arguments which override the one above

I vote for this also.

How to deal with caching?

This is definitely something we will need to watch out for.

How to make it fast?

Have we determined that performance is a problem? The jsonrpc thing sounds like a good idea when doing multiple files at once, but inside of editors, I assume the use cases are just to do the single file or even only part of the file.

[kentcdodds]

How to find a package version of prettier?

Great way to do that is with find-up

[lydell]

There's also read-pkg-up.

[SimenB]

JetBrains IDE (IntelliJ, WebStorm etc) issue: https://youtrack.jetbrains.com/issue/WEB-25077

[vjeux]

Previous discussions on the prettier repo: #753 #735

[millermedeiros]

One thing I added o esformatter was the concept of a root config to avoid merging other settings and to speed up the lookup a little bit (as soon as it finds a config with root: true don't need to keep looking up the file tree).

This is basically how I decided to implement it: millermedeiros/esformatter#76 (comment) - cli options always take precedence (assumes user is overriding the defaults on purpose)

The whole user config logic is handled by the getRc method, I expose it so that plugins and other consumers can reuse it (see: source)

The package version logic I do inside the bin file using the resolve module - it starts looking for the locally installed module based on the config file (if user provides one) or the cwd.

jsonrpc is a good idea (was going to do the same for esformatter but never found the time), I would implement it as a dedicated bin tho.

[bakkot]

Most JS I write does not live in an npm package, so this would do nothing for me.

I know that's kind of unusual, but I thought it worth mentioning - package.json is an npm thing, not a JS thing.

[gustavnikolaj]

Instead of implementing a JSON RPC protocol through stdin/stdout you could also just create a programmatic API like the one eslint has.

var eslint = require('eslint')
eslint.lintText(text, options, callback);

Both eslint and standard-engine-based linters implement similar APIs. I wrote a plugin for integrating standard-engine linters into Atom which use this API to implement a worker to avoid the node.js startup cost on each lint.

It allows for the same separation as the stdin/stdout protocol, but is more flexible in my opinion, and probably a bit easier to do as well :-) It also won't rule out the stdin/stdout based solution, but rather be the first step to implement it.

[SimenB]

@gustavnikolaj that's only useful for editors written in JS (so atom and code?), not for emacs, vim, intellij, webstorm, sublime etc.

And prettier already has a programatic API, so those integrations can be done today

[gustavnikolaj]

@SimenB Oh sorry, I should have checked whether it was already there.

[vjeux]

We also need it for atom. It has chrome flags enabled that prevent doing eval(), so you can't just require a js file found in package.json. What the current atom editor plugin does is to use a specific version, which isn't ideal since you may have multiple projects using different versions.

So the workaround is to shell out and use stdio

[gustavnikolaj]

@vjeux child_process.fork can be used from within atom to sidestep the CSP that prevents use of eval. Had to do the same thing to be able to use the projects linter instead of bundling them in the plugin.

[kentcdodds]

Yeah, most atom packages that need to do this use loophole. In fact, prettier-atom does this :)

[jondot]

@robwise I've bumped into performance issues stacking prettier with eslint --fix, so today I'm just using eslint. While my mac holds up well and I don't really "feel" sluggish while typing in Vim (as I'm sure no one does with current macs) -- CPU does spike, the laptop heats up, and battery drains much faster.

Today, I'm using neoformat/ALE with Vim using eslint_d that spawns only once (like proposed here) and that results in lightning fast lints, and code formats. Out of the lot of the editors I use (VSCode, Atom, Vim) - Vim will take up the least amount of CPU and battery, although it does all integrations out of Javascript land (unlike Atom, for example).

I think using one server process or at least supporting that mode is a lesson learned for many IDE architectures by now, and I would personally welcome it even though there's no real 'proof' of lack of performance.

[robwise]

@jondot When you say you've run into performance issues stacking prettier with eslint, have you tried https://github.com/prettier/prettier-eslint? We have this integrated inside of https://github.com/jlongster/prettier-atom.

[jondot]

Yes, I've tried prettier-eslint (via Neoformat). Timing for prettier-eslint + autofix, is around 2sec for a 70LOC React component file, with near-vanilla vim (neovim even), eslint with a few rules and prettier on Node 6.9.x. On the other hand timing for eslint_d for lint + autofix is sub-100ms.

I gave the whole thing another try after reading the thread here. The deal is that with Vim, the integration is running a binary, providing input and taking the output via stdin/stdout. However you look at it - we still incur the startup time and the big CPU spike of spinning up eslint.

With eslint_d I finally found solace as it only spins it up once, and latency for linting and fixing becomes near (but not identical to) javascript-native editors such as Atom and VSCode.

I spent a bit of time trying to trick prettier-eslint to use eslint_d (essentially becoming prettier-eslint_d) however then I found that prettier and eslint would be too tightly integrated. I feel that it can take a few more hours to make the prettier-eslint_d coupling happen, which can be better than building a client-server architecture from scratch - however I ran out of time.

Would be happy to hear about any other altenative Vim configuration that gives out quick lint+fix results.

[danawoodman]

I'm sure it's been discussed, but what about a prettier.opts file (or .prettier, prettier.json, prettier.config.js, prettier.config, etc) that contains the configuration options? It seems more standard in the JS world to use a config file versus putting configuration in package.json which seems a bit like it's obscuring the configuration/requiring developers to know to look there versus seeing the config file in the root of a project.

Here is an example config prettier.opts (similar to mocha.opts):

--no-semi
--single-quote
--trailing-comma
es5
--write
"app/**/*.js"

I'm sure this has been discussed before but figured I'd throw the idea out here again.

Looks like this is being discussed over in #98 (see here and beyond)

A prettier.opts approach

For those that want a simple approach that works today, create a prettier.opts file with any options you want to override:

--no-semi
--single-quotes
--trailing-comma

Then in your package.json you can call this by doing:

{
  "scripts": {
    "format": "prettier $([ -f prettier.opts ] && cat prettier.opts) 'app/**/*.js'"
  }
}

Basically this says, if there is a prettier.opts file, read it and pass it to prettier. This will work if you have this file present or not so it should be safe to use in any project.

You can also set up your editor integration to use this, for example with Neoformat for vim:

Plugin 'sbdchd/neoformat'
let g:neoformat_try_formatprg = 1
let g:neoformat_only_msg_on_error = 1
autocmd BufWritePre *.js Neoformat
autocmd FileType javascript set formatprg=prettier\ --stdin\ $([\ -f\ prettier.opts\ ]\ &&\ cat\ prettier.opts)

Note: not sure this will work on Windows...

[josephfrazier]

@jondot

I spent a bit of time trying to trick prettier-eslint to use eslint_d (essentially becoming prettier-eslint_d) however then I found that prettier and eslint would be too tightly integrated. I feel that it can take a few more hours to make the prettier-eslint_d coupling happen, which can be better than building a client-server architecture from scratch - however I ran out of time.

I'm working on a very similar project: prettier_d, which just runs prettier as a server (but without eslint).

Would be happy to hear about any other altenative Vim configuration that gives out quick lint+fix results.

For linting, I'm trying out eslint-config-standard and eslint-config-prettier (details here). Not sure if it alone is faster than anything you've tried, but you might be able to use it in concert with eslint_d to speed things up.

For continuous formatting inside the editor, I'm experimenting with using a local .vimrc file with some autocmds to format using prettier_d (details here). I'm hoping to be able to move the autocmds into my global vimrc, but I need to make prettier_d clever enough to do nothing if prettier isn't actually intended to be used in the current project. I've gotten this working, along with project-specific configuration in package.json: See https://github.com/josephfrazier/prettier_d.js/tree/74b3398ba0b5df7652ae140d34feccdda0145636#real-time-formatting-in-vim

[aaronjensen]

@josephfrazier have you seen https://github.com/sbdchd/neoformat ? Also, it's certainly slower than prettier_d would be, but I'm currently using eslint_d with https://github.com/not-an-aardvark/eslint-plugin-prettier which seems to work well now that prettier has no-semi

[iamstarkov]

I want to introduce prettier to my colleagues in the office, but it will be hard without config. Because i cant control my colleagues' editor' plugins' configurations.

Config support will help me to maintain config per each project and let prettier-cli and relevant editors' plugins to get configuration from there.

Another usecase is to introduce prettier to my OSS projects, where contributors use all kind of editors, and i need a way to say to those editors' plugins which options of prettier i do use.

[iamstarkov]

Third, usecase i have different es5 and es6+ projects, and i want to use the same tooling (cli and pluins), so i can't use --trailing-comma all option in my editor plugin, because it would break my old project. Configs will help me a lot, because in old project i would be able to set --trailing-comma es5 and nothing will be broken

[danawoodman]

I think it's pretty clear prettier should support some sort of local/global config file. I've created a simple little bash script that implements it that I call prettier-with-options:

#!/usr/bin/env bash

if [ -f prettier.opts ]; then
  prettier --stdin $(cat prettier.opts)
elif [ -f ~/prettier.opts ]; then
  prettier --stdin $(cat ~/prettier.opts)
else
  prettier --stdin
fi

Now just make it executable (chmod +x prettier-with-options), put it on your $PATH and then call it within your editor, in my case vim with Neoformat:

" Use prettier with custom config
autocmd FileType javascript set formatprg=prettier-with-options

" Shared neoformat config
autocmd BufWritePre *.js Neoformat
let g:neoformat_try_formatprg = 1
let g:neoformat_only_msg_on_error = 1

This will always run prettier on any JS code so be aware of that. It would require a bit more work to only turn on projects that have a prettier.opts file in them but it's doable. Hope this helps someone.

[EvHaus]

There are two important considerations that aren't being discussed that I want to ensure get considered as part of this proposal:

• Not all Javascript projects use a package.json
• If you want to share configurations, it is much easier to do so if you're passing around a prettier-specific file (ie. .prettierrc) than sharing a package.json that might have other project-specific stuff in it.

For those reasons (plus the ones already mentioned) I'd petition to have configuration in a dedicated file rather than inside the package.json.

I believe the problem of finding and caching the appropriate config is a problem that's already been solved by projects like eslint and stylelint and should be easily transferrable to prettier.

[azz]

Prettyfile.json :)

In all seriousness, a prettier.opts plus a CLI way to point to it could work.

[AxelTheGerman]

Any other tool in this category supports having a config file. There's probably half a dozen issues opened in this regard.

Correct me if I'm wrong but usually you would have any of the following files or use the default settings:

• .prettier.config in project root, or to make it simple in the current directory (assuming that you would run prettier from the root of your project?)
• ~/.prettier.config (home directory)
• possibly even higher up across all users, but I think that's more common for system services such as nginx
  Only having those few specific locations safes you the time to walk up the whole file tree.

Command line options are still nice for manually running a one of. Those would obviously override any configuration file.

Also as mentioned above, please make this available to projects that are not npm modules, event though most might be. But a dedicated config file is easier to copy to new projects and makes it more obvious where to look.

Need some examples? In my current project I see .csscomb.json, .eslintrc, .rubocop.yml and coffeelint.json. Also a .ruby-version to let rvm pick the correct ruby version for this project. In my home folder .gemrc for rubygems (which for example supports a /etc/gemrc for system wide configuration)

Please let's keep this discussion going. This is a key feature imho

[josephfrazier]

For anyone who wants to use package.json or .prettierrc right now, I've added support in prettier_d. You can put the JSON configuration in either .prettierrc, or as the prettier key in package.json, then run prettier_d --pkg-conf [file] and the configuration will be used. See the documentation for more details.

[jondot]

@josephfrazier very nice! i think it'll alleviate some pains around Vim.

Still, to update on my set up: there's still no polite way to use prettier on Vim (without thrashing CPU and lagging formats). Looks like I can't use eslint for linting such as unused variables, etc., and have prettier format code at the same time. So if I use standard rules for the former and prettier for the latter, it wouldn't work for some reason. I've tried all this with prettier_d and at some stage with eslint_d.
I'll try again with your update, @josephfrazier.

[josephfrazier]

@jondot:

So if I use standard rules for the former and prettier for the latter, it wouldn't work for some reason.

If you look at the ESLint configuration for prettier_d itself, I think I've gotten this working as you described. I don't have a Vim/ESLint integration set up (I just use plain eslint with the ESLint config, not eslint_d) This config works with syntastic/eslint_d, and I use prettier_d to format it's own code as I'm typing, as you can see from the local .vimrc file (note that you need a Vim plugin like vim-addon-local-vimrc to use local .vimrc files).

Feel free to open an issue at prettier_d if you have any trouble/questions/suggestions. I'd love to get feedback!

[danawoodman]

@vjeux how about the following as a proposal?:

Command line looks for ./prettier.opts then ~/prettier.opts in the following order or a -c/--config my.custom.prettier.opts. The flag has highest priority

If none of the above match, prettier falls back to defaults.

The prettier.opts file is read line-by-line into the prettier command line so people don't need to learn a new format or use some special file type (eg .json, .yml, etc). Plus a prettier.opts file is portable and can be moved to any JS project, even ones that don't have package.json files.

prettier # looks for -c/--config or ./prettier.opts or ~/prettier.opts or falls back to defaults
prettier -c prettier.custom.opts # -c/--config: pass in custom "prettier.opts" file path

If this is acceptable, is a PR something that would be desired?

NOTE: If it is preferable for some reason to use a .json file, the above still applies. Personally I find it more elegant and intuitive to use the .opts format since those args match exactly what prettier expects on the command line.

[AxelTheGerman]

@danawoodman would love to see exactly that!

[chrisui]

Been mentioned already but I would push for using something such as cosmiconfig which implements the config formats commonly seen across the ecosystem. Imo it gives the most predictable way for writing and consuming configuration for tools in the js world.

From the README:

Find and load a configuration object from

• a package.json property (anywhere down the file tree)
• a JSON or YAML "rc file" (anywhere down the file tree)
• a .config.js CommonJS module (anywhere down the file tree)
• a CLI --config argument

For example, if your module's name is "prettier," cosmiconfig will search out configuration in the following places:

• a "prettier" property in package.json (anywhere down the file tree)
• a .prettierrc file in JSON or YAML format (anywhere down the file tree)
• a prettier.config.js file exporting a JS object (anywhere down the file tree)
• a CLI --config argument

[chrisui]

Is there anything we can do to help move configuration/editor support along?

We seem to be getting in a bit of a muddle moving around projects with tools using different prettier versions (global vs project vs tool/editor vs ci) and it's causing us some degree of pain.

[chrisui]

I reckon we should be able to specify the prettier "version" in the config (wherever it lives) so that if someone attempts to use prettier with the wrong version we can fail loudly. This is the same as happens with using the incorrect version of flow to what is specified in configuration.

Ie.

{
  "version": "1.2.2"
}

[chrisblossom]

I think it is fairly important to be able to flag subdirectories with a new prettier config/overrides because not all JS features are supported per directory, specifically --trailing-comma all. The current Node LTS's (4 & 6) do not support this feature. If using it, at least part of your build chain will need an exception of some sort.

IMO don't reinvent the wheel...copy how eslintrc.js works. Nested .eslintrc.js inherit from configs further down the line but overwrite any settings.

[vjeux]

Fyi, node 8 that was just released supports trailing comma!!

[chrisblossom]

@vjeux Yeah it will be nice when it is LTS in October! nodejs/LTS#lts-schedule has Node 4 supported until April 2018 and Node 6 until April 2019.

Because Node's LTS, I don't think Prettier should adopt a configuration style that makes it more difficult to use until April 2019. I think the configuration decisions should follow the Node LTS schedule.

Here is my current configuration...
.prettierignore

.cache
.idea
.vscode
node_modules
build
static
flow-typed
flow
npm-packages-offline-cache
tools

package.json

    "prettier": "find . -name \"*.js\" | grep -v -f .prettierignore | xargs prettier --tab-width 4 --single-quote --trailing-comma all --write",
    "prettier:tools": "find ./tools -name \"*.js\" | xargs prettier --tab-width 4 --single-quote --trailing-comma es5 --write",
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "./*.js": [
      "prettier --tab-width 4 --single-quote --trailing-comma es5 --write",
      "git add"
    ],
    "tools/**/*.js": [
      "prettier --tab-width 4 --single-quote --trailing-comma es5 --write",
      "git add"
    ],
    "src/**/*.js": [
      "prettier --tab-width 4 --single-quote --trailing-comma all --write",
      "git add"
    ],
    "server/**/*.js": [
      "prettier --tab-width 4 --single-quote --trailing-comma all --write",
      "git add"
    ]
  },

Because of the "no configuration" philosophy, there ends up being more hacks/workarounds getting Prettier to work with a modern build setup. Not to mention the editor's plugin has no idea what config to use. End up having to run yarn run prettier:tools after saving any file in the tools directory if I don't commit right away otherwise the trailing comma will error node out.

If anyone has any suggestion on how to better handle this I'd love to hear how.

[josephfrazier]

@chrisblossom, since you're already using eslint, you could use eslint-plugin-prettier and eslint-config-prettier, add your prettier configuration to .eslintrc.jsfiles, then have lint-staged run eslint --fix instead of prettier.

[rattrayalex]

I'm a pretty big +1 to allowing .prettier config files, if for no other reason than that they function as great marketing on Github. But also because there are many times when there simply isn't a simpler way for people to use it.

Sharing bash files or "always run it with args --x --y z" within a company really isn't wonderful, and package.json simply doesn't work in all cases.

[Ciantic]

Is this thread mostly about agreeing to filename (e.g. .prettierrc / package.json) and format in it, like opts or JSON?

If so I think this should be decided by one maintainer, just do it.

There is already a cottage industry of these non-standards, one example from VSCode extension here:

{
    "prettier.tabWidth": 4,
    "prettier.typescriptEnable": [
        "typescript",
        "typescriptreact"
    ],
    "prettier.trailingComma": "es5",
    "prettier.printWidth": 100
}

This is not good! We need standard for this, such a simple thing should not be outsourced when in the end it's maintainers that decide these simple things.

[rattrayalex]

@Ciantic yes, I am planning on doing exactly that this weekend 😄 and it seems @azz has the same idea

[rattrayalex]

EDIT: moved a proposal regarding perf to #2434 (comment) as more relevant conversations are happening there.