Prettier 07 🎨 Bracket Spacing — Object literal spacing rules - KandZ

⏱️ Estimated read: 8 min | |

The bracketSpacing option controls whether Prettier prints spaces between the curly braces of an object literal. It is a boolean with two values: true prints { foo: bar }, and false prints {foo: bar}. The default is true . The option is narrow by design: it applies to object literals and import/export specifiers, but it does not apply to the braces of a code block, a function body, or a class body.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

This chapter covers the two values, the exact scopes where the option has an effect, the scope where it does not, and the reason the Prettier team considers this option a historical artifact rather than a feature to emulate.

Key point: bracketSpacing only affects object literals and import/export braces. It does not affect the curly braces of if, for, function, class, or arrow function bodies. Those blocks are always formatted as {} when empty, regardless of the option’s value .

Why the option is narrow

The object literal problem. An object literal is a data structure written inside braces. {foo: bar} and { foo: bar } are the same object, but the spacing makes a visual difference. The bracketSpacing option lets a team choose which form it prefers. The default true produces the more common form, with a space after the opening brace and before the closing brace.

The block statement problem. A block statement is a control-flow construct. The braces of an if, a for, a function, or a class are not data; they are delimiters. Prettier treats them differently. The documentation states that the option does not affect the spacing between braces in block statements . A function body with no statements is always {}, not { }. An empty class body is always {}. The option does not reach those constructs.

The import/export problem. The braces of an import or export statement are a list of bindings, not an object literal, but Prettier applies bracketSpacing to them as well. import { foo } from 'bar' is the true form, and import {foo} from 'bar' is the false form . The same visual choice applies to named exports and destructured imports.

a. The two values and their output

The option is set in .prettierrc or the equivalent configuration file. The value is a boolean.

{
  "bracketSpacing": true
}

With true, an object literal with properties is printed with spaces inside the braces.

const config = { semi: false, singleQuote: true }

The opening brace is followed by a space, and the closing brace is preceded by a space. The output is the default form.

{
  "bracketSpacing": false
}

With false, the spaces are removed.

const config = {semi: false, singleQuote: true}

The object is still valid JavaScript. The only difference is the whitespace inside the braces. The choice is purely visual, and it does not affect runtime behavior.

b. Where the option does not apply

The scope of bracketSpacing is the most common source of confusion. The option is often assumed to control every pair of curly braces in the file. It does not.

// bracketSpacing: true
// Object literal: spaces applied
const obj = { foo: bar }

// Import: spaces applied
import { foo } from 'bar'

// Block statement: spaces NOT applied
if (condition) { doSomething() }

// Empty function body: always {}
function noop() {}

// Empty arrow function body: always {}
const fn = () => {}

// Empty class body: always {}
class Empty {}

The if block in the example is not affected by the option. The braces are a statement block, and Prettier formats them according to its block rules, not the object-literal rules. The empty function body is always {}, even with bracketSpacing: true. The option is not a general “space inside braces” switch .

c. The historical artifact

The Prettier team has stated that bracketSpacing is one of the options they are not happy to have. The Option Philosophy page lists --no-bracket-spacing among the options that “are not the type of options we’re happy to have” and that “cause a lot of bike-shedding in teams” . The option exists because it was added early, and removing it now would break existing configurations. It is not a model for future options.

This is consistent with the broader Prettier philosophy: fewer options, less debate. The existence of bracketSpacing does not mean the team encourages more options of its kind. It means the team has accepted this one as a historical artifact and has chosen not to add more .

Complete Example Session

// ============================================
// PART 1: THE DEFAULT
// ============================================
{
  "bracketSpacing": true
}

// ============================================
// PART 2: OBJECT LITERAL WITH true
// ============================================
const config = { semi: false, singleQuote: true }

// Space after the opening brace.
// Space before the closing brace.

// ============================================
// PART 3: IMPORT WITH true
// ============================================
import { useState, useEffect } from 'react'

// The import braces follow the same rule.

// ============================================
// PART 4: THE FALSE VALUE
// ============================================
{
  "bracketSpacing": false
}

// ============================================
// PART 5: OBJECT LITERAL WITH false
// ============================================
const config = {semi: false, singleQuote: true}

// No space after the opening brace.
// No space before the closing brace.

// ============================================
// PART 6: IMPORT WITH false
// ============================================
import {useState, useEffect} from 'react'

// ============================================
// PART 7: THE BLOCK STATEMENT (NOT AFFECTED)
// ============================================
// With bracketSpacing: true or false:
if (ready) { start() }

// The if block is not an object literal.
// The option does not apply.

// ============================================
// PART 8: THE EMPTY FUNCTION BODY
// ============================================
// With bracketSpacing: true:
function noop() {}

// Always {}, never { }.
// The option does not reach block statements.

// ============================================
// PART 9: THE EMPTY CLASS BODY
// ============================================
// With bracketSpacing: true:
class Empty {}

// Always {}.

// ============================================
// PART 10: THE CONFIGURATION
// ============================================
// .prettierrc
{
  "bracketSpacing": false
}

// Applies to object literals and import/export braces.
// Does not apply to block statements.

The ten parts covered the default, the object literal with true, the import with true, the false value, the object literal with false, the import with false, the block statement, the empty function body, the empty class body, and the configuration.

Quick Reference

The option

Value	Output	Default
`true`	`{ foo: bar }`	Yes
`false`	`{foo: bar}`	No

Scope

Construct	Affected
Object literal	Yes
Import/export braces	Yes
`if`/`for` block	No
Function body	No
Class body	No
Arrow function body	No

Related options

Option	Purpose
`bracketSameLine`	JSX closing bracket placement
`arrowParens`	Parentheses around single arrow parameter
`singleQuote`	Quote style

Historical note

Item	Detail
Option philosophy	`--no-bracket-spacing` is a historical artifact
Not a model	The team does not encourage more options of this kind

Best Practices

✅ Do This:

// Set the option explicitly in the project config
{
  "bracketSpacing": true
}                                                            // ✅

// Use the default form for object literals
const config = { semi: false }                               // ✅

❌ Don’t Do This:

// Expect the option to affect block statements
if (ready) { start() }  // not affected                       // ❌

// Expect the option to affect empty function bodies
function noop() {}  // always {}                              // ❌

// Assume the option controls every brace pair
{
  "bracketSpacing": false
}  // only object literals and imports                        // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Block braces still have spaces	The option does not apply to block statements	Accept the block formatting; the option is not a global brace setting
Empty function body is `{}`	Prettier forces `{}` for empty blocks	The option cannot change this
Import braces are not spaced	`bracketSpacing` is `false`	Set it to `true`
Object literal spacing changed unexpectedly	The option was set to `false`	Set it to `true`

Real-World Examples

1. Default object literal

const obj = { foo: bar }

2. No-spacing object literal

const obj = {foo: bar}

3. Default import

import { foo } from 'bar'

4. No-spacing import

import {foo} from 'bar'

5. The configuration

{ "bracketSpacing": false }

6. The block statement (not affected)

if (x) { y() }

7. The empty function body

function noop() {}

8. The empty class body

class Empty {}

9. The default

{ "bracketSpacing": true }

10. The historical note

Prettier's option philosophy lists --no-bracket-spacing
as an option the team is not happy to have.

Visual

The two values

┌─────────────────────────────────────────────────────────────┐
│  bracketSpacing: true                                        │
│    const obj = { foo: bar }                                  │
│                                                              │
│  bracketSpacing: false                                       │
│    const obj = {foo: bar}                                    │
└─────────────────────────────────────────────────────────────┘

The scope

┌─────────────────────────────────────────────────────────────┐
│  AFFECTED                        NOT AFFECTED               │
│                                                              │
│  Object literal: { foo: bar }    if (x) { y() }             │
│  Import: { foo }                 function f() {}            │
│  Export: { foo }                 class C {}                 │
│                                  () => {}                   │
└─────────────────────────────────────────────────────────────┘

The empty block rule

┌─────────────────────────────────────────────────────────────┐
│  bracketSpacing: true                                        │
│                                                              │
│  Object literal: { }  (empty object)                         │
│  Function body:  {}   (always compact)                       │
│  Class body:     {}   (always compact)                       │
│                                                              │
│  The option cannot make an empty block { }.                  │
└─────────────────────────────────────────────────────────────┘

The philosophy

┌─────────────────────────────────────────────────────────────┐
│  Option Philosophy                                           │
│                                                              │
│  --no-bracket-spacing is listed among the options            │
│  the team is "not happy to have."                            │
│                                                              │
│  It exists as a historical artifact.                         │
│  It should not motivate adding more options.                │
└─────────────────────────────────────────────────────────────┘

Summary

Item	Value
Option	`bracketSpacing`
Values	`true`, `false`
Default	`true`
`true` output	`{ foo: bar }`
`false` output	`{foo: bar}`
Scope	Object literals, import/export braces
Not in scope	Block statements, function bodies, class bodies
Empty blocks	Always `{}`
Philosophy	Historical artifact

Key takeaways:

bracketSpacing controls the spaces inside object literal braces. true produces { foo: bar }, and false produces {foo: bar}. The default is true .
The option also applies to import and export braces. import { foo } from 'bar' follows the same rule as an object literal. The braces are formatted with or without spaces depending on the value .
The option does not apply to block statements. The braces of an if, a for, a function, or a class are not affected. An empty function body is always {}, regardless of the option’s value .
The option is a historical artifact. The Prettier team lists --no-bracket-spacing among the options they are not happy to have, because it causes bike-shedding without improving consistency . It exists because it was added early, not because it represents the ideal configuration surface.
The choice is visual, not functional. Both forms are valid JavaScript. The option does not change runtime behavior, and it does not affect the block formatting that Prettier applies to control-flow and function bodies.

Remember: bracketSpacing is a narrow option with a narrow scope. It controls the spaces inside object literals and import/export braces. It does not control the braces of a block statement, and it cannot make an empty function body print as { }. The default is true, which produces the more common form. The Prettier team considers the option a historical artifact, not a feature to celebrate. Set it, forget it, and do not expect it to reach the braces of an if block.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!