prettier-plugin-hug-call-arguments weekly downloads statistics

prettier-plugin-hug-call-arguments

Fixes prettier/prettier#11080.

Usage

Requires Prettier 3.x as a peer dependency.

npm install --save-dev prettier-plugin-hug-call-arguments

yarn add --dev prettier-plugin-hug-call-arguments

pnpm add --save-dev prettier-plugin-hug-call-arguments

Add it to your Prettier config (.prettierrc, .prettierrc.json, prettier.config.js, or the "prettier" key in package.json):

{
  "plugins": ["prettier-plugin-hug-call-arguments"]
}

No other options — it works automatically wherever Prettier already formats JS/JSX/TS/TSX with the estree printer (the babel, babel-ts, and typescript parsers). Nothing to configure, and every case it doesn't recognize is left to Prettier's own formatting untouched.

Examples

Prettier hugs the last argument of a call when it's a function/object/array literal:

app.get("/x", (req, res) => {
  res.send("ok");
});

...but not when that literal is wrapped in another call, which is a very common pattern for middleware wrappers (Express catchAsync, error boundaries, decorators-as-functions, etc.):

// input
app.delete('/campgrounds/:id', catchAsync(async (req, res) => {
  const { id } = req.params;
  await Campground.findByIdAndDelete(id);
  res.redirect('/campgrounds');
}));

// vanilla Prettier output
app.delete(
  "/campgrounds/:id",
  catchAsync(async (req, res) => {
    const { id } = req.params;
    await Campground.findByIdAndDelete(id);
    res.redirect("/campgrounds");
  }),
);

// with this plugin
app.delete("/campgrounds/:id", catchAsync(async (req, res) => {
  const { id } = req.params;
  await Campground.findByIdAndDelete(id);
  res.redirect("/campgrounds");
}));

It also flattens method chains instead of breaking every .method() onto its own line — a common look with query builders:

// input
db.updateTable('User').set({
  isDeleted: true,
  profilePicture: null,
  username: null,
}).where('id', '=', user.id).execute();

// vanilla Prettier output
db
  .updateTable("User")
  .set({
    isDeleted: true,
    profilePicture: null,
    username: null,
  })
  .where("id", "=", user.id)
  .execute();

// with this plugin
db.updateTable("User").set({
  isDeleted: true,
  profilePicture: null,
  username: null,
}).where("id", "=", user.id).execute();

How it works

This plugin wraps Prettier's built-in estree printer and only overrides the print step for CallExpression, ArrayExpression, ObjectExpression, ConditionalExpression, and ArrowFunctionExpression nodes that match one of a few narrow, specific shapes.

Preserving a layout you already chose:

// input
foo(
  1,
  2,
);

// with this plugin — kept exactly as written
foo(
  1,
  2,
);

// bar(1, 2, 3) stays on one line — nothing to preserve, so it's printed
// the normal, printWidth-aware way

Prettier already does this for object literals by default (objectWrap: "preserve"): write { with a newline before the first property and it stays multi-line, even if it would fit on one line. This plugin extends that same "respect how the author wrote it" behavior to call arguments, array elements, and arrow function parameter lists, which Prettier doesn't normally preserve — those always auto-collapse to fit printWidth regardless of the original formatting.

• a list is split one item per line when there's a newline anywhere between its own items — right after the opening (/[/{, between two items, or right before the closing bracket — and at least two items. Objects get the same rule, extending Prettier's own "newline before the first key" check

• newlines inside an item never count: every list decides for itself. A list written on one line stays on that line even when one of its items splits, and only that item breaks:

  // input
  foo([1, 2, [
    3, 4]], d);
  
  // output — the outer array and the call stay inline
  foo([1, 2, [
    3,
    4,
  ]], d);
  

  The same applies to a ternary written on one line (a ? foo([\n...\n]) : null). Either one falls back to Prettier's own layout when even its opening line wouldn't fit printWidth

• takes priority over every other feature below: a layout you explicitly chose is never fought by this plugin's own hugging heuristics

• bails on comments anywhere in the list, a sparse array, TS type arguments/parameters, or (for parameters) anything but a plain arrow function — a function expression/declaration has a name and block body to reproduce too, which is more than this narrow check takes on

Hugging a call-wrapped callback:…