Tslint: 제안: 조건부 린트 구성

테스트와 프로덕션 코드를 별도의 디렉토리에 넣으면 그러한 기능이 필요하지 않습니다. 구성 파일을 CLI 인수로 제공하지 않으면 TSLint는 가장 가까운 tslint.json 합니다. 따라서 다른 폴더에 대해 다른 설정을 가질 수 있습니다. "extends" 를 사용하면 동일한 기본 구성을 사용하고 특정 규칙만 재정의할 수 있습니다.

많은 Angular 및 React 프로젝트가 해당 프로덕션 코드와 동일한 디렉토리에 테스트를 넣는 것으로 나타났습니다. 개인적으로 이것은 나쁜 습관이라고 생각합니다. 나는 많은 사람들이 (실수로) 프로덕션 코드의 테스트에서 기호를 가져오는 것을 보았습니다.

IMO 제안된 기능은 복잡성을 많이 추가합니다. 구현은 그리 어렵지 않을 수 있지만 구성 파일을 읽고 이해하기 어렵게 만듭니다.
우리가 이것을 구현하려면 두 번째 제안을 선호합니다.

또한 구성을 확장할 때 작동 방식에 대해서도 논의해야 합니다. 재정의는 어떤 순서로 적용됩니까?

사실, 코드를 분리할 수는 있지만 인체 공학에 해를 끼칩니다. 당신이 가지고 있거나

src/
  tslint.json
  a/
    b/
      c/
test/
  tslint.json (extends ../src)
  a/
    b/
      c/

c/foo.spec.ts 는 import {symbol} from '../../../a/b/c/foo';

그 경로는 파일이 종종 트리에서 매우 깊숙이 있는 모노레포에서 보기 흉해집니다.

또는 당신이 가지고

  a/
    src/
      tslint.json
    test/
      tslint.json (extends ../src)
    b/
      src/
        tslint.json
      test/
        tslint.json (extends ../src)
      c/
        src/
           tslint.json
        test/
          tslint.json (extends ../src)

너무 많은 tslint.json 파일입니다.

재정의 주제: 재정의가 동일한 순서로 적용된다고 말하고 싶습니다. 규칙이 적용됩니다. 그것이 무엇인지 모르고 문서를 찾을 수 없었지만 직관적으로 다음과 같을 것이라고 생각합니다.

// a.json
{"rules": {"foo": [true, 1]}}

// b.json
{"rules": {"foo": [true, 2]}}

// c.json
{
  "extends": ["a.json", "b.json"],
  "rules": {"foo": [true, 3]}
}

결과적으로 규칙 "foo"는 인수 3을 갖습니다. 해당 규칙이 c.json 에 없으면 "확장" 배열의 순서 때문에 "foo"는 값 2를 가져야 합니다.

재정의의 경우 동일한 순서가 적용될 것으로 예상합니다. '확장' 규칙이 고려되는 순서를 고려하여 제공된 정규식과 일치하는 마지막 재정의를 사용하는 것이 합리적입니다. 단일 파일 예:

{
  "rules": {"a": [true, 1]},
  "override": [
    {"match": "test|spec", "rules": {"a": [true, 2]}},
    {"match": "test", "rules": {"a": [true, 3]}}
  ]
}

파일 경로에 "spec"이 포함되어 있으면 규칙 "foo"에 대해 값 2, "test"가 포함되어 있으면 3, 그렇지 않으면 1이 됩니다. (분명히 "테스트"가 첫 번째 항목에서 생략될 수 있기 때문에 매우 유용한 재정의 세트는 아니지만 아이디어는 얻을 수 있습니다)

그것이 의미가 있고 귀하의 질문에 대답합니까?

@calebegg 고려해야 할 몇 가지 다른

// a.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": [true, 2]}}
}

// b.json
{
  "extends": "./a.json"
  "rules": {"foo": false}
}

예상되는 결과는 무엇입니까?

• 2 주문이 a.json/rules 2 이기 때문에 -> b.json/rules -> a.json/override
• false 주문이 a.json/rules false 이기 때문에 -> a.json/override -> b.json/rules

여기도 마찬가지입니다. 예상 결과는 무엇입니까?

// c.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": false}}
}

// d.json
{
  "extends": "./a.json"
  "rules": {"foo": {"options": 2}},
  "override": {"match": "test|spec", "rules": {"foo": {"options": 3}}}
}

그냥 무작위로 생각: 패턴을 순서대로 일치시키고 이전 일치를 (부분적으로) 재정의하지 않는 이유는 다음과 같습니다.

{
  "rules": { // same as "*"
    "rule-one": true,
    "rule-two": true
  },
  "*.js?(x)": { // we could get rid of "jsRules" with this
    "rule-two": false
  },
  "*.{t,j}sx": {
    "jsx-rule": true
  },
  "*.spec.*" {
    "rule-one": false
  }
}

몇 가지 예:

• foo.ts : 규칙 1, 규칙 2
• foo.tsx : 규칙 1, 규칙 2, jsx 규칙
• foo.js : 첫 번째 규칙
• foo.jsx : 규칙 1, jsx 규칙
• foo.spec.tsx : 두 번째 규칙, jsx 규칙
• foo.spec.js : 없음

이것을 config에 어디에 넣어야 하는지 모르겠습니다. "rules" 와 같은 수준으로 작성하면 쓰기는 쉬우나 "extends" , "rulesDirectory" , ...

또 다른 문제는 구성을 확장하는 것입니다. 기본 구성에서 모든 재정의를 적용한 다음 현재 구성에서 재정의를 적용하면 이해하기가 다소 어렵습니다.

또한 코드를 더 복잡하게 만듭니다. 현재 구성은 구문 분석 중에 병합됩니다. 이 제안으로 최종 구성은 파일 이름이 있을 때만 알 수 있습니다.

안녕하세요,

이 기능은 훌륭할 것입니다. Eslint가 https://eslint.org/docs/user-guide/configuring#configuration -based-on-glob-patterns 기능을 지원한다고 생각합니다. 따라서 혼동을 피하기 위해 구문과 의미가 동일할 수 있습니다.

@minomikula 감사합니다. 전에 ESLint 문서를 검색했지만 이 섹션을 찾지 못했습니다.

그들의 접근 방식은 합리적입니다. 요약:

• "overrides" 섹션에는 재정의 배열이 포함되어 있습니다.
• 재정의는 여러 glob 패턴( "files" )을 지정할 수 있습니다. 둘 중 하나가 일치하면 구성이 적용됩니다.
• glob 패턴으로 파일을 제외할 수 있습니다: "excludedFiles"
• glob 패턴은 지정된 구성 파일에 상대적입니다.
• glob 패턴은 항상 기본 이름뿐만 아니라 전체 경로와 일치해야 합니다.
• 재정의는 순서대로 처리되어 이전 재정의를 재정의합니다.
• 구성 파일을 확장할 때 확장 구성을 계속하기 전에 기본 구성이 완전히 평가됩니다.
  
  
  
  • base.json/규칙
  
  
  • base.json/overrides
  
  
  • 확장.json/규칙
  
  
  • 확장.json/overrides
  
  

이 동작을 TSLint로 이식할 때 고려해야 할 몇 가지 사항이 있습니다.

• 재정의에서 extends 및 linterOptions 를 확실히 비활성화해야 합니다.
• 또한 rulesDirectory 도 허용하지 않을 수 있습니다.
• 재정의에서 rules 및 jsRules 를 허용하시겠습니까? 아니면 **/*.js?(x) 재정의를 위해 jsRules 를 더 이상 사용하지 않습니까?

생각이나 의견 @adidahiya @calebegg @alexeagle @minomikula?

오, 와우, 예, 그 접근 방식이 나에게는 합리적으로 보입니다. 나는 또한 선행 기술을 찾았어야 했다.

이것은 멋진 추가 사항이 될 것입니다! eslint 접근 방식은 테스트 파일에서 일부 규칙을 조건부로 비활성화할 때 효과적입니다.

@calebegg 시간 이 나면 계속

네, 확실히 이 일을 하고 싶습니다. @ajafff 일반적으로 ESLint 접근 방식으로 시작하여 PR에서 반복하는 것에 만족하십니까? 아니면 우리가 먼저 이야기해야 할 디자인 질문이 있다고 생각하십니까?

재정의에서 규칙과 jsRules를 허용하고 싶습니까? 아니면 */ .js?(x) 재정의를 위해 jsRules를 더 이상 사용하지 않습니까?

비추천하는 것은 나에게 의미가 있지만 어느 쪽이든 그다지 강하게 느끼지 않습니다.

@calebegg 저는 ESLint 접근 방식이 좋습니다. 내 POC 린터 런타임 https://github.com/fimbullinter/wotan/tree/master/packages/wotan#overrides 에서 매우 유사한 개념을 구현했습니다.

현재 TSLint API와의 통합은 현재 구문 분석하는 동안 모든 구성을 병합하기 때문에 어려울 수 있습니다. 이것은 파일 이름이 알려지고 모든 파일에 대해 수행되어야 할 때까지 연기되어야 합니다.

이것은 확실히 API 변경 사항입니다.

@calebegg @mitchlloyd @ajafff @alexeagle 외부 구성을 재정의하기 위해 tslint.json 파일을 단순히 중첩하는 것보다 이 기능의 이점이 거의 없습니다. 그 기능은 오늘날 이미 작동하며 복잡한 API 중단이 필요하지 않습니다. 우리가 이 요청을 거부하면 기분이 상하겠습니까?

중첩은 여기서 논의된 문제를 해결하지 못합니다. 많은 사람들 이 테스트하는 코드와 동일한 디렉토리 구조에서 테스트를 수행하기를 원하며 현재로서는 tslint로 그렇게 할 수 있는 좋은 방법이 없습니다.

소스와 동일한 디렉토리에 사양 파일을 넣는 프로젝트가 많이 있습니다. 이것은 많은 환경에서 모범 사례가 되었으며 Angular CLI는 이와 같은 프로젝트 구조를 생성합니다. tslint 구성 파일을 중첩하는 것이 현실적이라고 생각하지 않습니다.

내 프로젝트 구조가 Linting 도구에 의해 결정되어서는 안 된다는 데 동의합니다. 대신 Linting 도구는 일반적인 기존 패턴을 지원해야 합니다. 테스트와 소스 파일을 함께 배치하는 것은 일반적인 패턴입니다.

@giladgray 요청된 변경 사항은 사용자가 다음과 같이 테스트 및 프로덕션 파일을 나란히 배치하는 시나리오를 지원합니다.

some-dir/
  my-component.ts
  my-component.test.ts

my-component.ts 및 my-component.test.ts 대해 다른 규칙을 원할 때 " tslint.json 파일 중첩"은 이 사용 사례를 어떻게 처리합니까?

@giladgray 각도 가이드라인은 테스트를 파일과 함께 배치할 것을 권장합니다. 따라서 Angular 프로젝트의 99%가 이 작업을 수행합니다. tslint가 뒤로 돌아가기 때문에 내가 작업한 모든 각도 프로젝트에 문제가 있었습니다. 귀하의 마지막 의견은 혼란스럽고 근시안적입니다. 이 믿을 수 없을 정도로 유용한 제안을 받아들일 수 없거나 받아들이고 싶지 않다면 그렇게 중요한 프로젝트에서 우리를 대신해 결정을 내리기에는 당신이 너무 보수적이라고 생각합니다. 이 문제로 인해 Angular 프로젝트 작업이 수년 동안 어려워졌습니다.

@ohjames 주제를 유지하고 인신공격으로 방향을

위에서 언급한 중첩 구조에 맞지 않는 파일에 대한 재정의를 원하는 것이 합리적입니다. 6개월 이상 이 문제에 대한 활동이 없었다는 점을 감안할 때 @giladgray 의 의견은 이 변경에 여전히 상당한 커뮤니티 관심이 있는지 확인하기 위한 것 같습니다. 이것은 공개 PR(#3708)에 대한 그의 논평에 의해 구체적으로 입증됩니다.

이 작업을 수행하려면 이 분기를 업데이트하여 검토할 수 있도록 하거나 더 이상 관련이 없으면 닫으십시오. 2주 이내에 연락이 없으면 이 작업을 종료합니다.

@ohjames 나는 당신이 당신의 의견을 재고할 것을 제안합니다 - @DanielSchaffer가 언급했듯이, 인신공격은

이 주제에 대한 업데이트가 있습니까?
@ajafff 가 요약 논평 에서 제안한 아이디어는 합리적으로 보이며 모든 다양한 요구를 충족시킵니다. eslint와 동일한 의미 체계를 사용하는 것이 좋은 방법입니다.

관련된 #1063에 대해 언급했듯이 내 사용 사례는 현재 tslint-microsoft-contrib를 사용하여 일부 규칙에 대해 Vue 단일 파일 구성 요소에 폭탄을 설치하는 것입니다. 이것은 Vue 문제이거나 TSLint 문제일 수 있으며 해당 팀은 특정 문제를 해결하기 위해 주변을 둘러볼 수도 있고 그렇지 않을 수도 있습니다. 문제가 발생할 때까지 문제가 되는 규칙을 비활성화하면 너무 번거롭지 않은 간단한 해결 방법처럼 보입니다. 모든 단일 .vue 파일에 동일한 비활성화 지시문을 추가하고 규칙 지원이 변경됨에 따라 모든 위치에서 업데이트해야 하는 것과 비교됩니다. 또한 프로젝트를 .vue 및 .ts 파일로 분할하는 것도 이치에 맞지 않습니다. 매우 어색한 구조가 될 것입니다.

나는 이 기능이 들어오는 것에 찬성합니다. 일부 재정의가 모든 규칙을 완전히 비활성화하도록 허용하여 #73의 tslintignore 요청을 깔끔하게 해결할 수도 있습니까?

{
    "files": "./src/test-data/*.ts",
    "reset": true // Resets tslint.json to {}
}

tslint-microsoft-contrib은 현재 일부 규칙에 대해 Vue 단일 파일 구성 요소에 대해 폭탄을 제공합니다.

오 😕 @millimoose tslint-microsoft-contrib에 문제 를

@JoshuaKGoldberg - 가장 적절해 보이는 @vuejs/vue-cli에서 해당 버그에 대한 자세한 보고서를 이미 작성했습니다. ("복제 대기 중"으로 표시되어 있으므로 크게 잘못된 것은 아니라고 생각합니다.) 여기에서 차임에 대한 동기로 언급했습니다. 이것은 진화하는 생태계에서 자랄 수 있고 또 생길 것입니다. 이는 도구가 다른 사람의 버그에 대한 해킹을 실제로 작성하지 않고도 장애물을 해결할 수 있을 만큼 충분히 유연하다는 주장이 되어야 합니다.

이 문제에 대한 업데이트가 있습니까?

이 문제는 현재 '제안 필요'로 표시되어 있지만 https://github.com/palantir/tslint/issues/3447#issuecomment -344020834에 이미 제안이 있는 것 같습니다.

@RoystonS @ajafff 의 제안은 해결해야 할 몇 가지 느슨한 끝을 언급했습니다.

이 동작을 TSLint로 이식할 때 고려해야 할 몇 가지 사항이 있습니다.

• 재정의에서 extends 및 linterOptions 를 확실히 비활성화해야 합니다.
• 또한 rulesDirectory 도 허용하지 않을 수 있습니다.
• 재정의에서 rules 및 jsRules 를 허용하시겠습니까? 아니면 **/*.js?(x) 재정의를 위해 jsRules 를 더 이상 사용하지 않습니까?

또한 진행하기 전에 이에 대해 palantirtech 조직의 사람들로부터 합의가 있어야 합니다. 이는 상당히 중요한 기능이기 때문입니다.

나는 이것을 우연히 발견했고 이런 종류의 기능에 대한 관심을 표명하고 싶습니다.

우리는 결국 프로덕션 코드에 영향을 미치는 몇 가지 린트 규칙을 완화했고 어떻게 진행되는지 봅시다. ):

이 기능을 보고 싶습니다.

구독 - 이것도 필요합니다.

나는 이것이 너무 필요합니다 :(

여기도 마찬가지! 우리는 Vuejs와 함께 typescript를 사용하고 있으며 단위 테스트 파일은 테스트 디렉토리에 함께 있지 않고 구성 요소 소스 코드를 따라 모든 곳에 있습니다.

이 기능을 보고 싶습니다. 현재 이 문제를 해결하기 위해 명령줄 린트가 강조 표시하는 것과 다른 린트 오류를 ​​vscode가 강조 표시하는 약간 이상한 설정을 사용하고 있습니다.

이 기능이 구현될 지는 매우 의심스럽습니다. tslint는 일반적으로 적극적으로 유지 관리되지 않는 것 같습니다. @typescript-eslint 전환하는 것이 좋습니다. eslint 및 ts 프로젝트 모두에서 완전한 지원을 받았고 @typescript-eslint/eslint-plugin-tslint 를 사용 하면 마이그레이션이 그 어느 때보다 쉽습니다. 그리고 사용 가능한 tslint 및 해당 eslint 규칙/기타 대안이 있는 compat 테이블 이 있습니다. Eslint 설정은 사용자 정의가 가능하므로 tslint를 고수할 이유가 없습니다.

.gitIgnore...에 있는 파일에 대해 git 저장소가 사용하는 개념을 tsLint 규칙에 적용할 것을 제안합니다. 특정 하위 디렉터리를 린트할 때 재정의 파일과 함께 린터에 대한 컨텍스트로 현재 계층적 위치를 사용합니다. 그런 다음 원하는 디렉토리 수준에서 구성을 포함하거나 제외하고 설정할 수 있습니다.

예
tslint 구성은 루트에 배치되고 소스 코드 구조의 특정 수준에서 다른 동작을 원할 경우 해당 하위 디렉토리의 루트에 있는 확장 tslint 파일로 이를 재정의하기만 하면 됩니다.

@redevill test 폴더에 테스트를 작성하는 데 도움이 됩니다. 그러나 구성 요소/서비스의 동일한 폴더에 something.test.ts 로 쓰기 테스트가 없습니다.

동의함 - 그러나 약간의 변경: (템플릿 생성기로 자동화할 수 있음(CLI 스타일)
MyComponentDir
---MyComponentTestsDir
------tslint.test.json
------something.test.ts
---mycomponent.component.css
---mycomponent.component.html
---mycomponent.component.ts

그 아이디어는 여전히 유효할 수 있습니다.

이 제안의 열렬한 팬입니다. 예, 부탁합니다! 내가 선호하는 것은 Overrides 개념입니다.

Btw, tslint의 사용 중단 발표를 감안할 때 이 단계에서 그렇게 큰 변경이 이루어질 것이라고 _정말__ 상상할 수 없습니다. 우리 팀은 이미 규칙별 + 파일별 재정의 기능이 있는 eslint로 이동하고 있습니다.

앞서 언급한 발표: https://medium.com/palantir/tslint-in-2019-1a144c2317a9

@RoystonS 는 기본적으로 옳습니다. 이러한 큰 기능은 이 시점에서 tslint에 추가되지 않습니다. #4534 참조

우리는 Angular 프로젝트를 사용합니다. 재정의 개념이 필요합니다. 그렇지 않으면 관리하는 것이 고통스럽습니다.