Typescript: tsc는 rootDir 외부의 ts 파일에 신경 쓰지 않고 실패해야 합니다.

우회하기 위해 tsconfig.json 에 "제외"를 다시 추가합니다.

rootDir은 출력 폴더 구조를 빌드하는 데 사용됩니다. 컴파일러가 출력을 쓸 위치를 알기 위해서는 모든 파일이 rootDir 아래에 있어야 합니다. 이 제약 조건 없이 rootDir 아래에 있지 않은 파일이 있는 경우 컴파일러는 1. 완전히 예상치 못한 위치에서 내보내거나 2. 전혀 내보내지 않는 두 가지 옵션이 있습니다. 나는 오류 메시지가 자동 실패보다 훨씬 낫다고 말하고 싶습니다.

@mhegazy 설명 감사합니다. rootDir 라는 이름으로 브라우저의 baseURL 처럼 소스 코드의 루트 디렉토리로 사용했습니다. 출력 폴더 구조 전용인지 몰랐습니다.

내 tsconfig.json은 다음과 같습니다.

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": true,
        "noImplicitAny": true,
        "rootDir": "src",
        "outDir": "build"
    },
    "exclude": [
        ".idea",
        "build",
        "node_modules",
        "typings/globals",
        "typings/modules"
    ]
}

내 폴더 구조는 다음과 같습니다.

• 프로젝트
  
  
  
  • 짓다
  
  
  • node_modules(../node_modules에 대한 심볼릭 링크)
  
  
  • node_modules
  
  
  • src
  
  

src 폴더에 있는 내 .ts 파일을 컴파일하고 동일한 폴더 구조로 빌드 폴더에 출력하기를 원합니다. 내 문서 루트를 빌드 폴더로 설정하고 내 src를 문서 루트에서 제외할 수 있도록 이 작업을 수행합니다. node_modules 폴더의 .ts 파일에 대한 오류 메시지가 나타납니다. OP와 동일한 오류 메시지입니다. 위에서 나는 node_modules를 제외했습니다. 왜 tsc가 그것에 대해 불평합니까?

@HillTravis 문제는 https://github.com/Microsoft/TypeScript/issues/9552 와 동일한 것 같습니다

@mhegazy 동일한지 잘 모르겠습니다. 예, 내 구조에는 symlink가 포함되어 있지만 해당 symlink가 존재하는 모든 위치는 무시되어야 합니다.

#9552에는 src 폴더가 없습니다. 즉, 빌드 중인 경로에 node_modules 폴더가 있습니다. 내 시나리오에서 tsc가 보고 있어야 하는 루트 디렉터리는 node_modules를 포함하지 않는 src입니다. 따라서 해당 폴더를 전혀 보지 않아야 합니다. 그 위에 tsconfig.json을 통해 명시적으로 제외된 node_modules 폴더가 있습니다. 따라서 이중으로 무시해야 합니다. 나는 또한 build 폴더를 제외했고 그 안에 있는 node_modules에 대한 심볼릭 링크를 덮어야 합니다.

또한 #9552에는 오류 메시지나 컴파일 실패에 대한 언급이 없었습니다.

또한 TypeScript 1.8.10을 사용하고 있음을 언급해야 합니다.

특히 오류 메시지는 다음과 같습니다.

오류 TS6059: '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.module.ts' 파일이 'rootDir' '/Users/thill/Projects/에 없습니다. nrc/클라이언트/src'. 'rootDir'에는 모든 소스 파일이 포함되어야 합니다.

오류 TS6059: 파일 '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.ts'가 'rootDir' '/Users/thill/Projects/nrc/에 없습니다. 클라이언트/src'. 'rootDir'에는 모든 소스 파일이 포함되어야 합니다.

오류 TS6059: '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/timepicker-event-interface.ts' 파일이 'rootDir' '/Users/thill/Projects/에 없습니다. nrc/클라이언트/src'. 'rootDir'에는 모든 소스 파일이 포함되어야 합니다.

@HillTravis 당신은 이것에 대해 저를 신뢰할 수 있습니다 :) 컴파일러를 던지는 것은 심볼릭 링크의 일관성없는 처리입니다. 노드 모듈 확인을 위해서만 심볼릭 링크를 따른 다음 해당 이름을 파일 이름으로 사용합니다. 그런 다음 사용자가 지정한 경로 대신 실제 경로를 사용하여 모든 파일이 소스 디렉토리 아래에 있는지 확인합니다. 이것이 오류를 생성하는 것입니다.

테스트로 심볼릭 링크를 제거해 보았습니다. 사실 build 폴더 전체를 삭제했습니다. 그런 다음 tsc 다시 실행했지만 여전히 오류가 표시됩니다.

더 많은 테스트를 하는 동안 특정 노드 모듈(ng2-datetime)의 코드 내 가져오기 및 사용을 주석 처리하려고 했더니 오류가 사라졌습니다. 따라서 심볼릭 링크에 관계없이 해당 노드 모듈을 가져오려고 할 때만 오류가 표시됩니다.

GitHub에서 해당 패키지의 소스를 보면 package.json 파일에 "main" 매개변수가 "ng2-datetime.js"로 설정되어 있음을 알 수 있습니다. 그러나 작성자도 동일한 매개변수로 .ts 파일을 게시했습니다. 이름. 이것이 문제를 일으키는 것 같습니다. .d.ts 파일을 만들고 .ts 파일을 삭제하면 문제가 사라집니다. 심볼릭 링크를 다시 추가한 후에도 문제 없이 컴파일되었습니다.

따라서 모든 측면에서 이 문제가 특히 심볼릭 링크와 어떻게 관련될 수 있는지 알 수 없습니다. 작성자가 패키지에 .ts 파일을 포함할 때 일반적으로 문제를 일으키는 것 같습니다.

이에 대한 해결 방법이 있는지 알고 있습니까? 위의 OP는 tsconfig.json에 "exclude"를 다시 추가하여 문제를 해결했다고 말했습니다. 이미 디렉토리를 제외했지만 여전히 컴파일을 시도하고 있습니다.

이에 대한 해결 방법이 있는지 알고 있습니까? 위의 OP는 tsconfig.json에 "exclude"를 다시 추가하여 문제를 해결했다고 말했습니다. 이미 디렉토리를 제외했지만 여전히 컴파일을 시도하고 있습니다.

이것은 다른 것과 관련이 있을 수 있지만 지금은 찾을 수 없습니다. 유형을 확인할 때 tsc 항상 node_modules 에서 찾으려고 하고, 거기에는 없습니다( typings ).

"tsc는 rootDir 외부의 ts 파일에 신경쓰지 않고 실패해야 합니다." 동의합니다.

모든 소스가 있어야 하는 곳이므로 typescript가 rootDir 외부의 JS 파일을 보는 이유를 이해할 수 없습니다 .
오류 메시지는 "'rootDir'은 모든 소스 파일을 포함할 것으로 예상됩니다"라고 표시되면 해당 디렉토리 외부의 모든 항목은 TS에 관한 한 소스 파일로 예상되거나 가정되어서는 안 됩니다!

이것이 "의도한 대로 작동"이라면 이 행동의 의도 또는 동기는 정확히 무엇입니까? TS가 rootDir 외부에 있는 소스 파일을 컴파일하려는 경우가 있습니까?

반면에 tsconfig에 "include" 섹션을 추가하면 문제가 해결됩니다. 포함할 파일이나 디렉터리가 제공되면 TS는 그 외부의 다른 파일을 찾지 않습니다.

타이프스크립트 1.8.10 사용

내 homedir ~/node_modules node_modules 폴더가 있습니다. 내 프로젝트 디렉토리 ~/projects/myProject/ 에서 tsc 를 실행하면 typescript가 다음 파일에 대해 불평합니다.

../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/config.d.ts(29,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(36,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(68,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(75,111): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/request.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/services/glacier.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.

매우 혼란 스럽습니다. 처음에 홈 디렉토리에 노드 모듈 폴더가있는 이유는 확실하지 않지만.

@iwllyu [email protected] 에서 프로젝트를 확인하고 여전히 문제가 있는 경우 새 문제를 제출할 수 있습니다.

다른 파일 세트에 대해 불평하지만 여전히 2.1.4에 문제가 있습니다.

Using tsc v1.8.10
../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(27,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(34,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(66,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(73,111): error TS1110: Type expected.

Using tsc v2.1.4
../../node_modules/aws-sdk/lib/config.d.ts(38,37): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/request.d.ts(164,16): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/s3/managed_upload.d.ts(15,16): error TS2304: Cannot find name 'Promise'.

테스트 케이스를 분리하는 프로젝트를 생성하겠습니다.

글쎄, 나는 새로운 프로젝트로 시도했지만 일어나지 않았습니다. 이것은 더 오래된 프로젝트이고 추가 node_modules 폴더를 제거하여 이미 수정했기 때문에 다시 만들려고 더 이상 시간을 들이지 않을 것입니다. 도와 주셔서 감사합니다!

이 사건에 대해. 가져오는 모든 것이 외부에서 유형(예: 이 "전면 유형 스크립트, 후면 유형 스크립트" 웨이브에 대해 실제로 서핑을 하고 있는 것처럼)인 경우 - 아마도 tsc가 내가 하는 일을 구별할 수 있을까요?
백엔드에서 내 프론트엔드 애플리케이션까지 내 엔터티 유형만 공유하고 있습니다. 물론 해당 클래스의 유형 및 가져오기가 없는 출력(컴파일 시간 및 인텔리센스에만 사용되기 때문에).

이것도 있었습니다.
지금 흐름을 고려하면 Typescript는 우리 팀에 너무 제한적입니다.

얘들아, 지금 이것에 대한 해결책이 있습니까? 백엔드 코드 내에서 클라이언트 코드의 유형 사용 및 기타.

최선의 선택은 무엇입니까? 거기에 복사하여 붙여넣고 유형을 변경하면 수정합니까?

2개의 프로젝트에 대해 하나의 루트 디렉토리를 만드는 것은 옵션이 아닙니다. 왜 백엔드 tsconfig.json에 jsx에 대한 정보가 있고 es2015를 사용할 수 있을 때 commonjs로 컴파일될 것이기 때문입니다.

baseUrl 이(가) 적합합니까?

@unional 은 baseUrl을 변경하지 않으며 모든 node_modules 가져오기를 중단합니다.

import * as request from "superagent";

하지만

import * as request from "node_modules/superagent/..something";

?

ㅋㅋㅋ 이게 정말 의도한 대로 작동하는 건가요? 방금 이것에 부딪쳤고, 내 소스가 모두 특정 폴더( rootDir 를 통해)에 있다고 typescript에 말한 다음 .ts 확장자가 해당 폴더 외부에 있습니다.

이것은 정말 오류처럼 느껴집니다. 컴파일러에게 rootDir 를 통해 소스가 있는 위치를 말하면 해당 설정을 완전히 무시하고 출력 폴더 구조를 변경해서는 안 됩니다. 왜냐하면 내가 뭔가 잘못했다고 생각하기 때문입니다. rootDir 없는 파일은 무시해야 합니다. 또는 내가 원하는 출력 폴더 구조와 전혀 일치하지 않는 출력을 계속 내보내지 않고 완전히 실패해야 합니다!

나를 따라 오는 사람을 위해 다음은 당신이 _실제로_ 원하는 것을 할 것입니다.

{
    "compilerOptions": {
        "outDir": "./output",
        "rootDir": "./source",
    },
    "include": [
        "source"
    ]
}

내 소스가 모두 특정 폴더(rootDir를 통해)에 있다고 typescript에 말했습니다.

이것은 rootDir 의미하는 바가 아닙니다! rootDir 는 "이 폴더를 outDir 의 경로 계산을 위한 상대적 기준으로 사용"을 의미합니다. 컴파일의 일부인 파일은 files 및/또는 include / exclude 로 답변되는 별도의 질문입니다.

그것을 수락하더라도 현재 동작은 여전히 ​​오류 IMO에 있습니다. 지정된 디렉토리 외부에 TS 파일이 있는 경우 rootDir 는 outDir 의 경로를 계산하는 기초가 되지 _아닙니다. 이는 내가 지정한 구성이 완전히 무시된다는 것을 의미합니다.

컴파일러가 내가 잘못된 구성을 부여했다고 효과적으로 생각하기 때문에 하드 실패가 훨씬 더 좋을 것이라고 생각합니다. 유효하지 않은 구성을 무시하는 것은 (IMO) 이 유형의 실패를 처리하는 올바른 방법이 아닙니다.

훨씬 더 명확한 오류 메시지의 예(하드 실패와 함께):

TSC가 rootDir 외부에 있는 typescript 파일을 찾았으므로 컴파일을 진행할 수 없습니다. 모든 typescript 파일을 포함하도록 rootDir 를 변경하거나 rootDir 외부의 파일을 제외하거나 rootDir 내부의 파일만 포함합니다.

참고: rootDir의 현재 동작이 매우 잘못되었다고 느끼는 이유의 큰 부분은 바로 rootDir 외부에 파일을 갖는 것이 이치에 맞지 않기 때문입니다. rootDir 외부에서 파일을 컴파일한다는 것이 무엇을 의미하는지 스스로(또는 컴파일러)에게 물을 때 유일한 대답은 "이해가 되지 않습니다"입니다. 따라서 rootDir이 sourceDir도 지정한다는 자연스러운 결론에 도달합니다.

악은 이름에 있습니다. 그것은 실제로 relativePathBaseDir 또는 이와 유사한 것을 의미합니다.

또한 include 일반적으로 "여기도 보세요"를 의미하지만 이 경우에는 "여기만 보기"를 의미합니다.
나는 그것이 다른 이름을 가지고 의무화되는 것이 현명할 것입니다.

IMO 이 의견 은 이것이 실제로 버그이며 다음과 같이 다시 열어야 함을 확인하기 위해 특히 고려되어야 합니다.

참고: rootDir의 현재 동작이 매우 잘못되었다고 느끼는 이유의 큰 부분은 바로 rootDir 외부에 파일을 갖는 것이 이치에 맞지 않기 때문입니다. rootDir 외부에서 파일을 컴파일한다는 것이 무엇을 의미하는지 스스로(또는 컴파일러)에게 물을 때 유일한 대답은 "이해가 되지 않습니다"입니다.

사실, 그것은 말이되지 않습니다 . " rootDir 외부의 소스 파일" 은 파일 확장자나 내용에 관계없이 단순히

이것은 버그라는 점에서 +100입니다(실제로는 불쾌한 것입니다). 다음 디렉토리 구조를 고려하십시오.

- src/
  - module.ts
- test/
  - module.test.ts
- out/
  - module.js

ts-node 테스트를 실행하기 때문에 tsc 만 src 만 컴파일하고 싶습니다. rootDir: 'src' 가 있으면 현재 컴파일 오류가 발생합니다. ts-node 로만 실행하려는 테스트 및 기타 항목을 "제외됨"으로 표시하면 나쁜 일이 발생하기 시작합니다(예: vscode 강조 표시가 테스트에서 깨짐 ).

실제로 rootDir , excluded 및 기타 모든 옵션의 조합은 모든 요구 사항을 충족하지 않습니다(테스트를 실행하고 작업할 수 있는 동안 컴파일에서 테스트 제외).

그리고 저는 제 사용 사례가 독특하다고 생각하지 않습니다. 따라서 적어도 UX 관점에서 "의도한 대로 작업" 레이블을 재고할 가치가 있습니다.

src / test / out 설정은 프로젝트 참조에서 해결한 주요 시나리오였습니다.

rootDir 설정한 후 typescript가 내 webpack.config.js 파일을 컴파일하려고 하는 이유를 인터넷 검색을 하다가 이 문제를 발견했습니다.

내 소스가 모두 특정 폴더(rootDir를 통해)에 있다고 typescript에 말했습니다.

이것은 rootDir이 의미하는 것이 아닙니다! rootDir은 "outDir의 경로를 계산하기 위한 상대적 기준으로 이 폴더를 사용"을 의미합니다. 어떤 파일이 컴파일의 일부인지는 파일 및/또는 포함/제외에 의해 답변되는 별도의 질문입니다.

이것이 답이다! rootDir에 대한 문서 는 말합니다.

입력 파일의 루트 디렉토리를 지정합니다.

"입력 _source_ 파일"을 의미하는 것으로 간주했습니다. @RyanCavanaugh 의 의견이 이 옵션에 대한 현재 설명을 대체하는 것이 좋습니다.

여기 링크 - https://github.com/Microsoft/TypeScript/issues/11299 는 이 문제의 복제본입니다. (해결책: include/exclude를 사용하여 컴파일할 파일을 지정합니다. rootDir은 컴파일할 파일을 지정하지 않습니다.)

@mhegazy 이 효과에 해당 스레드에 대한 의견을 추가하시겠습니까? 그것이 질문자가 말하는 것으로 보입니다(TS가 RootDir 외부의 파일을 보는 이유에 대해 혼란스럽고 rootDir이 의미하는 것과 동일한 오해).

저도 이 문제에 직면해 있으며 해결할 수 없습니다.

tsc 컴파일이 트리를 포함된 디렉토리에서 상위 폴더로 이동하여 중복 유형 오류를 발생시킵니다.

다음과 같은 중첩 폴더 구조가 있습니다.

└─src
└─package.json
└─node_modules
└─tsconfig.json
└─example
│ └─src
│ └─package.json
│ └─node_modules
│ └─tsconfig.json

이제 예제 디렉토리에서 tsc를 실행하려고 하면 다음 오류가 발생합니다.

node_modules/@types/react/index.d.ts:2809:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2809         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2814:14
    2814         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

오류에서 볼 수 있듯이 tsc는 예제 폴더에서 트리 위로 올라가서 부모 디렉터리의 node_modules 폴더를 찾고 있습니다! 더 나쁜 느낌은 거의 효과 없이 상위 node_modules 디렉토리를 명시적으로 무시하려고 시도했다는 것입니다.

다음은 예제 디렉토리의 tsconfig입니다.

{
  "compilerOptions": {
    "target": "es5",
    "experimentalDecorators": true,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "jsx": "react"
  }
,
  "typeRoots": [
    "./node_modules/@types"
  ],
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "../node_modules"
  ]
}

이 문제를 어떻게 해결할 수 있습니까? 위의 어느 것도 나를 위해 작동하지 않는 것 같습니다

@lexwebb 동일한 문제가 발생했습니다. @types/react 에 동일한 버전이 있는 yarn.lock 파일을 확인하십시오.
https://stackoverflow.com/questions/52399839/typescript-duplicate-identifier-librarymanagedattributes를 참조

내 자산 폴더에 확장자가 .ts 인 "MPEG Transport Stream" 비디오 파일이 포함되어 있기 때문에 여기에 도착했습니다. 그래서 폴더가 내 rootDir 경로에 없어도 tsc 충돌이 발생했습니다 😄

exclude 경로에 assets 폴더를 추가하여 수정했지만, 불안한 행동이었습니다 🤔

그래서 부모와 자식 패키지 json 모두에서 약간 다른 버전의 반응이 있는 것으로 나타났습니다. 버전을 일치시키면 문제가 정확히 제거되었습니다. 여전히 상위 디렉토리 양식 유형 검사를 제외할 수 없는 고통입니다.

나는 이것이 결코 고쳐지지 않을 것이라고 생각한다. 방금 같은 문제가 발생했습니다. 이것이 "의도한 대로 작동"하는 방법은 저를 넘어선 것입니다. 의도는 컴파일러를 무의미한 방식으로 실행하는 것이 었습니다.

내 개인적인 경험에 따르면 typescript 빌드가 rootDir 트리에서 벗어나서 예상하지 못한 것을 빌드하려고 시도하는 이유는 당신이 (의도적으로 또는 부주의하게) 직접 또는 간접적으로 무언가를 참조했다는 사실 때문입니다. rootDir 내의 영역. 그렇게 하면 참조 파일이 포함된 영역을 제외하려고 시도했는지 여부에 관계없이 빌드가 참조 트리를 따릅니다. 때로는 PITA가 어떻게/어디서 ​​그것을 했는지 알아내려고 할 수 있습니다. 그러나 항상 나는 그것이 tsc 의 잘못이 아니라 제 자신의 잘못이라는 것을 알게 됩니다. 내가 지시한 대로 하는 것뿐입니다.

이것이 나를 때릴 때마다 그것은 유형 때문입니다. 인터페이스 또는 다른 것을 가져오는 파일에 있는 다른 것을 가져오는 파일에 있는 것을 가져옵니다. 결국 rootDir 외부의 파일에 있는 것을 가져올 때까지 그리고 매우 자주 내 구성에서 명시적으로 제외하려고 합니다.

HTH 일부는 고통의 근원에 도달합니다. 아무리 많은 구성을 해도 빠져나올 수 없습니다. 가져오기 구조를 엄격하게 제어하기만 하면 됩니다.

@kpturner 매우 합리적으로 들리지만 — 폴더 간 가져오기가 없는 베어본 테스트 프로젝트는 모두가 불평하는 동작을 생성합니다.

진짜? 한 번도 본 적이 없는 것 :)

제외된 폴더는 내가 언급한 상황이 있는 경우를 제외하고 모든 프로젝트에서 항상 제외됩니다.

이 스레드에 베어 본 예제가 있습니까? 제 폰으로는 말씀드리기 어렵습니다.

죄송합니다. 배제는 제가 언급하는 '완전한 뼈대' 상황의 일부가 아닙니다. 가져오기가 동작의 원인이 아닌 것으로 보입니다(그렇다면 더 이해가 가겠지만).

즉, 이와 같은 것을 컴파일하면 오류가 발생합니다.

-src / src.ts <- no imports -test / test.ts -out -tsconfig.json {"rootDir": "src", "outDir": "out"}

그러나 tsconfig.json 가 그렇게 보인다면 typescript가 src 디렉토리의 모든 것과 test 디렉토리의 모든 것을 컴파일할 것으로 예상합니다. 당신은 단지 단지에서 물건 transpile하려면 src 와 출력 out 다음 디렉토리를 당신의 tsconfig.json 할 것

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    }
}

그러면 rootDir 외부에 일부 파일이 있기 때문에 TS6059 오류가 발생합니다. 따라서 다음을 제외해야 합니다.

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    },
    "exclude": [
        "test"
    ]
}

트랜스파일되면 src 포함된 src.js src 하위 폴더가 있는 out 폴더가 생성됩니다. test 폴더는 완전히 무시됩니다. 이것이 내가 예상하는 일입니다. 아니요?

어, 실제로 내 예제 tsconfig 는 첫 번째 예제에서 볼 수 있듯이 rootDir 및 outDir 아래에 compilerOptions 를 포함해야 합니다. 또한 test , test 및 해당 파일을 제외할 때 제외됩니다. 원래, 나는 당신이 TS6059 오류의 (또는) 범인이 rootDir 외부 rootDir 이라고 말하고 있다고 생각했습니다. 하지만 제가 당신을 잘못 읽은 것 같습니다. 그럼에도 불구하고 rootDir 외부의 디렉토리는 귀하가 설명하는 것처럼 명시적으로 제외되어야 한다는 사실에 놀랐습니다.

아니요. (이전) 참조 트리가 제외 목록에 트랜스파일될 수 있다고 말했습니다. 약간 다릅니다.

TS6059 오류는 처음에는 약간 당혹스럽습니다. 그러나 저는 TS가 제가 실수를 하지 않도록 도와주려는 것으로 봅니다. 내가 rootDir을 정의하는 데 어려움을 겪었고 plonk typescript가 해당 rootDir 외부로 날아간다면 TS는 효과적으로 "oi - 당신이 내가 접근할 수 없는 typescript를 생성했습니다 - 맞습니까?"라고 말하는 것입니다.

나는 "아니요, 잘못했습니다."라고 대답하고 파일을 rootDir로 옮깁니다.
또는
"네 맞습니다. 알려주지 않아 죄송합니다."라고 말한 다음 제외 파일 목록에 추가합니다.

이것은 너무 복잡합니다. 나는 monorepo가 ​​있고 paths 옵션을 사용하여 (같은 monorepo에서) 로컬 패키지를 가져오는 동안 올바른 디렉토리 구조를 내보내고 각 패키지를 적절하게 컴파일하는 방법을 찾지 못하는 것 같습니다.

출력 디렉토리의 디렉토리 구조에 원치 않는 상위 폴더가 포함되어 있거나 tsc가 루트 디렉토리 외부에 있는 파일에 대해 불평합니다.

이렇게 복잡할 수 없겠죠?

어떤 조합을 사용하든 tsc 는 paths 가 동일한 monorepo의 로컬 패키지를 참조하는 monorepo를 처리할 수 없는 것 같습니다. --build , --project , references , paths , extends , rootDir , rootDirs , include , exclude , baseUrl , outDir 다른 값을 가진 모든 종류의 조합에서 결국 rootDir 내에 없는 파일에 대해 불평합니다 outDir 내부에 잘못된 디렉토리 구조를 내보냄으로써 엉망이 됩니다.

내가 가지고 있는 것을 모노 리포지토리로 설명하지는 않겠지만 동일한 리포지토리에 3개의 다른 프로젝트가 있습니다. 그리고 다른 프로젝트의 문제나 간섭 없이 각각을 독립적으로 트랜스파일할 수 있습니다. 각 프로젝트에는 고유한 tsconfig가 있습니다.

꽤 오랜 시간 노력하고 수정한 후에 lerna와 typescript 가 references 와 함께 paths 및 사용에 더 이상 질식하지 않습니다 rootDir .

rootDir은 출력 폴더 구조를 빌드하는 데 사용됩니다. 컴파일러가 출력을 쓸 위치를 알기 위해서는 모든 파일이 rootDir 아래에 있어야 합니다.

출력이 필요하지 않은 파일은 어떻습니까? 루트 외부에 json 파일이 있는 경우:

const errors = require("../../../../errors.json");

ES6 버전을 컴파일할 수 없기 때문에:

import * as errors from "../../../../errors.json";

그러나 첫 번째 버전에서는 유형 안전성을 잃고 있습니다.

@mhegazy 이 문제는 3년 전에 종료되었습니다. 하지만 3년이 지난 지금도 여전히 혼란의 원인인 것 같다.

이 "의도한 대로 작업 중" 상태를 다시 확인해 주시겠습니까? 이 스레드에서 커뮤니티의 반응을 고려할 때 커뮤니티가 예상하는 대로 동작하지 않는다고 말하는 것이 안전

나는 당신이 이것보다 훨씬 더 높은 우선순위를 가지고 있다는 것을 이해할 수 있지만, 여기에 제공된 피드백이 가치 있게 여겨졌다는 어떤 징후도 없이 이 문제를 닫는 것은 Typescript에 대해 정직하게 좋은 이미지를 실제로 전달하지 못합니다.

@ngryman 다음 단계는 무엇입니까? rootDir 에 정의 가 있습니다. 이것은 내 소스 파일의 공통 루트입니다. rootDir 정의에 따르면 파일이 공통 루트에 없으면 오류입니다. 그 정의는 문서화되어 있습니다. 사람들이 rootDir 대해 자신만의 정의를 만들어 냈고 이후에 놀랐다는 사실에 대해 아무 말도 할 수 없습니다.

이것은 스타벅스에 가서 라떼를 요청한다고 해서 에스프레소와 찐 우유가 섞이지 않아야 한다고 말하는 것과 같습니다. 정의에 대해 논쟁하고 있기 때문에 실행 불가능

https://github.com/microsoft/TypeScript/issues/9858#issuecomment -370653478에서 언급했듯이 이 문제에 대한 해결책은 단순히 더 나은 오류 메시지라고 생각합니다. 내가 그것에 부딪쳤고 결국 이 GitHub 문제를 발견했을 때, 가장 큰 좌절은 문제를 파악하는 데 얼마나 많은 시간을 허비했는지, 그리고 나서 그것이 컴파일러 버그라고 생각하고, 그런 다음 재현 사례를 만들고, 그런 다음 "의도한 대로 작동"이라는 중복 버그. 명확한 오류 메시지로 빠르게 실패했다면 그 모든 것을 구할 수 있었을 것입니다.

rootDir 외부에 소스 파일이 있으면 TypeScript 프로젝트가 잘못 구성되었음을 의미합니다. 사용자에게 이 문제를 해결하는 방법에 대한 지침과 함께 이를 나타내는 명확한 메시지를 제공하면 많은 사람들이 문제를 해결할 수 있을 것이라고 생각합니다.

@RyanCavanaugh 빠른 답변 감사합니다.

이 페이지로 이동하면: https://www.typescriptlang.org/docs/handbook/compiler-options.html. 다음 정의를 읽었습니다.

입력 파일의 루트 디렉토리를 지정합니다. --outDir을 사용하여 출력 디렉토리 구조를 제어하는 ​​데만 사용하십시오.

나는 그것이 "출력 디렉토리 구조 를 제어 하는 유일한 사용 "이 중요합니다. 컴파일러가 실제로 수행 하는 유일한 작업은 아니지만 해당 디렉터리 외부에 Typescript 파일이 있으면 오류가 발생한다고 어떻게 추측할 수 있습니까?

어쩌면 내가 뭔가를 놓치고 있을지도 모르지만, 그렇다면 나는 유일한 사람이 아닙니다. 따라서 제품이 있고 많은 사용자가 제품을 이해하지 못하는 경우 취할 수 있는 방법은 두 가지뿐입니다. 사용자를 바보로 생각하거나 명확하게 전달하지 못하는 것입니다. 1차에 치우치지 않았으면 좋겠습니다 😕

스타벅 예시를 마치려면 재료 목록에 "익스프레소와 스팀 우유의 혼합물"이라고 잘 적어서 라떼가 무엇인지 알고 추측할 필요가 없습니다.

rootDir 외부에 있는 파일의 의미는 TS가 outDir 외부에 파일을 출력한다는 것입니다. 이는 명백히 나쁜 동작이라고 생각합니다.

오류 메시지가 더 나을 수 있습니다. 이에 대한 제안이나 PR을 원합니다.

문서는 항상 더 나을 수 있습니다. 다시 말하지만 더 명확하게 전달하는 방법에 대한 구체적인 아이디어를 원합니다.

내가 사람들을 바보라고 부르는 것을 암시하는 것은 내가 더 이상 원하는 것이 아닙니다.

rootDir 외부에 있는 파일의 의미는 TS가 outDir 외부에 파일을 출력한다는 것이며, 이는 명백히 나쁜 동작이라고 생각합니다.

컴파일러가 rootDir "chroot"하지 않고 해당 디렉토리 외부의 파일을 고려하지 않는 이유에 대해 여전히 명확하지 않습니다. tsc 내부 및 기록에 대한 컨텍스트가 부족한 사용자로서 이것은 확실히 예측할 수 없는 행동입니다.

내 머리에서 줄 수있는 한 가지 예는 동일한 옵션을 제공하는 Jest입니다. https://jestjs.io/docs/en/configuration#rootdir -string. AFAIK Jest는 rootDir 외부의 테스트 파일을 고려하지 않습니다. 예를 들어 여기에서도 동일한 동작을 예상합니다.

문서는 항상 더 나을 수 있습니다. 다시 말하지만 더 명확하게 전달하는 방법에 대한 구체적인 아이디어를 원합니다.

여기에서 개선을 고려하고 계시다니 기쁩니다. @MicahZoltu 의 제안은 탐색하는 것이

결국 rootDir 가 예측 가능하지 않다고 다시 말할 수 있지만(따라서 사람들의 반응), 내가 이해하는 한 해당 옵션의 동작을 변경하는 것은 고려할 사항이 아닙니다. 그래서 제가 제안할 수 있는 절충안 중 하나는 rootDir 이름을 더 의미 있는 이름으로 바꾸는 것입니다. outBaseDir 가 후보가 될 수 있습니다. 하지만 아마 더 좋은 이름이 있을 것입니다.

내가 사람들을 바보라고 부르는 것을 암시하는 것은 내가 더 이상 원하는 것이 아닙니다.

나는 아무 암시도 하지 않았고 그렇게 받아들였다면 죄송합니다. 저는 아주 간단한 사실만 말했습니다. 사용자가 자신이 이해하지 못하는 것에 대해 불평할 때 효과적으로 취할 수 있는 방법은 두 가지뿐입니다. 나는 당신이 첫 번째 것에 기대지 않기를 바랍니다. 당신이 이러한 경로 중 하나와 자신을 연관시킨다는 사실은 솔직히 당신에게 맡겨져 있습니다.

특히 이 스레드가 처리된 방식에 대해 솔직한 피드백을 제공하는 것에 대해 제가 말해야 할 것을 말한 것 같습니다. 그래서 나는 다른 사람들이 해결책을 제안할 여지를 남겨두겠습니다.

@ngryman rootDir 의 정의와 실제로 수행하는 작업이 일치하지 않는 것 같다는 데 동의합니다. tsc --init 를 통해 새 ts 프로젝트를 만들 때 tsconfig.json 대한 rootDir tsconfig.json 의 주석은 /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */ 인용한 것과 유사합니다. _input_ 파일의 디렉토리를 제공하면 입력의 정의에 따라 컴파일을 고려하는 유일한 디렉토리가 해당 디렉토리에 있을 것으로 예상합니다.

@RyanCavanaugh 4년 전 typescript가 자바스크립트로 컴파일되는 데만 사용되었을 때 이와 같은 오류를 보고하는 것이 합리적이었을 ts-node 와 같은 typescript 실행의 인기로 인해 tsc가 약간 질투하는 것 같습니다.

그리고 rootDir 외부의 typescript 파일이 잘못된 프로젝트 구성을 암시한다는 생각은 단순히 잘못된 것입니다. 타입스크립트로 작성된 단위 테스트를 자바스크립트로 컴파일할 필요가 없습니다. ts-node 는 더 빠르고 테스트를 작성할 때 타이프스크립트의 모든 이점을 누릴 수 있습니다.

@CodySchrank에 동의합니다. rootDir 내부의 일부 소스 파일이 외부 파일을 참조/가져올 때 TS 오류가 발생해도 괜찮습니다.

그러나 TypeScript 자체가 rootDir 외부의 관련 없는 파일을 살펴보고 오류가 발생하는 동안 이러한 파일은 jest 또는 기타 도구와 같은 다른 도구에 대한 구성 파일일 뿐이라는 것을 이해할 수 없습니다. 내 말은, 요점이 무엇입니까? 이것들은 내 응용 프로그램의 일부도 아니며 어디에서 직접 참조/가져오기도 되지 않습니다. 맙소사, 처음에 결과 빌드에 번들로 포함되기를 원하는 이유는 무엇입니까?

이 오류를 경고로 바꾸면 어떤 의미가 있는지 궁금합니다. 코드를 간략하게 훑어본 결과 확실히 가능한 것처럼 보이지만 tsc 빌드 프로세스에 대한 전문가는 아닙니다. 잠재적인 문제에 대한 알림을 유지하면서 원할 경우 이를 우회하도록 하는 것 사이의 행복한 매개체처럼 보입니다.

src / test / out 설정은 프로젝트 참조에서 해결한 주요 시나리오였습니다.

이를 위해서는 각 루트 폴더(https://www.typescriptlang.org/docs/handbook/project-references.html)에 대해 최소한 별도의 프로젝트 구성이 필요합니다. 지침을 읽고 나서 패턴을 구현하는 방법을 제대로 이해하지 못한 채 자리를 떠났고, 제가 요청한 것이 파리채였을 때 착암기를 건네주는 것 같은 느낌이 들었습니다.

물론 내 소스 폴더 내에서 부속 모듈을 별도의 하위 프로젝트로 유지하는 것이 더 효율적이지만 여기서는 lodash를 컴파일하지 않습니다. 내가 원하는 것은 정적 분석을 위한 공통 프로젝트 폴더 아래에 테스트 및 벤치마크 파일과 같은 많은 파일을 포함하고 컴파일할 때 외부 세계에서 사용할 단일 디렉토리만 내보내는 것입니다. 이것은 지정하기에 충분히 쉬워 보이며 사용자가 수행하기 어려울 뿐만 아니라 TS 사양의 관점에서 분명히 _verboten_인 이유를 알기 위해 고군분투하고 있습니다.

내가 강조하고 싶은 것은 이 기능이 허용되지 않는 유일한 이유는 컴파일러가 개발자의 의도가 손상되었다는 가정 때문이라는 것입니다. 개발자가 "outDir" 를 ./src 로 설정하고 컴파일러가 ./test 에서 TS 파일을 찾으면 이 파일을 내보낼 필요가 없다고 가정 _할 수 있습니다(물론 "outDir"의 어떤 파일에서도 참조되지 않음).

하지만 그렇지 않습니다. 개발자가 이 파일을 내보내길 원했으며 무능이나 악의로 인해 이 파일이 포함되지 않은 하위 디렉토리를 지정했다고 가정합니다. 다시 말해, 컴파일러는 개발자의 지침을 일반적이고 합리적인 사용 사례와 일치시킬 수 있는 기회가 있으며, 그 대신에 터무니없는 것과 일치시키고 진행을 거부합니다.

현재로서는 "outDir" 의 합법적인 사용 사례가 무엇인지조차 알 수 없습니다. tsconfig.json 가 다른 구성 및 메타데이터 파일과 함께 최상위 수준에 있는 프로젝트 구조를 지원하기 위한 것으로 가정하고 소유자는 컴파일된 폴더가 그 안에 중첩된 소스 폴더만 나타내기를 원합니다. (그 메타 파일 중 어떤 것도 .ts 끝나지 않는지 확인하십시오. 이는 터무니없을 것입니다.)

사양의 디자인이 사용자 적대적인 것 같습니다. 스타벅스에서 음료를 주문하고 메뉴에 재료가 나와 있는데도 기대한 것과는 다르게 속상해한다는 언급이 있었다. 여기까지는 맞는데 이 기능은 핫도그를 팔지 않는 핫도그 가판대에 더 비유하고 싶습니다.

물론 짜증난 손님들은 돌아서서 핫도그 판매대에서는 핫도그를 팔지 않는다고 과감하게 알리는 큰 간판을 봤어야 했다. 그러나 혼란이 누적됨에 따라 핫도그 가판대의 소유자는 제품의 기능을 고객에게 전달하는 방법에 대해 생각할 기회가 있을 수 있습니다.

흠, 이것을 더 고려하면 이 문제의 기저에 있는 핵심 팀의 일부에 일종의 불변성이 있는지 궁금합니다.

모든 소스 코드를 컴파일해야 합니다. 컴파일되지 않으면 소스 코드가 아닙니다.

사용자 영역에서는 어떻게든 이를 극복할 필요가 있습니다. 소스 코드 즉, 정의를 확장하여 이를 수행하는지 모르겠습니다. TypeScript, 또는 두 번째 카테고리 생성("지원 코드", "검증 코드", "주변 코드"...). 이것은 소스와 동일한 유형 정의에서 작동할 것으로 예상되는 코드이며 소스가 올바른 것으로 간주되도록 성공적으로 검증해야 하지만 인터페이스와 관련하여 프로그램의 실제 기능의 일부가 아닙니다.

TypeScript의 소비자로서 나는 그러한 범주를 구현하는 데 따른 특정한 어려움에 대해 잘 알지 못합니다. 그러나 "outDir" 딱 맞는 것 같습니다. "outDir" 내부의 모든 것은 소스의 일부이고 외부의 프로젝트 폴더 내부는 지원 코드의 일부입니다. 이것을 유용/필수적으로 만드는 주된 것은 ts-node의 출현입니다. 즉, 이 지원 코드를 컴파일과 완전히 독립적인 별도의 단계로 실행할 수 있습니다. 물론 나는 그것을 활용할 수 있기를 원합니다.

도구에 제공된 입력 파일을 암시적으로 포함하지 않음

이 문제는 정확히 _왜냐하면_ 사용자가 rootDir 외부의 파일을 암시적으로 컴파일하려고 하기 때문에 발생합니다. 기본적으로 컴파일러에게 "이 디렉토리의 파일만 컴파일"이라고 말한 다음 해당 디렉토리 외부의 파일을 참조하도록 진행했습니다. 컴파일러가 혼란스러워 어떻게 진행해야 할지 모릅니다.

/project/source/index.ts

import '../external.ts'

/project/tsconfig.json

{
  "compilerOptions": {
    "rootDir": "./source"
  }
}

이 예에서 컴파일러에게 "소스 파일은 '소스' 디렉토리에만 있습니다"라고 말합니다. 그런 다음 해당 파일 중 하나가 소스 디렉토리에 _not_ 있는 파일을 참조합니다. TypeScript에는 이제 두 개의 충돌하는 명령이 있습니다. 하나는 소스 디렉토리의 파일만 컴파일하라는 것이고 다른 하나는 소스 디렉토리 외부의 파일을 컴파일하라는 것입니다.

@MattiasMartens 당신은 암시 적으로 include 및 rootDir 병합하고 있습니다. /src 및 /test 가 있는 경우 include 가 src/* 이면 /test 항목에 대한 오류가 발생하지 않습니다. src 에서 test 에서 항목을 잘못 가져왔습니다.

프로그램에서 잘못된 가져오기가 어떻게 생겼는지 기록하는 메커니즘을 제공하고 이러한 잘못된 가져오기가 발생할 때 오류를 발생시키는 것은 사용자에게 적대적이거나 적대적이지 않습니다. 다시 말하지만 이것은 플래그가 무엇을 의미 하는지 오해하기 때문이라고 생각합니다. 플래그는 주로 프로그램이 올바르게 구성되었는지 확인 하는 데 도움이 되는

어쨌든!

rootDir 의 정의가 주어지면 TypeScript가 제공된 rootDir 외부의 파일을 볼 때 몇 가지 옵션이 있습니다.

• outDir 위의 파일을 내보내십시오(이것이 가능하다고 가정합니다!). 이는 출력 위치에 대한 사용자의 지시와 모순됩니다.
• 파일을 처리하지만 내보내지 마십시오. 다른 빌드 단계가 없으면 작동하지 않는 프로그램이 생성됩니다.
• 프로젝트가 잘못 구성되어 있기 때문에 오류가 발생합니다.

나는 작동하지 않는 프로그램 이 기본값이어야 한다는 개념에 강력히 반대합니다. 여기서 기능 요청이 단순히 rootDir 외부에서 발견된 .ts 파일을 .d.ts 로 처리하는 것이라면 이는 합리적이며 rootDir 의미와는 별개의 것입니다. rootDir 이외의 것. 그런 깃발을 뭐라고 부르겠습니까?

@MattiasMartens 당신은 암시 적으로 include 및 rootDir 병합하고 있습니다. /src 및 /test 가 있는 경우 include 가 src/* 이면 /test 항목에 대한 오류가 발생하지 않습니다. src 에서 test 에서 항목을 잘못 가져왔습니다.

그건 사실이야. 나는 include 대해 의아해했고 VSCode의 도구를 포함하여 이 경우에 대해 생각했던 것보다 더 잘 작동한다는 것을 발견했습니다.

나는 여전히 컴파일 시 유효성 이 내보내 지지 않는 코드를 갖고 싶습니다. 이는 include 다루지 않는 것입니다. 그러나 그것은 여기에서 논의할 필요가 없는 별도의 요청입니다.

나는 이것이 플래그가 무엇을 의미하는지 오해하는 데서 비롯된 것이라고 생각합니다. 플래그는 주로 프로그램이 올바르게 구성되었는지 확인하는 데 도움이 되는 _옵트인 시행 확인입니다.

나는 이것에 의해 혼란스러워한다. rootDir 옵트인 시행 확인을 고려하십니까? 그것은 결국 방출되는 것에 영향을 미치므로 분명히 시행 확인이 _유일한_ 아닙니다.

target 와 같은 일부 플래그는 방출되는 내용을 크게 변경합니다. 이는 시행 검사가 아니라 컴파일러 명령입니다. rootDir 는 컴파일러 명령처럼 읽고 문서화됩니다.

나는 _작동하지 않는 프로그램을 내보냄_이 기본값이어야 한다는 개념에 강력히 반대합니다.

지금까지 이 스레드에 대해 읽은 내용에서 rootDir 내부의 파일 에서 rootDir 외부의 파일로의 참조는 _오류여야 한다는 광범위한 합의가 있는 것 같습니다. 나와 다른 사람들이 실망 스러웠던 기능의 측면은 거기에서 그치지 않지만 실제로 rootDir 외부의 프로젝트 폴더에서 TS 파일 을 찾으면 오류가 발생합니다 rootDir 수입 여부.

반복해야 합니다. rootDir 를 내 소스 코드가 있는 폴더로 설정하고 컴파일러는 rootDir 에 있는 것과 아무 관련 이 이 특정 동작 은 내 코드를 이해하는 데 도움이 되지 않습니다. 그냥 짜증납니다.

rootDir 에 대한 TypeScript 정의의 관점에서 볼 때 이 스레드에서 자세히 설명하는 것처럼 동작은 완벽하게 합리적이며 이에 대해 불만을 표명하기 위해 여기에 온 모든 사람이 오류가 있는 것이 사실입니다. 그러나 루트 디렉토리에 대한 기존의 예상된 정의에서는 합리적이지 않습니다. 루트 디렉토리를 제공하는 거의 모든 컨텍스트에서 파일 구조를 탐색하기 시작할 위치를 프로그램에 알려주고 파일 시스템에 다른 것이 없는지 절대적으로 묻지 않습니다. 관심.

정의가 틀릴 수 있습니다. 그들은 변경할 수 있습니다. 이전 버전과의 호환성을 위해 정의는 유지할 필요가 없고 기능만 유지하면 됩니다.

여기서 기능 요청이 rootDir 외부에서 발견된 .ts 파일을 .d.ts 로 처리하는 것이라면

나는... rootDir 무언가가 외부에서 코드를 가져올 때 컴파일러가 오류를 던지기를 원하는 것과 거의 같은 이유로 그것을 원하지 않는다고 생각합니다. rootDir 의 내용을 제공하는 경우 주변 코드에서 캡슐화해야 한다고 생각합니다.

나는 다른 사람들이 원하지 않는 동작을 방지하는 가장 간단한 방법은 암시 적으로 외부의 파일을 제외 할 생각 rootDir 에있는 파일 경우 rootDir 그들에게 참조하지 않습니다. 에있는 파일 경우 rootDir 그들에게 참조 할이 현재와 같은 오류가 발생한다.

거기에 있는 모든 단락은 " rootDir 는 include 의 기본값을 변경해야 합니다"로 요약되는 것 같습니다. 이는 오늘 동시에 해당 플래그를 추가하는 경우 제안하는 합리적인 방법이지만 현재로서는 만들 수 있는 획기적인 변경 사항이 아닙니다. 틀림없이 서로 더 증가인지 부하와 상호 작용하는 모든 구성 플래그를 만들기보다는 감소 비록.

include 가 명시적으로 설정되지 않고 포함된 파일이 rootDir 외부에 있는 경우 사용자 지정 오류를 발행해야 할 수도 있습니다.

"tests/foo.ts" 파일이 rootDir 'rc' 외부에 있습니다. "포함" 패턴을 설정하는 것을 잊으셨습니까?

기록 #33515

https://github.com/microsoft/TypeScript/issues/31757#event -2480427393에서도 문제가 있었습니다.

rootDir, 포함 및 제외 간의 상호 작용은 너무 이상하게 설계되었습니다.

나는 항상 rootDir이 컴파일러가 탐색을 시작하고 rootDir에서 참조할 수 있는 추가 폴더(예: 공급업체 폴더)를 포함하는 폴더라고 생각했습니다.

현재 정의는 지옥처럼 이상하고 매우 직관적이지 않습니다.

아이러니하게도 혼란스러운 것은 상호 작용 하지 않는다는 것입니다 . 설정은 서로 전혀 영향을 미치지 않습니다. include 는 프로그램의 내용을 100% 제어하고 rootDir 는 outDir 의 레이아웃 계산을 100% 제어합니다.

문제의 또 다른 예를 추가하기 위해 이것은 내 폴더 구조입니다.

tsconfig.json
package.json
src/index.ts

내 tsconfig에 있습니다.

"rootDir": "src",
"outDir": "lib",

그리고 내 "index.ts"(src 폴더)

import pkg from '../package.json'; // I read the package.json object

export class SomeClass {
  public version = pkg.version;
}

나는 빌드 후에 "index.js" 파일이 "lib" 폴더 안에 있을 것이라는 것을 _알고_ 있습니다. 그리고 나는 package.json이 1단계 올라갈 것이라는 것을 _알고_ 있습니다.
Typescript가 내 폴더 구조를 나보다 더 잘 알고 빌드를 중단해야 한다고 생각하지 않습니다. 출력 폴더에 포함되지 않은 rootDir 폴더 외부의 일부 파일에 대한 경고를 기록해야 합니다.

@sebelga 아마 버그가 있다고 생각 하는데요 - 수 .json 에서 외부 rootDir TS가 출력 폴더에 그 복사하지 않기 때문에 확인 될 것

@sebelga 나는 아마도 버그 - TS가 출력 폴더에 복사하지 않기 때문에 외부 rootDir에서 .json을 허용하는 것이

사실이 아닙니다.. 우리는 .json 파일을 내보내는 몇 가지 특별한 규칙이 있습니다... 파일이 같은 위치에서 자체적으로 내보내질 예정이라면 파일만 내보내지 않습니다. 모든 경우에 방출됩니다(예: --outDir가 지정되면 해당 폴더로 방출됩니다)

@RyanCavanaugh 런타임에 package.json 에서 버전 번호를 console.log 출력하려는 @sebelga 와 유사한 사용 사례가 있습니다.

그래서 내 솔루션은 내 "rootDir": "." 변경하는 것이 었습니다. 그러면 여기에 포함됩니다.

"include": [
    "src",
    "typings"
  ]

그리고 package.json 파일이 lib (빌드) 폴더에 포함되어 있고 이 폴더에는 "src" 하위 폴더가 포함되어 있으므로 빌드 직후에 실행되는 bash 스크립트를 작성하여 정리했습니다.

#!/bin/bash

rm lib/package.json
mv $(pwd)/lib/src/* $(pwd)/lib
rm -rf lib/src

그것은 작동하지만 나에게 꽤 해킹 된 느낌입니다.

@sebelga typings 폴더에 .ts 파일이 있습니까? 그렇지 않은 경우 rootDir 를 src 하고 스크립트를 건너뛰는 것이 합법적입니다.

@sebelga const { version } require('../../package.json') 또는 import { version } from 'package.json') 대신 다음과 같이 시도해 보셨습니까?

import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');

TypeScript는 이런 식으로 rootDir 외부에 있는 것에 대해 신경 쓰지 않습니다.

https://github.com/sindresorhus/load-json-file

모든 ../.. 를 하드코딩하지 않으려면 다음을 시도할 수 있습니다.
https://github.com/sindresorhus/read-pkg-up

@RyanCavanaugh 위에서 언급한 대로 "src"로 설정할 수 없습니다. src( import pkg from '../package.json'; ) 외부에서 "package.json"을 가져오고 있는데 tsc는 이를 허용하지 않습니다.

@dylang 을 공유해 주셔서 감사합니다! 나는 그것을 시도 할 것이다.

내 소스가 모두 특정 폴더(rootDir를 통해)에 있다고 typescript에 말했습니다.

이것은 rootDir 의미하는 바가 아닙니다! rootDir 는 "이 폴더를 outDir 의 경로 계산을 위한 상대적 기준으로 사용"을 의미합니다. _컴파일의 일부인 파일_은 files 및/또는 include / exclude 로 답변되는 별도의 질문입니다.

@RyanCavanaugh 하지만 rootDir 가 의미하는 바는 이것이고 이것이 이 문제에 대한 것입니다.

나는 컴파일러에게 오류를 무시할 수 있다는 것을 알려주는 새로운 "compilerOption"을 도입함으로써 기존 사용자에게 새로운 문제를 도입하지 않고 아마도 매우 수정될 수 있는 2016년 이후에 열린 문제를 볼 때 평정을 유지하는 데 능숙하지 않습니다. 주어진 사용 사례에서.

이에 대해 사과드립니다. 좋은 서비스를 제공해야 하기 때문에 어쩔 수 없지만 가끔 이와 같은 문제 스레드가 발생합니다. TypeScript 작성자가 하나의 간단한 구성 플래그를 구현하는 것이 왜 그렇게 어려운가요?

개발자들이 게으르거나 도움을 줄 의사가 없기 때문이 아니라고 생각합니다. 나 말고는 여기 있는 사람이 나쁜 사람이라고 생각하지 않는다.

속성 "rootDir"의 정의로 보이는 것에 대해 수년 동안 계속되어온 이 갈등, 이 논쟁입니다. 그리고 이 문제에 대해 어떻게 해야 할까요?

사람들은 자신이 옳다고 믿기 때문에 이 논쟁에 휘말리게 됩니다. 예, "rootDir"은 소스 코드의 기본 디렉토리 역할을 합니다. 예, 오류가 유효합니다.

그러나 근본적인 문제는 여전히 남아 있습니다. 내 도구는 코드를 완벽하게 컴파일하지만 내 IDE는 내 화면에 이 오류를 표시합니다. 그것은 변태입니다. 나는 그 빨간 선을 없애고 싶다. 내 파일에는 오류가 없습니다. 그리고 만약 그렇다면, 나는 이러한 비 이슈들에 주의를 산만하게 하기 보다는 그것들에 집중해야 합니다.

내가 원하는 것은 이 오류 메시지를 표시하지 않는 것입니다. 그것이 우리 대부분이 원하는 것이라고 생각합니다. 여기에 다른 사례가 있는지, 아마도 그것에 대해 이야기하고 싶은 사람들이 있을지 모르겠습니다.

함께 협력하여 이 문제를 해결할 수 있습니까? 저 빨간선이 사라지는 걸 보면 너무 행복할 것 같아요...

@nullquery tsc 작동하지만 IDE에 빨간색 물결선이 표시 되면 IDE가 tsc 와 동일한 컴파일러 버전 또는 구성을 사용하지 않는다는 의미입니다.

@nullquery 는 문제를 재현하는 방법을 보여주는 버그를 파일에 저장하고 이를 수정하거나 프로젝트 구성의 문제를 알려드립니다.

@sebelga 해결 방법에 이어 npm 스크립트 내부에 들어가는 데 적합한 변형이 있습니다.

tsc --module commonjs --target ESNext --outDir ./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true

여기에서 사용 예.

경계가 자동으로 적용합니다.

솔루션은 프로젝트 참조 입니다.

이것을 사용하려면 "tsconfig.json" 파일을 편집하고 이것을 파일 끝에 추가하십시오("compilerOptions" 외부):

"references": [
    { "path": "../common" }
]

이렇게 하면 "../common/" 폴더(및 모든 하위 폴더)의 파일을 참조할 수 있습니다.

이전의 혼란은 IntelliJ와 오염되지 않은 gulp-typescript 작업이 동일한 "tsconfig.json" 파일을 사용했음에도 불구하고 다른 결과를 제공한다는 사실에서 비롯되었습니다.

어떤 이유에서인지 "gulp-typescript"는 컴파일에 최선을 다하고 있는 것으로 나타났습니다.

TypeScript의 오류(예: let z: number = '' )는 IntelliJ에서 플래그가 지정되지만 "gulp-typescript"는 이를 제대로 컴파일합니다.
JavaScript 구문 오류(예: let 1z = '' )만 "gulp-typescript"에 의해 플래그가 지정됩니다.

따라서 "gulp-typescript" 사용자인 경우 "gulp-typescript" 버전 및 구성에 따라 이러한 문제가 발생할 수 있습니다. (글을 쓰는 시점에서 최신 버전을 사용하고 있지만 미래의 누군가가 이것을 읽을 것이라고 가정합니다. 시간이 더 나았으면 합니다.)

나는 프로젝트 참조의 사용이 이 눈부신 응답의 어딘가에 묻혀 있다는 것을 알고 있지만, 이것이 더 잘 문서화되었다면 더 좋았을 것입니다.

Google에서 "TS6059"에 대한 상위 3개 결과는 모두 GitHub 문제로 이어집니다. 이러한 일반적인 오류와 해당 솔루션을 문서화한 페이지가 있었다면 훨씬 더 명확했을 것입니다.

@MicahZoltu 이것이 해결될 수 있는 일입니까? 새 문제를 만들어야 하나요, 아니면 주요 기여자 간에 내부적으로 논의된다면 더 빨리 진행될까요?

(FWIW 저는 TypeScript 팀의 일원이 아닙니다)

일반적으로 꼭 필요한 경우가 아니면 path 하지 않는 것이 좋습니다. 나는 그것의 목적이 이상한 의존성 구조를 가진 레거시 JS 프로젝트와의 호환성을 허용하는 것이라고 생각하지만, 그것이 새로운 프로젝트에 사용되도록 의도된 것이라고 생각하지 않습니다. 당신은 기회가 있습니다. 나는 개인적으로 그것을 사용하지 않기 때문에 당신이 가질 수 있는 문제에 대해 실제로 도움을 줄 수는 없지만 많은 사람들이 그것에 대해 어려움을 겪는 것을 보았고 해결책은 일반적으로 "사용 중지"입니다.

gulp-typescript의 경우 gulp-typescript에서 사용하는 TSC 버전이 IntelliJ에서 사용 중인 TSC 버전과 다른 것처럼 들립니다. 설명하는 것과 같은 증상이 나타나면 일반적으로 문제입니다(다른 하나는 동일한 tsconfig.json 사용하지 않는다는 것입니다).

"gulp-typescript"에서 사용하는 버전은 동일해야 합니다. 두 버전 모두 node_modules 에서 파생됩니다. 나는 오류를 포착하고 이와 관련된 설정을 수정하는 다양한 방법을 시도했습니다("gulp-typescript"에서 제공하는 다양한 "리포터"를 어지럽히고 더 ​​많은 오류를 발생시키기 위해 설정을 재정의하려는 시도 포함). 아무 것도 작동하지 않는 것 같습니다.

그래도 괜찮습니다. IntelliJ가 오류를 제공하는 한 Gulp 작업이 오류를 무시한다는 사실을 기꺼이 받아들입니다.

나는 그 주의 선호하는 방법에 찬성하여 나의 방법을 정밀 검사하는 팬이 아닙니다. 내가 가지고 있는 프로젝트 구조는 나에게 의미가 있습니다. 모든 것을 포함하면서도 여러 구성 요소로 분할할 수 있는 유연성을 제공합니다.

나는 "레거시 이유로 호환성을 허용하는 것"을 믿지 않으며 특히 프로젝트 참조와 관련하여 그렇습니다. rootDir 외부의 파일을 참조하는 것이 _반드시_ 가능해야 합니다. 그렇지 않으면 귀하와 귀하의 팀이 이해하는 방식으로 프로젝트 구조를 정의할 자유가 없을 것입니다.

TypeScript로 처음 작업을 시작했을 때 많은 문제에 부딪쳤습니다. 그 중:

• JavaScript 파일을 포함하기 위한 솔루션은 당시 AMD인 것 같았습니다. 웹사이트는 공식적으로 들리고 AMD의 프로덕션 사용 사례가 온라인에 많이 있었습니다. 그러나 분명히 Webpack은 새로운 큰 일이었고 일부 프로젝트는 단순히 AMD 환경에서 작동하지 않았습니다. 교훈: 모든 사람이 새로운 방법을 채택하는 것은 아니므로 항상 망하게 됩니다.

• TypeScript에서 최종 축소된 JavaScript(소스 매핑 포함)로 가는 길은 나에게 명확하지 않았습니다. 당시에는 여러 가지 다른 방법을 사용할 수 있었지만 그 당시에는 "tsconfig.json" 파일 및/또는 내 IDE에서 기본적으로 작동하지 않는 것 같았습니다. 교훈: 올바른 일을 하고 싶다면 스스로 해야 합니다. 다른 사람들이 당신을 위해 일을 하도록 의존하지 마십시오. 그들이 아무리 좋은 의도를 가지고 있더라도 아무도 완벽하지 않으며 아무도 _당신의_ 작업 공간을 예측할 수 없습니다.

• 내가 원하는 한 가지 맞춤 설정이 있었습니다. HTML 파일의 내용을 포함하기 위해 JavaScript 사전으로 변환하는 방법이었습니다. 이것이 나의 유일한 걸림돌이 되어야 했지만, 결국 이것은 쓰기 쉬운 스크립트 중 하나로 밝혀졌습니다.

결국 모든 것을 처리하기 위해 나만의 Gulpfile을 개발해야 했습니다. 다음을 수행합니다.

• 배포용으로 축소된 JavaScript 파일을 node_modules 폴더에서 내 웹 루트로 복사합니다. 간단해 보이지만 포함시키려는 거의 모든 JavaScript 라이브러리는 축소된 JavaScript 파일을 저장하는 위치가 다릅니다. 구성도 없었고 파일에 대한 명확한 경로도 없었습니다. 결국 포함하고 싶은 각 JavaScript 라이브러리에 대해 별도의 스크립트를 작성해야 했습니다. 위치가 향후 버전에서 변경되지 않는다고 가정하면 작동하지만 변경되는 경우 항상 복사 스크립트를 변경할 수 있습니다.

• 출력 디렉토리에 별도의 파일을 생성하는 로컬 "tsconfig.json" 파일에 따라 TypeScript를 컴파일합니다( outDir ). (하하하하!) 그런 다음 "롤업" 플러그인을 사용하여 해당 파일을 단일 JavaScript 파일로 압축한 다음 UglifyJS를 실행하여 이 파일을 축소합니다. 이 모든 작업은 원본 TypeScript 파일에 다시 매핑되는 소스 매핑을 유지하는 것입니다.

• (사용자 정의 작업) TypeScript 소스 루트의 각 HTML 파일에 대해 html_templates 라는 사전을 포함하는 JavaScript 파일을 생성하고 이를 축소된 JavaScript 파일로 내 webroot 폴더에 배치합니다.

더 우아한 방법이 있을 수 있지만 하나의 오픈 소스 프로젝트에서 다음 프로젝트로 넘어간 후에는 각각이 제공하는 솔루션 사이에서 충분히 저글링을 했습니다.

내가 선택한 접근 방식은 효과가 있으며 이해하기에 충분히 간단하며(특히 "gulp-typescript"가 다른 작업을 수행한다는 것을 이해했기 때문에) 앞으로 몇 년 동안 이것을 계속 사용할 것입니다.

가장 좋은 해결책은 자신을 이해하는 것입니다. 이것은 나를 도우려는 사람에게는 도움이 되지 않지만(매우 감사합니다! 혼란이 아니라 도움을 주셔서 감사합니다) _any_ 솔루션에는 항상 문제가 있을 수 있으므로 무언가를 고수하는 것이 좋습니다. 다양한 신념, 성적 취향 및 성별 정체성을 가진 다문화 팀 이 하고 있습니다.

tl;dr 프로젝트 참조를 중단하지 마십시오. 내 도구가 작동하려면 필요합니다. 감사 해요

다중 프로젝트 TS 설정을 제대로 설정하는 것을 포기하고 모든 프로젝트에서 tsc -w 하고 npm link 하면 다중 프로젝트 tsconfig의 모든 복잡성을 무시하고 다른 항목을 참조할 수 있습니다. node_modules 의 일반 node.js 종속성과 같은 프로젝트입니다.

그러나 오늘 한 프로젝트에서 대상을 es5 에서 es6 했으며 File '.../lib.ts' is not under 'rootDir' 때문에 더 이상 컴파일되지 않습니다.

파일 구조:

/app
 - tsconfig.json // rootDir = "."
 - app.ts (

/app/node_modules/lib
 - tsconfig.json // rootDir = "."
 - lib.ts
 - lib.js
 - lib.d.ts

왜 tsc 에서 /app 에 대한 염려 /app/node_modules/lib/lib.ts 파일? 해당 파일을 전혀 사용해서는 안됩니다. 컴파일된 /app/node_modules/lib/lib.js 및 /app/node_modules/lib/lib.d.ts 있습니다.

/app/node_modules/lib/lib.ts 삭제되면 - 놀랍게도 - 잘 컴파일됩니다.

@alexeypetrushin 내 프로젝트 중 일부를 볼 수 있습니다. 잘 작동하는 것 같습니다. 예:

• https://github.com/unional/standard-log
• https://github.com/mocktomata/mocktomata

import * as pkg from '../package.json';

아니요. 그리고 내가 찾을 수있는이 오류를 끌 방법이 없습니다.

@SephReed : 저는 StackOverflow에서 200렙 포인트를 썼고 누군가 ../package.json 가져오기를 위한 이 당신이해야 할 곳입니다 typings.d.ts 같은 디렉토리에 파일을 package.json 이 내용으로, :

declare module '*.json';

나는 이것이 어떻게 작동하는지 잘 모르지만 솔직히 나는 상관하지 않는다. 그 단계에서 TS는 나를 위한 것이 아니라 스스로를 위한 것이었습니다.

이게 이렇게 열띤 토론이라니 놀랐습니다. 하지만 그 논리는 이해합니다. 저에게는 물론 소스 폴더가 있지만 컴파일을 위한 것은 아니지만 유형 지원을 확실히 포함하는 빌드 스크립트도 해당 폴더 외부에 있습니다. 솔직히 말해서 최고의 IntelliSense는 TypeScript이기 때문입니다.

repo/
⊢ config/  << provide TS support, but don't build this directory
  ⨽ webpack.config.ts 
⊢ scripts/  << provide TS support, but don't build this directory
  ⨽ release.ts
⊢ src/        << build this directory
  ⨽ example.ts
⨽ tsconfig.json

내가 사용 그래서 "rootDir": "src" 확인 파일에 지시되어 있는지 확인하기 dist 하지 dist/src . 물론 TypeScript는 이 설정에 대해 불평하는 것을 좋아하지만 Webpack을 사용하기 때문에 오류가 발생하지 않습니다.

나는 마침내 그것을 더 명확하게 하지 않는 몇 가지 코멘트 없이 이 플래그가 정확히 의미하는 바를 얻었습니다. 이것으로 응원합니다.

"files", "include", "exclude"와 같이 tsc가 컴파일을 고려할 폴더와 파일을 설정하는 옵션.

그렇다면 "rootDir"은 무엇을 위해 사용합니까?
rootDir은 소스 파일에 대한 디렉토리 구조(계층 구조)의 루트이며, tsconfig.json 디렉토리 또는 지정된 경우 "outDir"에서 시작하여 동일한 디렉토리 구조를 내보내는 데 tsc가 사용합니다. 따라서 이것은 tsc가 "outDir"의 기본 경로로 사용하는 경로가 아닙니다. "outDir"은 tsc가 출력 파일을 내보내는 루트일 뿐입니다.
예를 들어 Java 프로젝트에 이 디렉토리 구조가 있다고 가정해 보겠습니다.

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

"include"와 "rootDir"을 아래와 같이 설정하면 tsc는 다음과 같이 출력을 생성합니다.

"include": "src/main/resources/static/ts" *
"rootDir": "." *

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.js *
          test.ts

"outDir"도 아래와 같이 설정하면 tsc는 다음과 같이 출력을 생성합니다.

"include": "src/main/resources/static/ts"
"rootDir": "."
"outDir": "build" *

- build
  - src
    - main
      - resources
        - static
          - ts
            test.js *
- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

아마도 "rootDir" 옵션을 설정하고 "outDir" 옵션을 아래와 같이 변경하여 이것을 갖고 싶었을 것입니다.

"include": "src/main/resources/static/ts"
"rootDir": "src/main/resources/static/ts" *
"outDir": "src/main/resources/static/js" *

- src
  - main
    - java
    - resources
      - static
        - js
          test.js *
        - ts
          test.ts

따라서 "exclude" 옵션을 제외하고 파일의 범위를 다루지 않는 "rootDir" 옵션을 설정하면 "rootDir" 옵션의 목적에 맞지 않기 때문에 tsc가 빌드에 실패합니다.

예, 그것은 완전히 나쁜 명명 관행입니다. "rootOfStructureOfInputs"나 그 밖의 것이어야합니다. 또한 "outDir"은 "rootOfOutputs"여야 합니다.

SS에서 보는 것은 WebStorm 문제가 아니라 TS DevServer에서 발생합니다.
두 번째로 권장되는 수입품은 쓰레기입니다. "통신" 소스 폴더에서 선택합니다. 도대체 누가 그걸 원해야 하는지 모르겠습니다. 이러한 가져오기로 파일을 컴파일하면 많은 문제가 발생합니다.

나는 또한 시도했다 :

"exclude": ["lib", "node_modules",
        "..", "../..", "../../..", "../../../..", "../../../../..", "../../../../../.."
    ]

문제도 해결하지 못했다

@mhegazy 이 문제에 "의도한 대로 작동"이라는 레이블을 지정했지만 사실이 아닙니다. 내 스크린샷에서 볼 수 있듯이 tsc-server는 가져오기 제안으로 내 rootDir(이 경우 mobiservice/src) 외부의 파일을 제공합니다. 제가 보기엔 버그 같네요...