Docs: Add linting to rule doc example code blocks (1 of 3) (refs #2271)

[IanVS]

This is a work in progress, and will take some time to complete. However, if anyone has feedback on this, please speak up now before I go through all 170-something rules. :)

One specific item: some of the lines get pretty long with these expected errors. I'm not sure how that will look on the eslint.org site. Is there a way to check that?

[ilyavolodin]

Nice! I like it.

[BYK]

😲 👍 🎉

[IanVS]

I had to turn off linting for rule linebreak-style, which I did by removing the js info string from the code fences. This is because the \r\n and \n are being treated as code, and not linebreaks.

[btmills]

Would moving the line endings into informational comments work? It wouldn't change the meaning of the examples, but it would make them valid JS.

[IanVS]

@btmills, I like that idea. That's what I'll do.

[nzakas]

Just a heads up - the longer this sits, the harder it will be to merge. :)

[IanVS]

I understand, but I'm not just sitting on it. I've been spending several hours a night on it, and am maybe 30% done at this point. 😞

I've been rebasing periodically, and so far it doesn't have any problems. I'll give it a good once-over when I'm complete to make sure I've not missed anything that's been added. I'm hoping to have it done within another week or two.

[IanVS]

A bit of a snag: some rule examples require ecmaFeatures: { modules: true } and others require modules: false. Until a better solution can be found (maybe involving globbing), I'm removing the info string from the rules which require modules to be turned off. These are:

• no-delete-var
• no-dupe-args
• no-lone-blocks (a solution to "Use of future reserved word in strict mode" false positive with eslint-env es6 #2134 would also help here)

[IanVS]

I followed @btmills advice for linebreak-style, and also added the actual CRLF line endings as appropriate, so that linting works correctly. To do so, I also needed to add a .gitattributes to prevent automatic conversion on that file.

[nzakas]

No worries, just wanted to flag that. You might want to consider ways of doing partial commits to limit the merge conflict likelihood. "Big bang" commits are almost always a bad idea. :)

[IanVS]

OK. I'm happy to split into a few commits if that's an option. It would actually be good to at least see how this looks in some rules on the site, too. I'm about half-way through, so I'll squash and rebase with just the rule changes so as not to break the build. After that's merged, I'll finish up the rule changes and finally add the changes to makefile.js

[ilyavolodin]

@IanVS You can take a look at #397 that's where I migrated all unittests, so had to go through the same trouble as you are going through right now.

[IanVS]

OK, tracking in: #2271 (comment)

[ilyavolodin]

Nice touch!

[ilyavolodin]

LGTM for the first batch