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.