Add editorconfig

[chenrui333]

relates to #11551

[k8sio-netlify-preview-bot]

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 7ee13af

https://deploy-preview-11551--kubernetes-io-master-staging.netlify.com

[zacharysarah]

@chenrui333 👋 Thanks for this--I know you got some recent feedback about configuring your editor to avoid changing unrelated whitespace.

I'm still not sure whether the problem this PR addresses is sufficiently pervasive to require repo-level enforcement, or that this change will solve more problems than it creates. @lucperkins @Bradamant3 @kbhawkey Any feedback?

[chenrui333]

yeah, my past experience is good since it would reduce the noise for non-modified lines (mostly for coding lines).

I would imagine we probably need one time cleanup (to conform with the coding style enforced by the rules in editorconfig) if we agree to have this config file, but it would definitely beneficial in the long run. And also editorconfig is very generic config file, it has been widely supported across the editors.

Hope this helps!

[chenrui333]

I just found another use case that we might benefit with doing the localization PR review.
comment from @tengqm
#11538 (comment)

[lucperkins]

I absolutely consider editorconfigs to be a best practice. They don’t force anything on people that use editors that don’t support them, and they make standards enforcement effortless for those who do. I currently have a PR open to fix a problem where some Sass files were indented using spaces and others using tabs, which would have been avoided from the get-go with a proper editorconfig.

[bradtopol]

Assigning @zacharysarah since he is already engaged on this

[kbhawkey]

@chenrui333, I have not used .editorconfig. Is this correct, https://github.com/editorconfig?
It seems that some editors have this plugin built-in, other editors can install a plugin. Are there any drawbacks to using this plugin? There are a number of different file types in this project. How do other hugo users solve this problem?
I support setting up and documenting how docs/code should conform to the project's formatting style.
Ideally, before a PR is submitted, a script would check for line length, formatting, and whatever else needs to be checked 😄 . The script could be part of the local build/test, or possibly added to the CI/Travis build.

[chenrui333]

@kbhawkey Sure, I will try to answer your question one by one.

1. editconfig website
   Yeah, the github editorconfig org is the link that you attached, and the website link is https://editorconfig.org.
   There should not be any drawbacks, but we should do some one-time docs cleanup after agreeing the PR merge.

2. how does website users to leverage the editorconfig rules

There are a number of different file types in this project. How do other hugo users solve this problem?
This is static editor config thing.

Not every editor needs the plugin to apply the coding style implicitly. Check out this link, https://editorconfig.org/#download.

3. CI/CD process for the coding style
   As specified above, if the plugin exists, the rules in editorconfig would be silently applied. But yeah, it would be nice to have some sort of linting process before the commit or part of the travis CI process.

It would be something like this tool, https://github.com/jedmao/eclint.

I can actually take a look on that.

[chenrui333]

@kbhawkey This is the PR trying to use ec2lint fix * and enforce the coding style.
PR, https://github.com/chenrui333/website/pull/1

If we want to enforce in the CI/CD build, here is the script:

before_script:
  - npm install -g eclint
  - eclint check *
  - eclint fix *

[kbhawkey]

After some thought, I am not sure about a script to enforce the .editorconfig rules.
Everyone should be encouraged to follow the project standards (writing and formatting).

[chenrui333]

yeah, the idea to have the editorconfig is just to remove the noise from the PR review (the irrelevant changes) and facilitate a better PR review experience.

[zacharysarah]

Thanks for your patience, @chenrui333!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zacharysarah

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [zacharysarah]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[chenrui333]

@zacharysarah thanks a lot for your approval. After this, it is going to bring lots of changes (probably undesired from contributors).

It would be very good discussion topic in the sig-docs meeting.