Switch to Sass and Stylelint

[XhmikosR]

I open this now, but requires some of my other PRs merged.

I will split the output folder change to a separate PR. See #2544

---

Switch to Sass.

Also:

• switch to double quotes
• remove leading zeros
• use double colon pseudo selectors
• merge a few selectors
• restored prism-tomorrow.css and moved it in vendor

DO NOT SQUASH

[XhmikosR]

This is ready, but requires #2544 to be merged first.

I checked the (beautified) CSS and everything is fine. The diff can be seen here https://gist.github.com/XhmikosR/b22af72fabd48b1b5584bf9d736d7c05/revisions

[XhmikosR]

This can be merged after #2625 and after a rebase.

[Trott]

@nodejs/website

[XhmikosR]

Here's the latest diff of the generated unminified CSS https://gist.github.com/XhmikosR/10aaa5ea030adfc87838daad111335e4/revisions

[phillipj]

Great job! 💯 Changes looks okey at a glance.

GitHub's diff view gives the impression git thinks the original .styl files are deleted, which is sad cause we'd in practise loose the history of the style changes done throughout the project's lifetime so far. Think it would be valuable if we could make git understand the files has been renamed, instead of delete (and new .scss files introduced), since that would make it simpler to follow the history back when needed sometime in the future.

I would think git mv would do the trick in the regard:

$ git mv layouts/css/_base.styl layouts/css/_base.scss

Any thoughts?

[phillipj]

..sorry, I obviously pressed the wrong button while posting the comment above.

[XhmikosR]

I think this happens because the files contain a lot of changes, so they are basically new.

[XhmikosR]

I actually tried this with git mv and it's the same. The files have many changes that git considers them as new.

[phillipj]

Hm okey, thanks for testing! From a distance it didn't look like too much changes to the content, but guess it's on the borderline of what makes git consider it a new file.

The only trick I can think of what that will allow us to follow the history of back to the original files, is to first rename the files as is and commit, then make the actual content changes as a second commit.

I've generally made a habit of making sure git log --follow -- <whatever-filename> can be used to track historical changes later when applicable. Whether or not it's worth the extra effort in this scenario is up to you.

[Trott]

The only trick I can think of what that will allow us to follow the history of back to the original files, is to first rename the files as is and commit, then make the actual content changes as a second commit.

That would mean we'd have a broken build in the first commit, though, right? We don't do much git bisect in this repo though, so maybe that's OK?

[phillipj]

Yes, indeed the first commit would cause havoc on its own. Unless we can configure stylus to use a different file extension temporarily. But then it starts to be quite the detour just for the sake of preserving git history 😬 Would you consider it worthwhile Rich? Or should we just forget about it?

…

On Sat, 12 Oct 2019 at 06:16, Rich Trott ***@***.***> wrote: The only trick I can think of what that will allow us to follow the history of back to the original files, is to first rename the files as is and commit, then make the actual content changes as a second commit. That would mean we'd have a broken build in the first commit, though, right? We don't do much git bisect in this repo though, so maybe that's OK? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#2530?email_source=notifications&email_token=AAJMWE7VRKKSTNBQ5FXZCU3QOFFSXA5CNFSM4IUQSQYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBVEXQ#issuecomment-541282910>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMWE6OVRTDFMP2TBXEOFLQOFFSXANCNFSM4IUQSQYA> .

[XhmikosR]

The build won't fail since the second patch in the batch will be the Sass switch.

I will do it later, just remember to not squash the patches, otherwise it will be moot :P

[XhmikosR]

I fixed a couple more issues I noticed, namely the server watch for scss files and README.md and TRANSLATION.md references to stylus

[phillipj]

Looks great! Although GitHub's UI suggests the old files are deleted and completely new ones are added, it works as expected locally;

$ git log --oneline --follow -- layouts/css/_base.scss
d642361e (HEAD -> pr/2530, upstream/pr/2530) Switch to Sass.
7a40f336 Rename *.styl files to *.scss
1d687cf6 Stylus: always use variables for colors. (#2528)
25a8772e Fix iframe HTML validation errors.
a714afcc Fix table related HTML validation errors.
7bbb7823 Fix IE and minor tweaks (#2392)
...

[XhmikosR]

Cool, just need another approval and remember, do not squash :)

[XhmikosR]

BTW this PR uses node-sass. We could look into using dart-sass in another PR which might save us quite a few devDependencies.

[MylesBorins]

LGTM