wotan

Fimbullinter 프로젝트

플러그 가능한 타입 스크립트 및 JavaScript Linter

사용 가능한 패키지

WOTAN

잘 선택된 내장 규칙 세트가있는 메인 라이터 런타임. 자체 규칙, 프로세서, 포맷터, 공유 가능한 구성 및 플러그인 모듈로 사용자 정의 할 수 있습니다.

사용 가능한 규칙, 구성 및 사용에 대한 자세한 설명은 문서를 참조하십시오.

Vé

VUE 단일 파일 구성 요소 (SFC)의 공식 프로세서. Linting을 위해 *.vue 파일에서 스크립트 내용을 추출합니다.

Heimdall

호환성 계층은 wotan 런타임 내부에 tslint 규칙과 형식화를 사용할 수 있도록합니다.

Valtýr

Wotan이 거의 tslint처럼 행동하게 만드십시오. 변경없이 기존 tslint.json 재사용하십시오.

Bifröst

tslint 규칙 및 Formatters의 저자는 Wotan 내부에서 사용할 수있는 패키지를 제공 할 수 있습니다. Bifröst를 사용하는 규칙과 형태는 올바르게 작동하기 위해 Heimdall이 필요하지 않습니다.

이미르

사용자 정의 규칙 및 플러그인 저자를위한 핵심 유형을 제공합니다.

미 미르

모든 핵심 규칙, 포맷터 및 구성 사전 설정이 포함되어 있습니다.

미토 틴

TypeScript 용 LanguageService 플러그인. 입력하는 동안 실시간 내 세대 라인을 제공합니다.

추가 문서

• TypeScript의 API 이해
• 쓰기 규칙
• 테스트 규칙
• 로컬 규칙 사용
• 공유 구성 작성
• API 사용

레시피

• tslint 규칙으로 Vue 파일을 줄입니다
• tslint --type-check
• 사용하지 않은 변수를 감지합니다

이게 뭐야?

그 이름은 무엇입니까?

북유럽 신화 :

Fimbullinter는 Ragnarök의 사건에 앞서 끔찍한 겨울 인 Fimbulwinter에서 나왔습니다. 'Fimbul'은 'The Great', 'Linter'를 의미합니다. 'Linter'는 특정 코딩 패턴을 감지하고 경고하는 도구입니다.

Wotan 은 오딘의 많은 이름 중 하나입니다. 당신은 또한 Woden, Wodan, Wensley 등으로 그를 알고있을 것입니다. Woden은 희생적인 신, 피가 튼튼하고 잔인합니다. 그는 끊임없이 지혜를 위해 노력하고 있습니다. 그의 왕좌에서 그는 9 개의 세계에서 일어나는 모든 것을 볼 수 있습니다.

Vé 는 3 명의 귀찮은 Woden, Vili 및 Vé 중 막내로 거대한 Ymir를 졸고 그의 몸에서 9 개의 세계를 만들었습니다.

첫 번째 인간 부부에게 Ask and Embla에게 오딘은 영혼과 생명을 주었다. Vili는 재치 (지능)과 터치 감각을 주었다. 그리고 Vé는 얼굴 (외관, 얼굴 표정), 말, 청각 및 시력을 제공했습니다.

Burning Rainbow Bridge Bifröst가 하늘을 만나는 곳에 위치한 Heimdall (Heimdallr이라고도 함)은 Ragnarök의 발병을 계속 지켜보고 있습니다.

Bifröst 는 인간의 세계를 신의 영역과 연결하는 불타는 무지개 다리입니다.

"valr"(죽은 자, 전투에서 죽임)와 "Týr"(하나님)의 Valtýr 는 죽임의 신을 의미하며 종종 Odin을 언급하는 데 사용됩니다.

Ymir 는 전 세계의 몸이 창조 된 거인입니다. 그는 모든 요트 나르의 조상입니다.

Mímir ( "The Remember, The Wise One")은 그의 지식과 지혜로 유명했습니다. 오딘 신은 미 미르의 머리 주위를 들고 비밀 지식과 조언을 암송합니다.

Mithotyn (실제로 "운명의 디스펜서"를 의미하는 "Mitoðinn")은 아무것도없는 규칙을 소개합니다. 오딘의 외국으로 여행하는 동안 오딘의 장소를 채 웁니다.

왜 또 다른 라이터?

이것은 문제가있는 것으로 판명 된 다른 Linters의 디자인 결정을 피하려고합니다.

• 오는 패키지에 따라 규칙 이름을 접두사하여 이름 충돌을 피하십시오.
  • TSLINT는 모든 규칙을 글로벌 네임 스페이스에 넣고 사용 가능한 모든 규칙 디렉토리에서 검색합니다. 디렉토리의 순서는 중요하지만 핵심 규칙은 우선 순위가 우선합니다.
  • Eslint는 로컬 규칙 디렉토리를 CLI 플래그로 허용합니다. 해당 디렉토리의 규칙은 핵심 규칙을 무시할 수 있습니다.
• 구성 파일의 종속성은 해당 파일에 대해 해결됩니다.
  • Tslint는 이미 그렇게합니다.
  • Eslint는 그것을지지하지 않습니다.
• 공유 가능한 구성과 플러그인을 구분하지 않습니다. 실제로 둘 다 규칙 디렉토리, 설정, 규칙 및 프로세서를 선택적으로 제공 할 수있는 확장 가능한 구성입니다.
  • tslint를 사용하면 extends 과 rulesDirectory 중에서 선택할 수 있습니다. 패키지의 규칙 디렉토리는 구현 세부 사항이며 사용자 구성의 일부가되어서는 안됩니다.
  • Eslint는 구성 및 플러그인을 상당히 다릅니다. 실제로 그들은 플러그인을 선호하여 공유 가능한 구성을 더 이상 사용하려고 시도했습니다.
• 스타트 업 시간을 줄이기위한 규칙의 게으른로드.
  • Tslint는 이미 그렇게합니다.
  • Eslint는 플러그인이 이미로드 된 객체로 규칙을 제공 할 것으로 기대합니다. 큰 패키지의 몇 가지 규칙 만 사용하면 많은 오버 헤드가 발생합니다.
• 파일 시스템 액세스 및 구성의 캐싱. 캐시가 DI 서비스이므로 API 사용자는 필요할 때 캐시를 지울 수 있습니다.
• 처음부터 프로세서 지원. *.Vue 파일 및 더 많은 라인을 활성화합니다.
• 구성 규칙의 별칭. 규칙을 Eslint의 no-resticted-syntax 와 같은 규칙을 각 구성 옵션에 대해 별개의 이름 지정 규칙으로 취급하는 데 사용할 수 있습니다.
• 전체 API는 DI 컨테이너로 구동됩니다. 따라서 다른 서비스를 쉽게 주입 할 수 있습니다. CLI를 통해 플러그인을 사용하여 다른 서비스를 주입 할 수도 있습니다.
• CLI 기본값 및 플러그인 구성에 대한 "Global"구성 파일 ( .wotanrc.yaml 외에) : .fimbullinter.yaml . 이 파일은 편집기 플러그인에서도 사용할 수 있으므로 공통 구성을 복제 할 필요가 없습니다.
  • Eslint에는 그러한 파일이 없으며 향후 파일을 추가하지 않았습니다. CLI 기본값으로 구성된 구성 파일을 작성 해야하는 경우 standard 또는 xo 와 같은 도구는 존재하지 않아도됩니다.
  • tslint startet은 그것을 tslint.json 에 넣어 혼란스러워합니다.
• 사용하지 않고 중복성을보고하고 --report-useless-directives 을 사용하여 의견 (또는 그 부품)을 비활성화하십시오.
  • Eslint는 사용하지 않은 비활성화 의견 만보고합니다. 완전히 사용되지 않은 의견 만보고합니다. 중복 의견은보고되지 않고 존재하지 않는 규칙에 대한 의견을 가능하게합니다.
  • tslint는 그것을지지하지 않습니다.

tslint와의 차이점

• 플러그인 또는 공유 가능한 구성을 확장하려면 extends: plugin-name 사용하십시오. 이름은 구성 파일에 대한 Node의 모듈 분해능 알고리즘에 따라 해결됩니다.
• 프로젝트 내에서 유지되는 규칙을 사용하려면 rulesDirectory: {"my-prefix": "./path/to/rules"} my-prefix/rule-one: "error" 로 구성하십시오. 규칙 디렉토리는 구성 파일과 관련된 경로입니다.
• 재정의 : 하나 이상의 재정의를 지정하여 기본 보조 장치를 재정의 할 수 있습니다. 파일 이름이 재정의의 글로벌 패턴과 일치하면 해당 오버라이드가 제공하는 모든 설정이 적용됩니다. 오버라이드는 순서대로 처리되며 나중에 재정의 된 재정의 설정이 이전 재정의에서 재정의됩니다.
  • 패턴은 지정된 구성 파일과 관련하여 일치합니다.
  • 슬래시가없는 패턴은 각 파일의베이스 이름과 일치합니다.
  • 현재 디렉토리에 일치하는 것을 제한하려면 패턴을 ./ 로 접두사하십시오.
  • 부정 패턴을 사용하여 앞 패턴의 일치에서 빼기 위해 사용될 수 있습니다.
• linterOptions.exclude > exclude
  • 구성을 확장 할 때 제외는 재정의되지 않습니다.
  • 패턴 매칭은 재정의와 동일한 규칙을 따릅니다 (위 참조).
• 구성 파일에 대한 JSON5 지원.
• 규칙과 프로세서가 픽업 할 수있는 규칙 독립적 설정.
• 프로세서, 심지어 지원 --project 도 지원합니다.
• 별명, 위 참조
• 고정에 대한 안전한 안전한 접근 :
  • 구문 오류가있는 파일을 수정하지 않습니다.
  • 코드 파괴를 방지하기 위해 겹치는 교체를 제외합니다.
  • 다음 반복에서 충돌하는 변경 사항을 적용하기 위해 파일 당 구성 가능한 수의 반복 수를 실행합니다.
  • 수정이 구문 오류를 도입하는 경우 중지됩니다.
  • --project 로 수정한다고해서 전체 프로그램을 처음부터 생성하지 않으므로 빠르게 빠르게됩니다.
• 테스트
  • 테스트는 CLI를 통해 지정할 수있는 모든 것을 구성 할 수있는 JSON 파일로 구성됩니다.
  • 테스트 파일에는 오류 마크 업이 포함되어 있지 않습니다. 구문 오류를 피하고 유지하기가 더 쉬워집니다. 보풀 결과 및 고정 콘텐츠는 별도의 기준 파일에 저장됩니다.
  • 다른 설정으로 동일한 코드를 테스트 할 수 있습니다.
• TypeScript 프로젝트 참조를 지원합니다.
• .fimbullinter.yaml 에서 CLI 옵션의 기본값을로드합니다.
• 확인되지 않은 JavaScript 파일에서 유형 정보를 사용하지 않습니다 ( // @ts-nocheck 또는 "checkJs": false ).
• 사용하지 않고 중복 된 보고서는 --report-useless-directives 에 대한 의견을 활성화하고 비활성화합니다.

지원되는 환경

이 프로젝트는 적극적으로 지원되는 모든 버전의 node.js에서 실행됩니다.

이 프로젝트는 공식적으로 최신 3 가지 안정 버전의 TypeScript를 지원합니다. 글을 쓰는 시점에서 이것은 3.0-3.2입니다. TypeScript의 야간 빌드 ( typescript@next )와 함께 작동 하지만 보장은 없습니다.

맞춤 규칙은 최소한 ES6을 사용하여 기본 클래스를 지원해야합니다. 그렇지 않으면 패키지에서 내보낸 수업을 확장하려고 할 때 문제가 발생합니다.

시맨틱 버전화 (SEMVER 정책)

켈 다음 정책은 아직 1.x와 다음 릴리스에만 적용됩니다. 0.x 범위의 모든 릴리스는 실험적인 것으로 간주됩니다. 감가 상각없이 API 변경을 할 수 있고 파손될 수 있습니다.

이론적으로 규칙으로의 모든 변경은 사용자를 깨뜨릴 수 있으며 깨진 변화로 간주 될 수 있습니다. 모든 버그 수정에 대한 새로운 주요 버전을 공개하지 않기 위해 아래에 요약 된 지침이 약간 다릅니다.

Prereleases (야간 빌드)

• 안정적이라는 보장되지 않습니다
• @fimbul/wotan@next 설치할 수 있도록 NPM에서 next 으로 태그
• 다음 릴리스를위한 최신 변경 사항이 포함되어 있습니다
  • x.0.0-dev* 다음 주요 버전에 대한 중단을 포함하여 모든 변경 사항이 포함됩니다.
  • xy0-dev* 에는 다음 마이너 버전의 모든 변경 사항이 포함되어 있습니다
  • 패치 버전에는 프레 레아가 없습니다

패치 릴리스

• 충돌을 해결합니다
• 회귀를 수정합니다
• 사용자가 동작을 바꾸지 않는 내부 기능의 리팩토링

사소한 릴리스

• 새로운 규칙, 규칙 옵션, 형성자, 프로세서, API를 추가합니다
• 규칙은 새로운 결과로 이어질 수있는 새로운 수표를 추가 할 수 있습니다.
• wotan:latest 규칙과 옵션이 활성화됩니다
• 규칙은 메시지 찾기 메시지를 변경할 수 있습니다
• 인간의 복제를위한 형성 (예 : stylish )은 출력을 변경할 수 있습니다.
• 규칙, 규칙 옵션, 형성자, 프로세서 및 API를 사용하지 않을 수 있습니다.
• 구성 파일에 새로운 구성 옵션을 추가 할 수 있습니다

주요 릴리스

• API 변경 파괴가 포함됩니다
• 이전에 더 이상 사용되지 않은 규칙, 옵션, 형성자 등을 제거합니다.
• 기계 소비 (예 : json 또는 tap )를위한 형식 순위는 출력을 변경할 수 있습니다.
• wotan:recommended wotan:latest 의 내용으로 업데이트됩니다

릴리스 일정

현재 고정 릴리스 일정이 없습니다. 마스터에 변경 사항이 있으면 야간 빌드가 매일 밤 게시됩니다. 패치 릴리스는 버그가 식별되고 고정 되 자마자 게시됩니다. 마스터에 변경 사항이있는 경우 매주 또는 2 주마다 사소한 릴리스가 게시됩니다. 충분한 파괴 변경이 쌓이면 주요 릴리스가 게시됩니다.

특허

Apache-2.0 © Klaus Meinhardt