Version 2.0.0 of @moonjellydigital/prettier-config Is Out

Version 2.0.0 of @moonjellydigital/prettier-config is now available to install from the NPM registry.

I originally published this Prettier config to NPM solely for the convenience of not having to copy configuration files between my own repos. I thought, well it’s more convenient to install and free to host if it’s public, and there’s no reason other people shouldn’t be able to use it if they want to.

Despite absolutely no marketing, it gets a few downloads per week that aren’t me or my CI runs. Thank you to the person or people who decided to use this package. The fact that anybody other than me uses it has prompted me to write a post about it.

As the version number implies, there are changes in 2.0.0 that will format your code differently than the 1.x versions. This version sets experimentalOperatorPosition to start and objectWrap to collapse.

Yes, I know those options came out with Prettier 3.5 in 2025 and that it is now the last quarter of 2026. It took that long to decide if I really wanted to change the way objects and code with binary operators were formatted. I finally decided that yes, changing the formatting made sense, and here’s why.

objectWrap: ‘collapse’ Rationale

Prettier’s old behavior, and the default behavior of objectWrap, formats an object to use multiple lines if there’s a newline before the first property, regardless of whether the object could fit on one line. So the final, formatted output depends on what the developer punches into their keyboard.

// original input
const myObject = { propA: 'a string', propB: 'more string' };

const myOtherObject = {
  propC: 'str', propD: 'another string'
};

// old formatting behavior
const myObject = { propA: 'a string', propB: 'more string' };

const myOtherObject = {
  propC: 'str',
  propD: 'another string'
};

// new formatting with objectWrap: collapse
const myObject = { propA: 'a string', propB: 'more string' };

const myOtherObject = { propC: 'str', propD: 'another string' };

One could argue that this is a feature because it lets developers choose the most readable layout in each case. One could also make a strong counter argument that it’s an anti-feature that makes the codebase less consistent and invites bikeshedding about what constitutes better readability. There’s also the question of whether it’s even worthwhile to put any effort into thinking about changing the way object literals get formatted.

Ultimately, I came down on the side of visual consistency because more and more code is being AI generated. An LLM doesn’t have eyeballs to assess the readability of one way of formatting versus another; that’s something peculiar to sighted humans. The formatting “choices” it outputs are a product of statistical probabilities based on context, training data, and the algorithmic nudging of token selection made by the watermarking system. A programmer coding by hand can make choices about formatting that have intent and meaning, LLMs can’t.

Permitting only a single way objects can be formatted reduces AI-generated noise in the codebase.

experimentalOperatorPosition: ‘start’ Rationale

Code with binary operators on multiple lines used to put the operator at the end of the line. This is the behavior of Prettier versions prior to 3.5, and also the behavior of the default setting for experimentalOperatorPosition.

// original input
const result = (principal * (1 + rate / compoundsPerYear) ** (compoundsPerYear * years) - principal) / years + fixedFee * 12 - discount;

// old formatting behavior
const result =
  (principal * (1 + rate / compoundsPerYear) ** (compoundsPerYear * years) -
    principal) /
    years +
  fixedFee * 12 -
  discount;
  
// new formatting with experimentalOperatorPosition: start
const result =
  (principal * (1 + rate / compoundsPerYear) ** (compoundsPerYear * years)
    - principal)
    / years
  + fixedFee * 12
  - discount;

Putting the operators at the start of the line is just easier to read (in my opinion), especially if you’re scanning quickly. And with the amount of code LLMs generate, there’s a lot more scanning quickly than there used to be.

So I guess chalk both of these changes up to modern, AI-heavy coding workflows.