JS Beautifier "short objects" #55
Conversation
…e options instead.
Previously, var lines were indented to 4 spaces always, even if the indent size = 8. There's not much reason for doing that.
…dable characters obfuscated as \x codes with the equivalent)
…ases to prove it needed to go
|
closing this pull request. may send again int he future |
|
👍 This is a much needed feature. Why was it not merged? |
|
I have no idea. Probably because it is python-only and nobody had a willpower to port it to javascript, and it would be bad if python and js would diverge too far. |
|
What a bummer! :( |
|
@mrchief - feel free to file an issue to for this feature (reference this pull request). At least then we can track it as an open request for future milestone. |
|
@einars Does it also mean that someone coming up with a JS fix has to come up with a python port? I can see someone landing into a situation where the JS fix (for a new feature) is not merged as no one has come with a python port yet and over time, the project changes so merging the JS fix becomes impossible or very hard, in effect impeding feature growth on the library as a whole. |
|
While it would be very welcome, if you can't update the python version of the library and your js fix/feature is excellent, most probably somebody — me or @bitwiseman or somebody else here — will gladly do that. And, if nobody responds, then probably it just went under the radar, try again and write a comment: the notification might have been received in a very bad moment, intense day, etc and was forgotten soon after, etc. Yes, that sucks, and yes, these things happen all the time. I, for example, feel somewhat bad about this very pull request: I don't remember its history, but I see that it was sitting without an attention for 5 months, and now I'm sorry for @chrisjshull . At the same time, a comment "hey, what's about this, is it bad, or are you going to do something about it?" might have fixed situation with this forgotten changeset. |
|
👍 |
|
This is a great feature. Is there a configuration setting to never split objects into multiple lines either in this patch or in the current version? |
This commit adds an option on the JS Beautifier CLI allowing the user to specify the maximum length of "short objects".
Typically the JS Beautifier expands all JS object declarations into multiple lines, each line having a key value pair. However, this is overly verbose for many situations (e.g. short objects which could easily fit on a single line).
Right now this is only for the python CLI.
--short-object=0
objects less than this many characters long
will stay on a single line (newlines within
the object's code will override this)
recommended: 80
Currently, "short objects" defaults to 0, which disables it.
Recommended value might be 80, via
--short-object=80e.g.:
a = {a:1,b:2}becomes:
a = { a: 1, b: 2 }also:
a = {c:{a:b,b:[1,2,34,5,6,7,8]}}becomes:
a = { c: { a: b, b: [1, 2, 34, 5, 6, 7, 8] } }changes posted back under the MIT license