@adidahiya @nchen63의 이 댓글 을 참조하세요.

@nchen63에서 :

탭 -> x 공백 및 x 공백 -> 탭을 수정하지만 x 공백 -> y 공백은 수정하지 않습니다.

그래도 x spaces 에서 y spaces 해야 합니다.

내 프로젝트는 2와 4 공간을 모두 사용합니다. x spaces 규칙을 y spaces 하면 매우 유용합니다.

또한 크기 위반을 수정하거나 수정할 수 있도록 최소한 오류로 보고할 것으로 기대하는 이 문제에 부딪쳤습니다. 현재 사이트(https://palantir.github.io/tslint/rules/indent/)에 문서화된 들여쓰기 크기에 대한 구성은 실제로 아무 것도 하지 않는 것 같습니다.

예, 이 버그를 수정하십시오. Angular CLI는 파일이나 프로젝트를 생성할 때 들여쓰기 수준으로 2개의 공백을 사용하며 모든 따옴표는 작은 따옴표입니다. 그런 다음 tslint를 실행하여 사용자의 tslint.json에 따라 이러한 문제를 수정합니다. 따옴표는 잘 작동하지만(내 기본 설정에 따라 큰 따옴표로 변환) 들여쓰기는 2칸으로 유지됩니다(저는 4칸을 선호함). Tslint는 실제 TAB 문자가 표시되는 경우에만 오류를 보고하지만 공백 수도 확인해야 하는 것이 합리적으로 보입니다.

https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts 에서 사용되는 구현이 상당히 순진한 것 같으며 x spaces -> y spaces 에서 작동할 것으로 기대하지 않습니다.

예를 들어 들여쓰기 너비가 2칸으로 선택되었다고 가정하고 다음 코드를 고려하세요.

foo = {
    a: {
  b: {
    c: 'c'
  }
    },
    d: 'd'
}

우리의 현재 구현이 이것이 전혀 실패한다는 것을 어떻게 알 수 있습니까? 각 공백 시퀀스는 정규식 / / 전달합니다. 우리가 2칸의 배수를 찾아도 이것은 통과할 것입니다. 마찬가지로, 다중 수준 들여쓰기 시나리오에서 4개의 선행 공백은 통과 시나리오가 될 수 있지만 4개의 ​​공백으로 단일 수준의 들여쓰기를 시작하는 것은 실패해야 합니다.

모든 솔루션은 eslint가 수행하는 것과 유사하게 AST를 통과해야 한다고 생각합니다(https://github.com/eslint/eslint/blob/master/lib/rules/indent.js). 그 단점은 tabs -> spaces 또는 spaces -> tabs 대해 약간의 성능 저하가 있다는 것입니다. 설정을 기반으로 구현을 선택하여 이 문제를 해결할 수 있지만 탭과 공백의 조합이 사용되는 경우 현재 구현이 실패할 것으로 예상합니다. 이 경우 AST 기반 솔루션만 사용해야 합니다.

eslint 구현에서 수행된 AST 작업 중 적어도 일부는 typescript의 라이브러리에서 직접 처리할 수 있으므로 솔루션을 작성하는 데 너무 어렵지 않아야 한다고 생각합니다.

우리의 현재 구현이 이것이 전혀 실패한다는 것을 어떻게 알 수 있습니까?

_기술적으로_ 그럴 필요가 없습니다. align 규칙은 그러한 코드를 작성하는 것을 방지합니다. 물론 indent 규칙에서도 AST를 실행할 수 있습니다. 내가 신경 쓰는 것은 indent 와 align 일부 조합으로 문제 설명에 작성한 내용을 달성할 수 있다는 것입니다.

정렬 규칙은 그러한 코드를 작성하는 것을 방지합니다.

멋진! 나는 소스 코드를 검사할 때 그것을 놓쳤다. 나도 거기에 정점을 찍을거야. TBH, 나는 다른 사람들을 가능한 한 순진하게 유지하기 위해 기존 규칙을 활용하는 아이디어를 좋아합니다.

같은 문제가 발생했습니다. 아래 규칙은 공백 대신 사용 중인 탭을 포착하지만 잘못된 수의 공백은 포착하지 않습니다. 2를 다른 숫자로 변경할 수 있지만 여전히 오류가 발생하지 않습니다. tslint 5.5.0을 사용하고 있습니다.

"indent": [true, "spaces", 2],

이에 대한 업데이트가 있습니까? (누군가가 이미 수정 작업을 하고 있지 않다면 시도해 볼 의향이 있습니다. )

@mDibyo 가세요

@mDibyo 이것에 진전이 있었습니까?

부분적으로 구현했습니다. 완성하고 주말에 PR 올리도록 노력하겠습니다

내 프로젝트에 tslint-plugin-prettier 와 함께 더 예쁜 형식을 사용하기 시작한 이후로 이 문제가 저에게 더 낮은 우선순위가 되었다는 점을 미리 알려드리고 싶었습니다. 향후 기본 제공 구성에서 더 예쁜 것에 대한 더 많은 공식 지원을 추가하고 이에 따라 형식과 관련되지 않은 핵심 규칙에 초점을 조정할 수 있습니다.

반면에 Prettier는 모든 라인에 가장 많은 코드를 맞추려고 노력합니다.

당신이 그것을 원하지 않는다면?

인쇄 너비를 120으로 설정하면 예쁜 것이 지나치게 조밀하거나 바람직하지 않은 코드를 생성할 수 있습니다.

우리는 프로젝트에서 120자를 사용합니다.

또한 또 다른 종속성입니다. 나는 일반 TSLint 규칙을 사용하는 것을 선호한다고 생각합니다.

나는 일반 TSLint 규칙을 사용하는 것을 선호한다고 생각합니다.

@glen-84 네, 괜찮습니다. 그래서 TSLint에서 모든 서식 규칙을 제거하고 외부 포맷터에 완전히 위임해야 한다고 말하는 것이 아닙니다. Prettier는 분명히 독단적이며 모든 사람이 그것을 사용하기로 선택하지는 않습니다. 이 문제는 여전히 PR을 위해 열려 있습니다.

이 문제에 무슨 일이?

내 홍보가 진행 중이며 많은 경우에 여전히 시간이 필요합니다. @cyberhck

그래서 우리는 그것이 곧 병합될 것으로 예상합니다 :slightly_smiling_face:

업데이트가 있습니까?

아마도 우리는 typescript-formatter 유지 관리자에게 몇 가지 API를 노출하도록 요청할 수 있습니까? 패키지는 tslint.json 파일의 설정에 따라 전체 소스 파일의 형식이 이미 지정되었는지 확인할 수 있습니다.

그러나 TSLint의 수정 프로그램 설정을 잘 사용하려면 도움이 필요할 수 있습니다.

문제는 들여쓰기 크기가 꺼져 있는 경우가 아니라 잘못된 공백 문자를 사용하는 경우에만 실패가 보고된다는 것입니다.

@adidahiya 잘못된 들여쓰기 문자를 사용하면 오류를 보고할 수 없습니다. 규칙을 space/4로 설정하고 다음과 같은 경우:

export function foo() {
return 123;
}

또는

export function foo() {
<tab>return 123;
}

오류를 다시 보고하지 않습니다. 귀하의 원래 의견에 따르면 잘못된 공백 문자인 경우 보고하시겠습니까?

이에 대한 진전이 있습니까? 그냥 물어봐 😝

조언? 더 예쁘게 사용하세요.

누구든지 tslint-eslint-rules를 사용해

@jscharett tslint-eslint-rules는 ter-indent 규칙과 함께 작동합니다. 불행히도 JSX 들여 쓰기는 다루지 않습니다 ...

여기에 수정의 희망이 있습니까?

이 버그는 v5.10.0에서 아직 수정되지 않았습니다.

나는 TSLint가 Prettier뿐만 아니라 JS 코드의 형식을 지정할 수 있을 것이라고 상상하지 않습니다. 이것은 복잡한 문제인데 프리티어가 누구보다 잘 풀었습니다. 특히 프로젝트에서 두 도구를 동시에 사용하는 경우가 많고 충돌이 발생할 가능성이 높기 때문에 이를 위해 TSLint에 의존해서는 안 된다고 생각합니다...

편집: 이 문제가 _어떻게_ 복잡한지에 대한 더 나은 아이디어를 얻으려면 이 PR을 검토하거나 Prettier 소스 코드를 살펴보십시오. 이 데모가 "복잡한" 것으로 느껴지지 않는다면 PR 😄으로 이 프로젝트를 도와주세요!

@aervin 나는 여기에 동의하지 않는 경향이 있습니다. 제 생각에 2개의 프로젝트는 다른 목적을 가지고 있습니다. Prettier는 형식화 범주에 속하는 반면 TSLint는 유효성 검사에 더 가깝습니다. 예, TSLint는 일부 규칙에 대한 형식 지정을 수행할 수 있지만 린터로서의 의도된 목적은 유효성 검사로 돌아갑니다.

Prettier에 의존하는 것의 문제점은 그것이 독단적이라는 것입니다. 그 스타일에 동의한다는 것은 대단한 일이지만, 그렇지 않다면 어떻게 하시겠습니까? 우리는 모두 JSLint를 사용했는데 너무 독단적이어서 모두 불평했습니다. 그런 다음 JSHint와 JSCS가 등장하여 우리에게 약간의 제어 권한을 주었습니다. 이제 우리는 플러그 앤 플레이 기능을 제공하고 문제를 자동으로 "수정"할 수 있는 @eslint 와 같은 강력한 도구를 갖게 되었습니다.

나는 Prettier가 훌륭한 프로젝트라고 확신하지만, 개인적으로 그것을 한 발짝 뒤로 물러난 것으로 봅니다. 그것은 나에게서 통제권을 빼앗고 있습니다. TSLint는 코드를 "수정"할 필요가 없습니다. 문제인 경우 문제로 플래그를 지정하기만 하면 됩니다. 나는 이 문제가 복잡하다는 것을 의심하지 않지만 eslint는 그것을 해결했습니다. 작동하는 데 사용되는 규칙; 그것을 깨기 위해 무엇이 바뀌 었습니까?

@jscharett 친절한 답변에 감사드립니다. 나는 이러한 프로젝트가 다른 목적을 가지고 있거나 _해야 합니다_ 동의합니다. 내 주장은 이러한 프로젝트를 그러한 목적으로 제한해야 한다는 것입니다. 들여쓰기 문제를 해결하는 데 Prettier를 맡기고 단순화할 수 있는 화살표 기능에 대해 개발자에게 경고하는 TSLint를 남겨 두자.

저도 Prettier가 독단적이라는 데 동의합니다. 나는 오히려 Prettier에 대해 그것을 좋아합니다. 이제 우리 팀은 누구의 형식화 의견이 더 합리적인지 논의할 필요가 없습니다. 우리는 모두 Prettier :laughing: 에 대해 불평할 수 있습니다.

편집하다:

작동하는 데 사용되는 규칙; 그것을 깨기 위해 무엇이 바뀌 었습니까?

첫 번째 문제 주석은 이 규칙이 의도한 대로 작동한 적이 없다고 믿게 합니다.

나는 Prettier가 훌륭한 프로젝트라고 확신하지만, 개인적으로 그것을 한 발짝 뒤로 물러난 것으로 봅니다. 그것은 나에게서 통제권을 빼앗고 있습니다.

내 경험상 저는 Prettier를 추가하기 전까지 서식 규칙을 세밀하게 제어하는 ​​데 관심이 있다고 생각했습니다... 그리고 얼마 지나지 않아 서식이 지정되는 특정 방식에 대해 그다지 신경 쓰지 않는다는 사실을 깨달았습니다. 그들은 일관되게 포맷되었습니다. 더 이상 그것에 대해 걱정하지 않고 코드가 어떻게 보이는지 _do_ 하기를 원하는 것보다 전적으로 내가 원하는 것에 집중하는 것은 엄청난 인지 부하입니다.

tslint는 이미 서식 범주에 속하는 다른 항목의 유효성을 검사합니다. 예를 들어, 변수 이름과 연산자 사이에 정렬, 대괄호 스타일 또는 공백을 적용합니다. 또한 prettier와 같은 독단적인 솔루션에 의존하지 않고 들여쓰기를 확인할 수 있는 것이 바람직합니다.

더 적은 토론과 더 많은 홍보가 필요합니다. 😉 😉

가세요 @ffxsam

내 의견은 대부분 혀로 뺨을 맞았습니다. 왜이 문제가 1 년이 넘었고 진전이 없었는지 궁금합니다. 모두가 Linting 대 Prettier에 대해 논쟁하는 것 같습니다.

@ffxsam tslint가 ts 부분에 관한 것인지 아니면 lint 부분에 관한 것인지에 대한 논쟁이 있기 때문에

유효한 지적입니다. TSLint/ESLint와 겹치는 부분이 있는 것 같습니다. 하지만 작동하지 않는 indent 옵션이 있다는 사실은 누가 알 수 있도록 망가진 것입니다. TSLint 코드베이스에 익숙한 사람이 수정하는 것이 가장 빠르고 쉬운 것 같습니다...?

x spaces => y spaces 수정에 투표하세요. 이것은 우리 회사가 매우 많이 의존하는 기능입니다. 이것을 고치지 않는 것은 의미가 없습니다.

@ffxsam 이 문제를 거의 1년 동안 지켜보고 있습니다. 네 오랜만입니다. 하지만

빈 프로젝트에서 여전히 재현 가능
https://github.com/dimaShin/tslint-reproduce-2814

@dimaShin님 , 시간을 내어 재현 가능한 리포지토리를 만들어 주셔서 감사합니다. 그러나 팀은 이미 이 문제를 알고 있으며 재생산은 문제가 되지 않았습니다.

우리는 단지 수정 옵션이 있는 이 기능을 기다리고 있지만 그것은 나에게 문제가 되지 않습니다. 지난번에 사람들이 들여쓰기를 확인하고 다른 모든 항목에 대해 tslint를 확인하기 위해 prettier를 사용하고 있는지 확인했습니다.

그것이 당신에게 적합하다고 말하는 것이 아닙니다. 저에게는 확실히 그렇지 않습니다. 또한 이 특정 옵션에 대해 .editorconfig 를 사용하고 이것이 해결되면 나중에 tslint로 전환하는 것이 좋습니다.

시간을 내어 정보를 추가해주셔서 다시 한 번 감사드립니다. :)

들여쓰기를 확인하기 위한 전략을 결정합시다. 참고로 eslint에서 사용하는 전략은 다음과 같습니다.

1. OffsetStorage 인스턴스는 원하는 오프셋의 맵을 저장합니다. 여기서 각 토큰에는 다른 지정된 토큰이나 첫 번째 열까지 지정된 오프셋이 있습니다.
2. AST를 통과할 때 그에 따라 원하는 토큰 오프셋을 수정합니다. 예를 들어, BlockStatement를 입력할 때 BlockStatement의 여는 중괄호에서 1 들여쓰기 수준만큼 BlockStatement의 모든 토큰을 오프셋합니다.
3. AST를 통과한 후 OffsetStorage 컨테이너에 따라 모든 토큰의 예상 들여쓰기 수준을 계산합니다.
4. 각 줄에 대해 첫 번째 토큰의 예상 들여쓰기를 파일의 실제 들여쓰기와 비교하고 두 값이 같지 않으면 토큰을 보고합니다.

이 전략은 이전 주석을 기반으로 하는 구문을 기반으로 하며 특정 방식으로 줄을 끊어야 하기 때문에 너무 독단적입니다. 코드가 줄로 구분되는 방식과 독립적인 들여쓰기를 확인하는 간단한 방법을 제안합니다.

1. 들여쓰기 단위는 설정에서 정의됩니다. 탭의 경우 하나의 탭 문자입니다. 공백의 경우 2개 또는 4개의 공백 문자입니다.
2. 파일의 비어 있지 않은 첫 번째 줄에는 들여쓰기 단위가 0이어야 합니다.
3. 비어 있지 않은 모든 후속 줄에는 다음 중 하나가 있어야 합니다.
   NS. 비어 있지 않은 선행 줄과 같은 들여쓰기 단위 수 또는
   NS. 비어 있지 않은 선행 줄의 들여쓰기 단위 수보다 작거나
   씨. 비어 있지 않은 선행 줄과 들여쓰기 단위 수보다 정확히 하나

논의할 몇 가지 추가 사항:

• 크기 매개변수는 탭에 영향을 주지 않습니다(왜?)
• 크기 매개변수가 양의 정수일 수 없는 이유는 없습니다.
• 들여쓰기 크기 자동 수정은 구문 전략 경로 없이는 구현할 수 없습니다.

@stifflerus 또한 규칙은 {} 블록이 없는 if/for/arrow 함수와 함께 작동해야 합니다.

@maximelkin 두 번째 줄에 당신이 준 예가 들여 쓰기되지 않았습니까? 제안된 전략이 실패할 경우의 예를 제시할 수 있습니까?

if(this) that(); //okay because it's all one line

if(this)
  that(); //also okay because the second line is indented

let x = () => f(); //okay because it's all one line

let y = () =>
  f(); // I have not seen any code but like this but it would be okay

이것이 수정되면 굉장할 것입니다.

들여쓰기 규칙을 적용하는 것만큼 근본적인 것이 여전히 작동하지 않는다는 것을 믿을 수 없습니다.

그렇다면 2018년에는 그러한 ts-code를 린트할 방법이 없을까요?

const x = {
  a: 1,
   b: 2,
}

나를 위해 일한다
./.eslintrc.ts.js :

module.exports = {
  'parser': 'typescript-eslint-parser',
  'parserOptions': {
    'ecmaVersion': 6,
    'sourceType': 'module',
    'ecmaFeatures': {
      'jsx': true,
    }
  },
  'plugins': [
    'react',
  ],
  'rules': {
    'indent': ['error', 2],
  },
}

yarn eslint --no-eslintrc --config ./.eslintrc.ts.js --ext .tsx src

https://github.com/eslint/typescript-eslint-parser

각도의 들여 쓰기 문제에 대해 찾은 솔루션은 다음 단계에서 더 예쁘게 추가하는 것입니다.
npm install --save-dev tslint-plugin-prettier 더 예쁜 tslint-jasmine-rules
tslint.json 편집 -->
` "규칙 디렉토리": [
"node_modules/codelyzer",
"node_modules/tslint-plugin-prettier",
"node_modules/tslint-jasmine-rules/dist"

],
"확장": "tslint-plugin-prettier",

"규칙": {
"더 예쁘다": 사실,
// 여기에 원하는 규칙 추가`

그리고 package.json에 --> 추가
" ,"더 예쁘다": {
"singleQuote": 사실,
"인쇄 너비": 140,
"세미": 사실,
"bracketSpacing": 참,
"arrowParens": "항상",
"파서": "타입스크립트"
}"

이것은 거의 모든 사람들이 매일 사용하는 기능입니다. 이 문제에 더 많은 관심을 가져주시면 감사하겠습니다.

여러분, tslint-eslint-rules에서 제공하는 ter-indent 옵션을 사용할 수 있습니다.

"ter-indent": [ true, 4, { "SwitchCase": 1 }]

그것은 나를 위해 일했습니다. 건배!

@hiteshaleriya 그것은 내가 잠시 동안 내 프로젝트에서 가지고 있던 것이지만 실제로 오류를 수정하는 것이 아니라 그냥 침묵시키는 것입니다... 여기 내 tslint.json .

{
    "extends": "tslint-config-airbnb",
    "rules": {
        "ter-indent": ["error", "spaces", 4],
        "no-unused-vars": ["warn"],
        "no-multi-spaces": false,
        "no-console": false,
        "max-line-length": false,
        "import-name": false
    }
}

다음은 경고나 오류 없이 완료된 관련 예입니다.

function retrieveAndSetConfig(): Promise<any> {
  return new Promise((resolve, _) => {
  // ^ 2 spaces, expected 4
    const ghe = new GHEUtils();
    // ^ 4 spaces, expected 8
    // ...
}

또한 탭을 사용할 때 오류가 표시되지 않습니다(4개의 공백이 있는 경우 의도적으로 설계된 것일 수 있음).

@SpencerKaiser 아래와 같이 ter-indent 규칙을 업데이트한 후 시도해 주

"ter-indent": [true, 4]

나는 당신의 예를 시도했고 내 끝에서 예상대로 작동합니다(오류 발생).

@hiteshaleriya 너무 빨리 돌아와 주셔서 감사합니다! 따라서 이제 예상대로 오류가 발생하지만(👍) --fix 로 오류를 수정하지 않습니다. 어떤 아이디어?

@SpencerKaiser --fix 명령을 두 번 실행해 볼 수 있습니까? 처음에는 첫 번째 줄만 들여쓰고 두 번째에는 나머지를 들여씁니다(예제 코드의 경우). 이상해 보이지만 작동하지 않으면 문제를 신고하십시오.

@hiteshaleriya 그래서 몇 가지 관찰 ... 다시 실행할 필요가 없었습니다. 대략 n/4 번 실행해야했습니다. 여기서 n 는 공백의 들여 쓰기 길이입니다. 프로젝트에서 가장 멀리 들여쓰기된 줄 ¯\_(ツ)_/¯

마침내 모두 마친 후에는 다음과 같은 기본 들여쓰기 오류를 건너뛰는 것 같습니다.

class Something {
    function myFunc() {
        const myThing = {
            wat: 1,
         wattt: 5,    // 9 spaces, expected 12
        };
    }
}

의 들여 쓰기 수준까지 I 엉망 경우 const (라인 17) 0 공간, 그것의 나머지는 오류 플래그가 나는 떨어져 나갈 때의 공간으로 라인을 _excluding_ --fix :

ERROR: 17:1  ter-indent  Expected indentation of 8 spaces but found 0.
ERROR: 18:1  ter-indent  Expected indentation of 4 spaces but found 12.
ERROR: 20:1  ter-indent  Expected indentation of 0 spaces but found 8.

--fix 의 첫 번째 패스는 다음과 같습니다.

        const myThing = {
    wat: 1,
         wattt: 5,
};

그리고 두 번째 패스:

        const myThing = {
            wat: 1,
         wattt: 5,
        };

생각??

tslint-config-prettier로 그 문제를 해결한 방법

@shubich 나도 결국 똑같은 짓을 했어...

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

@MaKCbIMKo 내가 이해하는 한, 전체 팀은 eslint 방문 typescript-eslint를 통합하기 위해 이동할 것이며 가까운 장래에 tslint는 더 이상 사용되지 않을 것이므로 지금은 이 규칙을 무시하는 것이 좋습니다(또는 tslint-config-prettier 사용 )

이 작업의 복잡성과 프로젝트 방향 변경으로 인한 마감: #4534

typescript-eslint의 ESLint 규칙은 저에게 완벽하게 작동합니다(#4534 참조):

module.exports = {
    "env": {
        "browser": true,
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2019,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        },
        "project": "./tsconfig.json",
    },
    "plugins": ["@typescript-eslint"],
    "rules": {
        "@typescript-eslint/indent": ["error", 2] // or ["error", "tab"]
    }
}

tslint-config-prettier로 그 문제를 해결한 방법

링크를 찾을 수 없습니다.

🤖 삐삐! 👉 TSLint는 더 이상 사용되지 않으며 👈 typescript-eslint로 전환 해야

🔒 이 이슈는 더 이상의 불필요한 토론을 방지하기 위해 잠그고 있습니다. 감사합니다! 👋

PS tslint-config-prettier - TypeScript를 _format_하기 위해 TSLint와 같은 _linters_ 사용을 중단하십시오. Prettier 와 같은 _formatter_가 더 잘 수행합니다.