feat(lint): add prettier formatter to assert LESS files whitespaces

[mvorisek]

Compared to Stylelint, Prettier is very simple tool and I am quite supprised Stylelint is deprecating the whitespace rules in favor of Prettier. For LESS it seems ok, for JS, we should never enable Prettier as formatting is part of a code and improves readability.

As Prettier is an opinionated formatter instead of an linter, we need to satisfy it everywhere without exceptions.

When I was crafting this PR, I found several Prettier issues and proposed changes to Prettier:

• Fix semicolon duplicated at the end of LESS file prettier/prettier#14007
• Fix no space after unary minus when followed by opening parenthesis in LESS prettier/prettier#14008
• Do not change case of property name if inside a variable declaration in LESS prettier/prettier#14034

In this PR, these changes are contained and Prettier is patched before it is run. Once the changes are merged in prettier and stable release is made, they can be removed.

This PR fixes minor whitespaces unfixed/undetected in GH-2610.

And also asserts:

• PHP port of the LESS fails to compile colors.less #1832
• feat(lint): add stylelint overrides and variation files #2593 (comment)

Prettier has no built in support to dump the diff - prettier/prettier#6885 - so we dump it in the CI using git.

[mvorisek]

PR is done, Prettier fixes with patches looks reasonable. Compiled semantic.min.css is binary the same as before this PR.

[lubber-de]

Please resolve conflicts

[lubber-de]

In this PR, these changes are contained and Prettier is patched before it is run. Once the changes are merged in prettier and stable release is made, they can be removed.

Seriously? This is really hacky. You want to use a tool, which does not do what we need... Why not fork prettier.io instead and use that?

[lubber-de]

So please fork the Prettier under fomantic GH org and apply there all 4 patches.

I sent you an invite for Admin access to https://github.com/fomantic/prettier, so you can freely maintain it 🙂

[lubber-de]

Finally LGTM 👍🏼

I would like to thank you very much for this and especially for your patience and understanding for all the (critical) feedback i gave 😉

[lubber-de]

@mvorisek It seems prettier has merged all of your PRs 🙂
They havent published a new version yet, but once they do, is everything covered what we need so we can switch back to the original prettier repo and remove the fork again?

[mvorisek]

@lubber-de all except the one which adds new lines when comma is present - fomantic/prettier@d9c5a04 and fomantic/prettier@ca814b7

I can try to propose it to Prettier as well, but I am not sure if it will be accepted

[lubber-de]

I can try to propose it to Prettier as well, but I am not sure if it will be accepted

Yes, please 😊 they seem to trust you

[mvorisek]

I have about 1500 contributions / year in GH. But it is not only about personal credit, the previous PRs were bugfixes, this one is feature request about styling. AFAK such FR should not be accepted, I will do my best to stress the importance of increased readability with a an example, but I cannot promise anything.

[mvorisek]

@lubber-de I have crafter 14208 prettier PR. Currently we enforce NL based on the original presence - fomantic/prettier@edb343f - but such behaviour is not possible in prettier offcially (it rebuilds AST into one stable format).

So the 14208 prettier PR is designed to enforce line break in all CSS values when comma is present. See https://github.com/mvorisek/prettier/commit/da28053ff997aa259ee41046a7377bcfc35a7ee9 . Is such format ok with you or do you have any idea of better prettier formatting?

[lubber-de]

TBH, no, or, "depends". Forcing a NL always will bloat the view for example in site.variables where the unicode ranges for the Lato font is given. -> comma list in one line is ok
In situations like multiple box shadows a NL is nicer for the designer to compare -> NL is ok

There still exists "prettier-ignore", but i fear we would make use of that too often in all the files.