jdavisclark
commented
10 years ago @mokkabonna I'm a little bit out of the loop here...but what projects actually use the html css sections? What is the source of truth for the file spec?
Open mokkabonna opened 10 years ago
jdavisclark
commented
10 years ago @mokkabonna I'm a little bit out of the loop here...but what projects actually use the html css sections? What is the source of truth for the file spec?
mokkabonna
commented
10 years ago Well that's the problem, the actual project (js-beautify) does not define the config file with html/css sections. This is probably since it was originally just for js. But since the project does support HTML/CSS right now, it is leading to other projects taking the logical step from that, meaning adding HTML/CSS to the config as well. It is also an discussion in js-beautify if to include support for html/css in the config or actually just split out the two beautifiers info separate projects.
Meaning users can't use one plugin that expects the config without the html/css parts, with another plugin that do not expect it.
It would help users if because of this current confusion jsformat would actually be "kind" and support both formats. This can be done safely.
HTMLPrettify uses what imo should be the format of the .jsbeautifyrc file
https://github.com/victorporof/Sublime-HTMLPrettify#using-your-own-jsbeautifyrc-options
jdavisclark
commented
10 years ago Im with you now. Dug around a little and it looks like this is the 'official' .jsbeautifyrc spec. I don't think I am opposed to supporting the Sublime-HTMLPrettify .jsbeautifyrc format as a fallback; impact is extremely minimal.
The discussion surrounding splitting the js-beautify project up has been going on for a while. I weighed in at one point with a preference for splitting things up, but haven't checked back in a while...
Going to mark this as a low priority feature, but it's simple enough I'll probably get to it soon.
See https://github.com/einars/js-beautify/issues/391 and https://github.com/victorporof/Sublime-HTMLPrettify/pull/74
This needs to be resolved among all the projects imo. This just creates problems for the users.
Best approach IMO for JsFormat would be to support the nested js/html/css approach, but fallback to merging the options at the top level of the config file if no js property exists. This would give you backwards compability as well.
JsFormat does the climbing of parent folders correctly, but the config "wrong" (incompatible with real features of js-beautify, but, hey so does js-beautify itself).
And Sublime-HTMLPrettify does the climb wrong, but the config "right" (IMO, makes the different html/css/js options separate)
Users are left confused :)