Make line width configurable on the CLI ?

[xfalcox]

We are evaluating this on discourse/discourse and all our plugins.

Things are looking good, but this jumped to me as weird:

https://github.com/discourse/discourse-chat/pull/1030/files#diff-001301097537175b30c546260016452d2ff11f02435e4acb6cbd4143d744b407R199

Is this because of line width? I see ternaries being removed in many places because of, I assume, line width. Can we get a cli option for line width? We have no immediate interest in forking nor using syntax_tree as a lib at the moment, so that would be great to help adoption.

[xeger]

Configurable line width would be a big help for me, too.

I have been focusing on the VS Code extension and not really on the core gem. The gem has a plugin architecture; if I were to do line width, I would see about making it a plugin (might need to adjust the core code to enable that).

The other factor is, how to specify the parameter (desired max width)? Your idea of using an environment variable was interesting. I know the philosophy of this gem is KISS / zero-config as much as possible -- introducing any config is a bit of a bummer.

An alternate idea would be to introduce a way to specify parameters for plugins, on the CLI or at instantiation time, --plugin=foo/bar:120 or something like that.

Or, perhaps the gem could ship with a plugin that expands line width to 120 / 160 / etc, and people can subclass that plugin and install their own subclass if they want another value.

Anyhow: random musings. Curious to hear @kddnewton's take on line length. It's not blocking adoption in my company but would be nice to have down the road.

[kddnewton]

Yeah I don't really want to add more configuration but print width is so fundamental I think I have to. I think I'm going to add --print-width as a command-line option to all of the commands that it makes sense.

That being said @xfalcox I really wouldn't suggest increasing it all of the way to 120. It's fundamentally different from something like rubocop's line length for instance. This doc here: https://prettier.io/docs/en/options.html#print-width goes into why and is a pretty good explanation. I've seen people have success with 100 occasionally, but leaving it at 80 is definitely a better way to go in the long run (in my opinion).

That being said, I am going to support this option.

[xfalcox]

Hahaha you are right on the money with the 120. I implemented both 120 and 100 as plugins on my fork and we found 120 removing too much if blocks into guard clauses.

We are now evaluating 100 as a middle ground!

[kddnewton]

@xfalcox --print-width is in the CLI for v3.1.0