Content: Ensure indentation consistency in `files/` folder

Created on 8 Dec 2020  ·  8Comments  ·  Source: mdn/content

Hear me out: I'm not trying to start the "Tabs vs. Spaces" war.

Content dumps contain some edits that are predominantly or exclusively indentation changes: tabs to spaces or spaces to tabs. I have no idea how these edits occur (do contributors feel the urge to change indentation? do they copy-paste articles to their favorite text editor, which converts indentation secretly from them, and then copy-paste back?). However, I'm sure these accidental edits will be even more common once people start checking out mdn/content and editing it with their desktop editors.

Most helpful comment

I understand your issue description, but I don't understand your issue title :)

I changed it, hopefully now it's better.

Whatever we do, let's introduce it in a way that we're not forced to mass-edit thousands of files all in one big sweap.

Yes, we can break it up into multiple steps to avoid drastic changes. I propose:

  1. Consider introducing new tabs a flaw, as you suggested
  2. Add EditorConfig
    This will ensure that when contributor updates a piece of content with with a local checkout, the file gets updated automatically (by the text editor).
  3. Eventually, once all content gets updated, consider tabs an error.

All 8 comments

I understand your issue description, but I don't understand your issue title :)

What are you proposing?
I for one wouldn't mind seeing all tabs disappear and introducing one should be considered a flaw.
But we could also consider a much harsher thing which would be that if we find a single ^\t character in the content, it's considered a busted piece of content and it breaks CI. We have some good choices.
What did you have in mind?

Whatever we do, let's introduce it in a way that we're not forced to mass-edit thousands of files all in one big sweap.
Perhaps once we've figured out what it should be and we've cleaned up the content, we can return to the contribution guide and update some written rule about indentation. Then, with linting + policy combined, we can get some consistent sanity here.

I understand your issue description, but I don't understand your issue title :)

I changed it, hopefully now it's better.

Whatever we do, let's introduce it in a way that we're not forced to mass-edit thousands of files all in one big sweap.

Yes, we can break it up into multiple steps to avoid drastic changes. I propose:

  1. Consider introducing new tabs a flaw, as you suggested
  2. Add EditorConfig
    This will ensure that when contributor updates a piece of content with with a local checkout, the file gets updated automatically (by the text editor).
  3. Eventually, once all content gets updated, consider tabs an error.

This will ensure that when contributor updates a piece of content with with a local checkout, the file gets updated automatically (by the text editor).

Only when the editor is configured to respect it.

Perhaps a script could search/replace tabs as GitHub action? (Would that be another commit, that gets respected?)

@bershanskiy I 100% agree with that plan.
I think in some far future we can run Prettier on all the code, but that's a huge undertaking. And I'd rather save that energy towards Markdown.
Would you be interested in putting together a flaw detection PR and stuff. It's not easy but it gets pretty easy if you just look at some of the other existing flaws and how they are used in the builder and in the Toolbar. I'm more than happy to help you with a patch if you get it started. But before we begin, can we please have @chrisdavidmills say his mind on this topic. Chris?

@Ryuno-Ki The search/replace functionality gets taken care of by the flaw framework. E.g. we have a lot of external images that should be downloaded and checked in. That's something the flaw framework takes care of. It also makes it incredibly easy to do it in relatively smaller chunks without having to have a PR with 1,000+ files.

@peterbe yes, I wouold love to see this on MDN. It would help fix the problem of different people's code editors doing different things with indentation, and it would help enforce consistency.

And we already have a guideine written for this: https://developer.mozilla.org/en-US/docs/MDN/Guidelines/Code_guidelines/General#Indentation

And thanks @bershanskiy for bringing this up. You rock!

Would you be interested in putting together a flaw detection PR and stuff.

Yes, I'm interested. It's not release blocking, right? I'll take a look at this over the weekend.

It's not release blocking, right?

Not at all.
There are tonnes of bad things in the content that we need to start cleaning up with a mixture of automation and gentle strategies.
When we release, things'll be imperfect. Just like the Wiki. But slowly we'll sharpen and sharpen our automation tools.

Was this page helpful?
0 / 5 - 0 ratings