Is there a way to set global configuration?

[aaronmcadam]

Editor plugins don't always have ways to pass configuration to the process they call.

For example, in order to set the vim plugin neoformat to tell prettier to use single quotes, I've had to fork the plugin.

Other vim plugins for linting, for example, aren't an issue because we have eslintrc.

I appreciate the complexity involved in having a prettierrc file (the spelling alone is awkward!) and I agree with the spirit of not adding too many options, but is there a way to set a global configuration that prettier could always use?

[jlongster]

That's a good use case, thanks. It sucks to have to fork it. We're not going to have an rc file, but would it work for you we if supported environment variables? So you could do PRETTIER_WIDTH=80 prettier? It's not ideal, but I'm happy to make this work as much as we can as long as we only have 3-5 options and avoid configuration files.

[aaronmcadam]

Hey @jlongster, thanks for getting back to me!

I did think ENV variables would be a good option after posting this. I think that would work really well, especially if there's only a couple of options!

[cedricpinson]

That would be great I have the same problem with emacs

[vramana]

ENV variables sometimes can cause great source of pain. I think it's just better to avoid them. So having editor plugins support configuration is the best in my opinion.

[brookswift]

I would really love to use this if I can get prettier to output code that will pass my large corporate eslint rules. Right now, it looks like the two issues I have are spaces between array braces [] and contents [ 1, 2, 3 ] is output but my lint hook requires [1, 2, 3] and no semicolon ending the last line of code, so I get }) instead of });

[jlongster]

@vramana Explain more about the pain? I don't think it would be pain for us to support, but might be a pain for users to use. They can deal with the pain if they are using tools that can't properly pass arguments in.

@brookswift You are in luck. There is already an option for bracket spacing (pass --bracket-spacing=false in CLI or bracketSpacing: false or API). As for semicolons, see #12. We will not directly support lack of semicolons, but I'm working on an idea to integrate eslint and use that pass to remove them.

[brookswift]

@jlongster , sorry, I wasn't clear about the 2nd issue. After I run prettier, I lose the semicolon on my last line of code. That's the issue I was running into. I need every statement to end with a semicolon, including the last one. Maybe that's actually a bug then? I can type up an example case for you if so. If I can get your tool to pass our eslint requirements, I might be able to integrate it into our build process and save our hundreds of developers the daily headache of trying to fix lint issues.

[jlongster]

@brookswift Oh, even better. Yes, if there should be a semicolon, we should output it. I suspect it's more with the type of syntax that's on that line. Please file a new issue!

[evanliomain]

@jlongster ENV variable is a pain to use unlike a file configuration.
Consider a project :

• which can be run on windows, mac and linux ;
• which is edited on vscode, vim, textmate, notepad (etc) according developper flavour

Consider you have several project on your laptop, and each one with a different configuration (because of different team)

A prettierrc, tracked in the version control (like git) is the nice way to share the configuration :

• a new developper have it when he checkout it
• it's version controlled, with all benefit (history, PR review ...)

ENV variable need a configuration for each team's developper. It a big break to adopt it in a project.

[lydell]

What about being able to specify options in package.json?

{
  "name": "some-package",
  "prettierConfig": {
    "printWidth": 71,
    "tabWidth": 4,
    "singleQuote": true,
    "trailingComma": true,
    "bracketSpacing": false,
    "parser": "flow"
  },
  "dependencies": {
    "prettier": "0.11.0"
  }
}

It's easy to read the closest package.json with read-pkg-up;

const readPkgUp = require("read-pkg-up");
let pkg;
try {
  pkg = readPkgUp.sync({normalize: false}).pkg;
} catch (e) {
  console.error(e);
}
const globalOptions = (pkg && pkg.prettierConfig) || {};

Or simply always from ./package.json:

let pkgString;

try {
  pkgString = fs.readFileSync("./package.json", "utf8");
} catch (e) {
  // Ignore no package.json found.
}

let pkg;

if (pkgString) {
  try {
    pkg = JSON.parse(pkgString);
  } catch (e) {
    console.error(e);
  }
}

const globalOptions = (pkg && pkg.prettierConfig) || {};

[lydell]

If somebody wants global configuration now, you can run prettier via eslint using the brilliant eslint-plugin-prettier plugin. prettier some-file.js --write then basically becomes eslint some-file.js --fix. (You get ignore file support, too, via .eslintignore.)

[aaronyo]

Does prettier want to support a user working across projects that use different prettier rules? I don't think env vars are a good solution for that use case.

With emacs, I'll sometimes start a single process and open files from multiple projects. If those projects want a different prettier rule, and I'm configuring with env vars, I'd be forced to launch multiple instances of emacs. Not the end of the world, but it would be the only reason I'd have to do that.

[esamattis]

I also needed project specific config files for prettier. As a workaround I ended up creating this wrapper:

https://gist.github.com/epeli/7e9511cbd2ec806c5f8a6f96428352c2

Just put it to PATH and use prettier-config instead of prettier and it will read cli options from the project's .prettieropts file.

The file just contains the cli options you want to have. ex.

--no-bracket-spacing
--tab-width=4
--print-width=100

It will look for the .prettieropts file like eslint: From the current directory and any parent directory. It will use the first one found.

For Vim the Gist also contains a neoformat config for it.

[robcaldecott]

Please not environment variables: they cause headaches between Windows/Macs. A package.json section would be perfect. I'm desperate to get prettier adopted here and per-project configuration would definitely make that easier.

[pie6k]

I'd be fan of .prettierrc, .editorconfig or .jsstyle

[awitherow]

Jumping between multiple projects and not having an easy way to define my pretter settings per project is quite a pain! I would love to have something along the lines of .prettierrc!

[rafales]

I think looking into both .prettierrc and .editorconfig would be a good idea. Settings in package.json could be a nice addition, but there should be a way to have more control over which files have which settings.

For example - in a huge webpack project I have 3 js files in scripts folder which get executed by node. For those 3 files I need --trailing-comma set to es5 (otherwise I'll run into syntax error). For the rest - I'd prefer all setting.

Another situation when configuration file outside of package.json would be useful - huge repos with multiple packages.

[danawoodman]

I mentioned a similar approach to @epeli over here.

It seems like since prettier's goal is to keep config simple, using a simple prettier.opts file that gets passed directly to prettier is the simplest approach that will allow switching between projects, offer editor support and discoverability for developers (which putting options in package.json lacks).

I think having out of the box support for this would be huge for adoption of prettier since it would mean just needing to install a plugin for your editor or running prettier without arguments in any project that has a prettier.opts file in it. This maps to how .eslintrc file works and it's associated editor support.

[danawoodman]

I've implemented what I think is a simple approach to getting a prettier.opts file working today for both command line and editor integration use, please see here

[aaronyo]

Here's my workaround:

If you install prettier local to your project rather than globally (which is highly recommend for any team projects) then you've probably already got your IDE finding the project-local prettier executable. You've done the hard part. Now just create an executable in your project, say bin/prettier, that calls your locally installed prettier with the appropriate opions. Point your IDE to that instead of the npm installed prettier.

(If you're using emacs, you can modify this stack stackexchange answer to find a locally installed prettier. Just replace "node_modules" and the executable location with "bin/prettier".)

[aaronyo]

I just realized I'm talking about local config rather than global. This issue thread is dealing with both (.prettierrc is not a global config solution). If global config is desired, it's a much easier problem and should probably be separated from the challenge of local config.

[aaronmcadam]

.prettierrc is not a global config solution

other rc file implementations will look for rc files in $HOME and in the local project directory

[danawoodman]

Yes a .prettierrc (or my preference, prettier.opts) should work just fine globally. It prefers the local version over the global, if present.

[aaronyo]

@aaronmcadam @danawoodman

I should have been more clear. If the only thing you want is "global" configuration, environment variables seem like a very good solution. The argument for a .prettierrc is that you want more flexibility than that.

I think there are at least three use cases touched on in this issue thread:

1. "Globally" configure prettier so that whenever I start my editor/IDE it always has the same config.
2. Specify prettier configuration when I start my editor/IDE, so that I can have multiple instances of my IDE running with different configs.
3. Run a single instance of my IDE/editor that will determine prettier config based on the file (or project) that is currently loaded.

(and then there is also the desire for a solution that works on any platform, but i'll leave that aside...)

The title of this thread makes it sound like the goal is #1.

I hope that doesn't all just sound like a bunch of words. It seems like it would useful to be clear about what the actual goal is. A .prettierrc does seem like a good solution if we're after more flexibility like what is suggested by #3.

[danawoodman]

@aaronyo yeah, this is about global config. I mentioned over here that it would be nice if we had a solution that worked both globally and locally per project. My proposal (and that of others), is to use the standard config file approach (.prettierrc/prettier.opts/.prettier.config/etc). Here is what I think would be ideal:

1. By default, prettier does its thing (default behavior)
2. If you have a prettier.opts (or whatever we end up calling this file) in your $HOME, we use that
3. If one exists in a project, that is preferred (completely overrides that in $HOME)

To me this covers all use cases I can think of. Editors just need to call prettier when files are changed and prettier figures it out (editor integration then becomes "dumb").

[vjeux]

Good news, node 8 will ship with support for trailing commas in function calls and declarations. So we'll be able to use --trailing-comma=all everywhere :) nodejs/node#10117 (comment)

[azz]

@vjeux Except in prettier where node 4 is supported? 😉

[danawoodman]

How is this relevant to global cofig?

[thasmo]

I'd love to see support for a stored configuration and I'm suggesting https://github.com/davidtheclark/cosmiconfig so people have the choice. Thanks a lot!

[rattrayalex]

Fixed in #2434 with cosmiconfig