Add new formatting options: colors, compactParenthesis, maxOperatorArgsLength

[foul11]

Hi, the library is good.
I use it to debug the output from kysely, to display nice error messages.
For this I was missing some options similar to options from util.inspect.
below is a visual demonstration of what I added:

Specifically:

• Syntax highlighting
• Block layout, like inline layout but block
• Limit on the maximum number of elements in a tuple

All changes are under flags that are disabled by default, so the changes will not affect dependent projects.
Let me know if any further improvements need to be made.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[nene]

Hi there. Thanks for the pull request.

However, this is too much functionality bundled into one large change.

I can immediately say the following:

Syntax highlighting

This is a no. There are other libraries out there to do syntax highlighting. I can't point to any specific one off the top of my head, but I'm pretty certain this area is well covered. I really want to limit the scope of this library to just formatting.

Limit on the maximum number of elements in a tuple

This seems something very specific to your use-case. I generally want to avoid having options that change what the code does. Currently a single odd exception to this is the params option which allows for parameter substitution.

Block layout, like inline layout but block

This part I don't quite understand. Could you give me a better overview of what this does and perhaps also how it was implemented.

[foul11]

It's a shame you have this opinion even about basic syntax highlighting.
I think it would be quite convenient for debugging.

Block layout, like inline layout but block

console.log(
  format(`INSERT INTO user VALUES (${'?'.repeat(10).split('').join(',')})`, {
      compactParenthesis: true, // new option, activate block layout
      expressionWidth: 10,
  })
)

-- with new options, block layout
INSERT INTO
  user
VALUES
  ( ?, ?, ?, ?,
    ?, ?, ?, ?,
    ?, ?
  )

-- default behivator, inline layout
INSERT INTO
  user
VALUES
  (
    ?,
    ?,
    ?,
    ?,
    ?,
    ?,
    ?,
    ?,
    ?,
    ?
  )

[foul11]

In my case, I'm formatting a query in which the number of params can reach up to 30,000, so it would be nice to be able to reduce the output

[nene]

It's a shame you have this opinion even about basic syntax highlighting. I think it would be quite convenient for debugging.

I'm sure it would be very convenient. But so would be many other features that this library could have. I don't want to come across as somebody who just pushes back on all the feature proposals. However I do think it is better for a library to concentrate on doing one task well. And frankly I think SQL Formatter is struggling even with that single task.

[nene]

I'm formatting a query in which the number of params can reach up to 30,000

Wow 😲 🌋

Care to provide some context as to how one ends up with so many parameters? Like in PostgreSQL there's a limit of just 1600 columns per table.

[nene]

Regarding this "Block layout" feature, this I could very well consider. But I first need to understand it a bit more.

I kinda see how it's working with a huge amount of ? placeholders, but how does it intersect with everything else? Does it effect all comma-separated lists or just some? How does it work when the comma-separated items have different sizes? For example, will it be applied to the list of columns in CREATE TABLE and how will the resulting output look?

I could figure this all out by reading & running the code, but it really should be up to you to convince me that it's a great feature this formatter should have.

Plus I'm currently away from a computer and will likely be mostly offline for the rest of this week.

[foul11]

Care to provide some context as to how one ends up with so many parameters? Like in PostgreSQL there's a limit of just 1600 columns per table.

I use sqlite in my application, it is application-parser, and sometimes I need to iterate through quite a few rows in a table using their id, I get a query like WHERE id IN (?,?,?, ... more params), sqlite allows me to use up to 32766 parameters, and I use batches to iterate over the entire input. I don't actually store that many columns. But this limitation also affects me when inserting, since I need (rows * columns) params to insert into one query.

About "Block layout" I used it as a replacement for "Inline layout". I only found one place where it was used, in the formatParenthesis function, so I simply added a switch that changes the behavior from "try to fit everything on one line and if that doesn't work, fall back to writing each argument on a new line" to "we try to fit everything on one line and if it doesn't fit, go to a new line and try to keep stuffing arguments while there's room."

That is, it is a kind of change in the node placement strategy, and since it uses only the length of the incoming token (as the "Inline layout" does), it should not cause problems.

[nene]

So... I tested out this compactParenthesis option. My takeaway is that it doesn't really work well with other constructs. For example, when applied to CREATE TABLE, you'll get:

CREATE TABLE foo ( id INT, foo TEXT, bar TEXT, age INT, skillset TEXT,
  blah TEXT, blah2 TEXT, blah3 TEXT, blah4 TEXT
)

Maybe it's not too bad... but I don't think anyone would really want this.

Also importantly this indentation style:

SOME CONSTRUCT ( ...........
    ..........................
    ........................
    ..........................
    ................
)

doesn't match with the indentation style that SQL Formatter uses:

SOME CONSTRUCT (
    ......................
    ..........................
    ........................
    ..........................
    ................
)

Finally, I think there's some bug in the implementation, as the long lines end up not being broken up where I would think they should:

INSERT INTO
  foo ( type, model, color, size, material, location,
    price, owner, year, history, rating, review, warranty,
    availability, discount, stock, supplier
  )
VALUES
  ( 'house', 'Model A', 'red', 'large', 'brick',
    'city center', 250000, 'John Doe', 2020,
    'Built in 2020, this house has a modern design and is located in the city center.', 4.5,
    'Great house with a lot of space and a nice location.', '10-year warranty included.', 'Available',
    '5% discount for first-time buyers.', 10, 'Best Homes Inc.'
  );

-- what I would expect to see instead:
INSERT INTO
  foo ( type, model, color, size, material, location,
    price, owner, year, history, rating, review, warranty,
    availability, discount, stock, supplier
  )
VALUES
  ( 'house', 'Model A', 'red', 'large', 'brick',
    'city center', 250000, 'John Doe', 2020,
    'Built in 2020, this house has a modern design and is located in the city center.',
    4.5,
    'Great house with a lot of space and a nice location.',
    '10-year warranty included.', 'Available',
    '5% discount for first-time buyers.', 10,
    'Best Homes Inc.'
  );

[nene]

Also importantly. I think this really should be implemented as a separate indentation style. That is, instead of having a separate option compactParenthesis: true, this style should be specified through indentStyle option. Something like indentStyle: 'compact'.

I should note though that currently the indentStyle option is deprecated, as I'd really like to get rid of the two very awkward styles it supports.

Ideally though I would not have any indentation style configuration, as it just adds more things to maintain. But compared to these two styles, the one proposed by you looks both more maintainable and more useful. So I'd rather have the one proposed by you than these two existing ones.

[nene]

In its current form this PR is not acceptable.

Primarily because it bundles together 3 new features out of which only one I would consider accepting.

That one feature also needs more work to:

• match the existing indentation style used by the formatter
• solve bugs in the implementation
• use indentStyle option for enabling this style.

I encourage you to make a separate PR that only implements that one feature.