Separate concept of brackets/braces

[joefiorini]

See example here:

https://jlongster.github.io/prettier/#%7B%22content%22%3A%22const%20aList%20%3D%20%5B1%2C%202%2C%203%5D%3B%5Cnconst%20anObj%20%3D%20%7B%20a%3A%20'b'%2C%20c%3A%20'd'%7D%22%2C%22options%22%3A%7B%22printWidth%22%3A80%2C%22tabWidth%22%3A2%2C%22singleQuote%22%3Afalse%2C%22trailingComma%22%3Afalse%2C%22bracketSpacing%22%3Atrue%7D%7D

The default airbnb rules require no spaces directly inside brackets (see https://github.com/airbnb/javascript#whitespace--in-brackets) and a space inside curly braces (see https://github.com/airbnb/javascript#whitespace--in-braces). It would be nice to have separate bracket-spacing and curly-brace-spacing options to allow similar flexibility.

I'm surprised I couldn't find an existing issue for this, as it must be causing eslint conflicts for a lot of projects. Maybe I just missed it?

[vjeux]

I'm surprised I couldn't find an existing issue for this, as it must be causing eslint conflicts for a lot of projects. Maybe I just missed it?

prettier has just been open sourced a week ago and in the past week we've fixed a bunch of things that made it output invalid JavaScript and code that looks really bad. So I don't expect that many people actually managed to actually use it for their project yet.

Please keep opening issues, they are great!

[joefiorini]

@vjeux thanks, I didn't realize this repo was still so young. I am using it in my work codebase right now, so I will keep opening issues as I come across things that conflict with our (fairly standard airbnb) eslint config.

[vjeux]

At this point, the biggest thing that is broken are comments. You can go through the list: https://github.com/jlongster/prettier/issues?q=is%3Aissue+is%3Aopen+label%3AComments

• We output invalid JavaScript // comment else {
• We drop comments inside of empty blocks
• Comments are positioned very randomly and may make eslint-ignore-next-line kind of comments invalid.

Outside of that, it should output valid JavaScript, but there are some things we can output better like JSX (#234), Binary expressions (#262) and Member expressions ( https://github.com/jlongster/prettier/issues?q=is%3Aissue+is%3Aopen+label%3AMemberExpression )

The goal is to get through most of them by end of next week :)

[vjeux]

Our plan of attack is to fix all those things and when it is done, go through a pass of all the suggestions like this one and evaluate what we want to do with them :) Keep them coming!

[joefiorini]

I might implement something for myself for the time being, so I can keep my current project in line with our eslint config (if I can do it quickly enough).

[vjeux]

Should be easy, search for options.bracketSpacing in src/printer.js and remove the line when you don't want it :)

[joefiorini]

In case someone else needs this change for now:

I went through and changed options.bracketSpacing to options.bracketSpacing || true in every context except array. Also noticed a place where shouldPrintSpaces is set to options.bracketSpacing, but then never used (around src/printer.js:1842). Assuming that isn't intentional?

[vjeux]

Nope, not intentional, feel free to send a pull request to get rid of it :)

[jlongster]

This is an opinionated formatter so we're not going to keep adding options so that people can still maintain their own formatting rules. I don't recommend using this with eslint's formatting rules. You should get rid of the formatting rules and keep the other rules that enforce semantic behaviors.

I know that's not always possible for existing projects, and we're trying to find a balance for adding a few options to help adoption, but we're also not going to add a lot of configuration.

[jlongster]

BTW, I'm open to never adding spaces with square brackets if that's how most people want it, disregarding the bracket spacing option.

[smably]

I did a survey of the most popular JS coding styles. Here is what I found:

• Airbnb: spaces inside braces, no spaces inside brackets
• Standard: seems to be OK with zero or one space between braces and brackets
• Google: no spaces inside braces, no spaces inside brackets

None of these style guides recommend spaces inside brackets, nor do the examples in Crockford or Mozilla's code style pages. Standard's examples also omit the spaces inside brackets.

My recommendation: prettier shouldn't insert spaces inside brackets, but spaces inside braces should remain configurable.

[vjeux]

I created #446 to remove spacing inside of []

[delijah]

If this library is about enabling developers to use their own code style, why do you define fixed rules here? I think both should be configurable, spaces inside curly braces and spaces inside (square) brackets (separately).

[lydell]

If this library is about enabling developers to use their own code style

It is not.

https://prettier.io/

Opinionated Code Formatter

https://prettier.io/docs/en/why-prettier.html

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles.

Less configuration, less debate.