Html5-boilerplate: RFC : ESLint로 마이그레이션

누군가? 나는 현상 유지에 만족합니다. ESLint는 훌륭하지만 변경을 확신 할 필요가 있습니다 (그러면 누군가 PR에서 변경을 _ 만들어야합니다.) 나는 이것을 한 주 동안 열어두고 아무 조치가 없으면 마감하겠습니다.

나는 이것을 위해 PR 할 수있다. ESLint는 자바 스크립트 생태계에서 가장 널리 사용되는 도구 중 하나입니다.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen 나는 이것에 대해 @amilajack 의 편에 완전히 있습니다.
내가보고 싶다면 웹에서 수집 한 데이터와 둘을 간단히 비교했습니다.

감사합니다. 정말 대단한 일입니다. 다른 사람이 차임하고 싶습니까?

@amilajack PR 제안에 감사드립니다. 정말 감사합니다.

@roblarsen 천만 에요!
@amilajack 도움이 필요하면 언제든지 메시지를 보내주세요. : construction_worker :

@amilajack 아직 작업 중입니까?

@ryzokuken 제가 살펴보고

ESLint 위에 추가 된 Standard 와 꽤 인기가있는

@ArmorDarks 내가 스탠다드 스타일을 좋아하지만 다른 사람들이 그것을 따르도록 강요하는 것은 좋지 않다고 생각합니다. 특히 많은 지식이나 경험이없는 개발자는 코드로 인해 예기치 않은 런타임 오류가 발생하고 추가 문제가 발생하여 프로젝트 문제가 증가 할 수 있습니다.

내가 프로그래밍 언어의 유연성을 좋아하는만큼 그러한 특전에는 대가가 따릅니다. 문제는 우리가 그 대가를 지불 할 의향이 있는지 여부입니다. 엄격한 규칙은 거의 항상 프로젝트가 성장하더라도 코드를 더 쉽게 이해하고 결과적으로 더 안정적으로 만듭니다.

또한, 세미콜론이 인기를 끌면서 Airbnb의 JavaScript 스타일 가이드를 예로 들었습니다. GitHub에서 가장 별표를받은 저장소 중 하나이고 NPM에서 다운로드 수가 더 많습니다. [1] [2] [3] [4]

또한 이미 세미콜론을 사용하고 있기 때문에 모든 JavaScript 파일을 업데이트해야합니다. [5] [6]

따라서 저는이 주제가 자전거 흘릴 만한 가치가 있다고 생각하지 않습니다.

참조 :

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

어쨌든 코드 스타일 분쟁으로 귀결 될 것입니다. 나는 단지 전투 테스트를 거친 대안을 제안하고 있습니다.

Btw, 어떤 옵션을 사용하든 상관없이 (프로젝트 자체 규칙이있는 ESLint이든, airbnb와 같은 인기있는 ESLint 구성이든, 표준이든) _ 어쨌든 사용자가 따라야 할 무언가를 시행 할 것입니다 _. 따라서 정확히 무엇을 시행할지의 문제입니다.

이 시점에서 나는 최소한의 중단으로 eslint로 전환하고 싶습니다. 여기에는 최소한 새로운 규칙이 무엇이어야하는지에 대한 논의없이 우리가 현재 가지고있는 기존 규칙을 없애는 것이 포함됩니다 (이것이 eslint에 대한 기존 PR이 DOA 인 이유입니다).

예를 들어 저는 세미콜론 언덕에서 죽을 것입니다.

참고로, 규칙 세트의 실제 소비자는 관리자와 양심적으로 PR을 만들고 실제로 코드를 테스트하는 모든 사람으로 제한됩니다. 우리는 dist에서 eslintrc 를 배송하지 않을 것입니다. 프로젝트 측면에서 진정한 이점은 우리가 _ 해내 고 _ 좋은 웹 개발자가 어떤 모습이어야하는지에 대한 예가 될 수 있다는 것입니다.

예를 들어 저는 세미콜론 언덕에서 죽을 것입니다.

그것은 정규식으로 몇 번의 스트로크에 불과합니다. 하지만 어떤 사람들에게 사용하든 안하든 정말 고통스러운 주제 인 것 같습니다 ...

우리는 dist에 eslintrc를 제공하지 않을 것입니다. 프로젝트 측면에서 진정한 이점은 우리가이를 수행하고 좋은 웹 개발자가 어떤 모습이어야하는지에 대한 예가 될 수 있다는 것입니다.

그러나 다른 프로젝트에 포함될 JS 코드는 나중에 린팅 될 것이며 사람들은 규칙에 맞게 수정하거나 HTML5Boilerplate 규칙을 사용해야합니다. 이것이 JS가 가능한 한 JS 커뮤니티 표준에 가까워 야하는 이유이며, 규칙과 코드 스타일에 필요한 몇 가지 변경을 피할 수 없다고 생각합니다. 그다지 문제가되지는 않습니다. Standard 및 ESLint와 --fix 는 도입 된 규칙 오류의 대부분을 자동으로 수정합니다.

진짜 문제는 JS 세계에서 커뮤니티 표준을 고려해야하는 것입니다.

좋은 점. 우리가 제공하는 소량의 JS조차도 다운 스트림 효과를 상기시키는 것이 좋습니다.

그리고 명확히하기 위해 저는 변화를 반대하지 않습니다. 내가하고 싶지 않은 것은 토론없이 전체적으로 변경하는 것입니다 (토론에 참여해 주셔서 감사합니다 👍) 지금 당장 6.0을 공개하는 것이 절실하지만 일반적으로 변경을 서두르지 않습니다 여기에 그들이 올바른 변화가 아니라면.

한 가지 옵션은 일반적인 문제를보고하지만 스타일 선호도를 실제로 부과하지는 않는 eslint:recommended 구성 을 적용하는 것입니다. 이 경우 ESLint는 오류와 버그를 방지하는 역할 만합니다. 실제로는 최소한의 상식적인 구성입니다.

이 경우에 추가 할 유일한 스타일 관련 규칙은 .editorconfig 규칙입니다 : 후행 공백 없음, 4 개의 공백 들여 쓰기 및 마지막 줄 바꿈.

4 칸 들여 쓰기

정보를 위해 더 이상 4 개의 공백을 사용하는 인기있는 코드 스타일이 없습니다.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint : recommend) 좋은 것 같지만 개인적으로 https://github.com/h5bp/html5-boilerplate/를 선호합니다.

농담 : https://github.com/christophwitzko/semicolon-indent#semicolon -indent

저도 Standard와 함께 있습니다. 왜냐하면 그들은 커뮤니티를 통한 검증을 통해 좋은 구성을 유지할뿐만 아니라 ESLint 위에 우수한 테스트 추가 기능을 제공하기 때문입니다.

그러나 공정하게 말하면 Prettier 도 언급해야합니다. 하지만 내 투표는 여전히 스탠다드를지지합니다.

논의의 앞부분에서 알림

예를 들어 저는 세미콜론 언덕에서 죽을 것입니다.

그것이 살아남은 게임이라고 상상해보십시오. 우리가 2005 년에 탭과 스페이스를 결정하는 것처럼 말입니다.

Btw, Prettier에 대해 언급 할 가치가 있습니다. 대부분의 Prettier가 유지하는 코드 스타일은 대부분 코드 스타일이고 ESLint 구성 (특히 Standard 구성)은 비스타 일의 좋은 또는 나쁜 사례도 많이 다루기 때문에 좋은 ESLint 구성과 함께 사용해야합니다.