맙소사!

:+1:

네! 이는 귀하가 제공한 사용 사례에 완벽하게 부합합니다. 우리가 사용하는 도구에 코드가 사용되는 방식에 대한 더 나은 보기를 제공하는 것은 확실히 옳은 일입니다. 실수로 .d.ts 파일에 F12를 입력할 때마다 새끼 고양이를 목 졸라 죽이고 싶은 기분이 듭니다!

홍옥,

친절한 피드백을 해주시고 결정해주셔서 감사합니다. TypeScript는 매우 훌륭한 도구이며 이 기능은 엄격한 관심 분할에 의존하는 대규모 프로젝트(예: Azure Portal 또는 프로젝트 Monacos의 > 100kloc 및 많은 독립 팀이 있는 세계). 즉, 이것은 "일반인"에게 정말 도움이 될 것입니다. 또한 @NoelAbrahams (#2180)와 같은 다른 사람들이 이미 이에 대한 내용을 제안

나는 당신의 제안이 훌륭하다고 생각합니다. 내가 이제 마감한 내 제안(#3394)과 비교하여 내가 볼 수 있는 유일한 단점은 참조에 대한 대체 메커니즘이 없다는 것입니다.

여기에 자세히 설명된 다음 실제 시나리오를 고려하십시오. https://github.com/Microsoft/TypeScript/issues/3394#issuecomment -109359701

다른 프로젝트 csproj2ts에 의존하는 TypeScript 프로젝트 grunt-ts가 있습니다. grunt-ts에서 작업하는 사람은 거의 기능 범위가 매우 제한적이므로 csproj2ts에서 작업하기를 원할 것입니다. 그러나 나 같은 사람에게는 두 프로젝트를 동시에 작업하고 리팩토링/정의로 이동/모든 참조 찾기를 수행할 수 있으면 좋을 것입니다.

내 제안을 할 때 종속성 개체가 명명된 폴백이 있는 개체 리터럴이 되도록 제안했습니다. 귀하의 제안에 더 부합하는 버전은 다음과 같습니다.

"dependencies": {
   "csproj2ts": ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "SomeRequiredLibrary": "../SomeRequiredLibraryWithNoFallback"
}

여전히 배열이 되도록 단순화하기 위해 grunt-ts tsconfig.json 파일의 미래 가상 dependencies 섹션의 다음 대체 구현을 제안합니다.

"dependencies": [
   ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "../SomeRequiredLibraryWithNoFallback"
]

dependencies 각 배열 유형 항목에 대한 해결 규칙은 다음과 같습니다. 각각에서 발견된 _first_ 항목이 사용되는 항목이고 나머지는 무시됩니다. 문자열 유형 항목은 Jonathan의 제안서에 명시된 대로 처리됩니다.

이것은 구현하기가 약간 더 복잡한 솔루션이지만 개발자(및 라이브러리 작성자)에게 훨씬 더 큰 유연성을 제공합니다. csproj2ts에서 개발할 필요가 없는(따라서 ../csproj2ts/tsconfig.json 파일이 없는) 개발자의 경우 종속성은 컴파일 컨텍스트에 추가되는 정의 파일일 뿐입니다. ../csproj2ts/tsconfig.json 파일이 있는 _do_ 개발자의 경우 제안서는 위에서 설명한 대로 정확하게 작동합니다.

위의 예에서 "../SomeRequiredLibraryWithNoFallback" 는 기존 제안에서와 같이 있어야 하며, 없는 것은 컴파일러 오류입니다.

고려해 주셔서 감사합니다.

여기에서 분리해야 하는 두 가지 문제가 있습니다. 빌드가 있고 언어 서비스 지원이 있습니다.

Build의 경우 tsconfig가 여기에 적합하지 않다고 생각합니다. 이것은 분명히 빌드 시스템 문제입니다. 이 제안과 함께 typescript 컴파일러는 다음과 같은 비즈니스에 있어야 합니다.

• 의존성 파악
• 주장에 대한 최신 확인
• 구성 관리(릴리스 대 디버그)

이것들은 모두 빌드 시스템의 책임입니다. 이것은 어려운 문제이며 MSBuild, grunt, gulp 등과 같이 이미 이를 수행하는 도구가 있습니다.
tsconfig 및 tsc가 빌드 드라이버가 되면 모든 CPU를 사용하여 관련 없는 하위 트리를 빌드하거나 각 프로젝트에 대해 사후 및 사전 빌드 명령을 사용하고 다른 프로젝트도 빌드할 수 있습니다. 다시 말하지만, 그들이 하는 일을 잘하는 빌드 도구가 있고 우리가 그것을 다시 만들 필요가 없다고 생각합니다.

언어 서비스의 경우,
도구가 여러 tsconfig 파일에 대해 알고 있고 이를 통해 추론하고 더 많은 도움을 줄 수 있지만 빌드에는 영향을 미치지 않아야 한다고 생각합니다. 나는 다음과 같은 것을 고려할 것입니다 :

"files" : [
    "file1.ts",
    {
        "path": "../projectB/out/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

여기서 tsc는 "경로"만 볼 수 있지만 도구는 다른 정보를 보고 최대한 도움이 되도록 노력할 수 있습니다.

나는 문제의 존재를 인정하지만 일괄 빌드 및 툴링이 올바른 해결책이라고 생각하지 않습니다. tsconfig.json은 구성 백(즉, 응답 파일에 대한 json 대안)으로 남아 있어야 하며 빌드 시스템이 되지 않아야 합니다. 하나의 tsconfig.json은 단일 tsc 호출을 나타냅니다. tsc는 단일 프로젝트 컴파일러로 유지되어야 합니다.

VS의 MSBuild 프로젝트는 빌드 시스템을 사용하여 IDE 기능을 빌드하는 예이며 이제 ppl은 너무 커서 만족하지 않습니다.

답변 감사합니다, 모하메드. 내가 이해했는지 확인하기 위해 다시 말하겠습니다.

• 다중 프로젝트 빌드를 조정하는 작업은 전용 빌드 도구의 영역으로 남아 있어야 한다고 생각합니다.
• TypeScript 언어 서비스에 대한 이 제안에 무언가가 있을 수 있다고 생각합니다.
• 이 tsconfig.json 에서 tsc --project 를 실행하는 것은 tsc file1.ts ../project/out/project.d.ts 를 실행하는 것과 같다고 생각합니다. 그러나 TypeScript 언어 서비스를 사용하여 VS 또는 다른 편집기에서 이러한 프로젝트를 열면 "정의로 이동"이 개발자를 기능이 정의된 _실제 TypeScript 파일_으로 가져올 수 있습니다( projectB.d.ts 의 정의가 아님).

나에게 그런 권리가 있습니까?

그렇다면 이것은 매우 공정하다고 생각합니다. 내 원래 제안(https://github.com/Microsoft/TypeScript/issues/3394)에서 내 아이디어가 출력될 위치에서 방출된 결과를 복사하는 단계가 포함되지 않았기 때문에 내 아이디어가 불완전하다고 말했습니다. 참조 라이브러리에서 런타임 시 참조 라이브러리가 예상하는 위치로 이동합니다. "정말 필요한 것은 언어 서비스 지원인데 왜 중간에 건물을 짓느냐"고 말하는 것 같아요.

귀하의 예에서 데이터를 약간 변경하려면 이와 같은 것을 지원하시겠습니까?

"files" : [
    "file1.ts",
    {
        "path": "externalLibraries/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

현재 프로젝트는 기본적으로 사용되는 projectB에 대한 정의와 함께 제공되지만 projectB에 대한 실제 소스를 사용할 수 있는 경우 실제 소스가 대신 사용된다고 가정합니다.

@nycdotnet 당신은 그것을 올바르게 요약했습니다. 나는 느슨하게 결합되고 다른 IDE와 다른 빌드 도구를 혼합하고 일치시킬 수 있지만 여전히 훌륭한 디자인 시간 경험을 얻을 수 있는 시스템을 만들고 싶습니다.

잘 들린다!

나는 @mhegazy에 동의하고 실제로 TypeScript가 스스로를 '컴파일러'로 생각하는 것을 멈추고 스스로를 '유형 검사기' 및 '트랜스파일러'로 생각하기 시작하는 것이 중요하다고 생각합니다. 이제 단일 파일 변환 지원이 있습니다. 런타임/번들링을 제외하고 컴파일된 JavaScript 파일이 생성될 이유가 없습니다. 또한 실제 typescript 소스를 사용할 수 있을 때 유형 검사 중에 외부 참조 정의를 생성해야 하는 이유도 모르겠습니다.

파일 및 패키지 해석은 사용 중인 빌드 시스템(browserify, systemjs, webpack 등)의 책임이므로 언어 ​​서비스가 작동하려면 빌드 시스템/플랫폼과 동일한 방식으로 파일을 해석할 수 있어야 합니다. 사용하고 있습니다. 이는 각 빌드 시스템에 대해 사용자 지정 LanguageServicesHost를 구현하거나 tsconfig.json에 올바른 매핑 항목을 생성하는 도구를 제공하는 것을 의미합니다. 둘 중 하나는 허용됩니다.

@nycdotnet 여러 대체 경로에 대한 사용 사례가 npm link ../csproj2ts 사용하여 더 잘 처리될 것이라고 생각합니까?

나는 컴파일러/트랜스파일러와 별도로 빌드를 유지해야 한다는 @mhegazy에 동의합니다. 섹션에 *.ts 파일이 나열되지 않으면 여전히 파일을 검색한다는 가정하에 tsconfig -> tsconfig 종속성을 파일 섹션에 포함하고 싶습니다. 예

"파일": [
{
"경로": "externalLibraries/projectB.d.ts",
"sourceProject": "../projectB/"
}
]

tsconfig.json 파일이 포함된 디렉토리 및 하위 디렉토리에 있는 모든 ts 파일은 계속 포함됩니다.

@dbaeumer 그런 다음 다른 속성에 갖고 싶습니까? 현재 파일이 정의되어 있으면 항상 사용되며 include *.ts 부분은 무시합니다.

@mhegazy 반드시 다른 섹션은 아니지만 결국에는 상황이 더 명확해집니다. 내가 피하고 싶은 것은 tsconfig -> tsconfig 종속성을 사용하는 경우 모든 파일을 강제로 나열하는 것입니다. 위의 예에서는 컴파일러에 제공하기 위해 *.ts 파일을 나열하지 않고 싶습니다.

이것이 많이 필요하다고 생각합니다. 그러나 빌드 질문을 피할 수는 없다고 생각합니다. 이것은 우리가 이 제안과 함께 빌드 시스템을 구현해야 한다는 것을 의미하지는 않지만 제안된 것과 같은 구성에서 작동하는 몇 가지 좋은 지침을 생각했어야 했습니다. 올바르게 하는 것은 쉽지 않을 것입니다(Visual Studio용으로 해결해야 합니다).

위의 제안에서(.d.ts와 소스가 모두 참조되는 경우) .d.ts가 오래된 것인지(즉, 다시 빌드해야 하는지) 감지합니까? Refactor/Rename과 같은 작업은 프로젝트 전체에서 작동합니까(즉, 다음 빌드를 덮어쓰게 될 .d.ts 파일뿐만 아니라 참조된 프로젝트 소스의 이름을 업데이트함)? GoToDef를 사용하면 참조된 프로젝트의 원본 코드(전체 프로젝트의 거대한 .d.ts 파일 중간이 아님)로 이동합니까? 이는 참조된 프로젝트의 소스를 해결하고 경우에 따라 분석할 필요가 있음을 의미하는 것 같습니다. 어떤 경우에 .d.ts가 유용한가요?

오늘날 우리가 가지고 있는 일반 솔루션은 한 프로젝트의 빌드 출력으로 .d.ts를 갖고 다른 프로젝트에서 입력으로 참조됩니다. 이것은 빌드에 잘 작동하므로 변경할 필요가 없습니다.

문제는 편집 시나리오다. 편집하는 동안 생성된 파일을 살펴보고 싶지 않습니다. 내가 제안한 솔루션은 생성된 .d.ts의 출처에 대한 "힌트"를 제공하는 것입니다. 그러면 언어 서비스는 .d.ts를 로드하지 않고 대신 힌트 경로에서 "프로젝트"를 로드합니다. 이 방법으로 goto def는 .d.ts 대신 구현 파일로 이동하며 마찬가지로 컴파일 없이도 오류가 작동합니다.

이름 바꾸기와 같은 작업은 한 프로젝트에서 다른 프로젝트로 "전파"하고 유사하게 참조를 찾습니다.

오늘날에는 TS가 파일을 읽고 구문 분석하기 위한 API를 제공하지만 tsconfig.json 파일을 찾는 것은 전적으로 호스트(IDE 등)에 달려 있습니다. 계층적 방식으로 여러 tsconfig.json이 있는 경우 이 작업을 어떻게 상상할 수 있습니까? 호스트는 여전히 초기 파일을 해석할 책임이 있지만 다른 파일은 해석하지 않습니까? 아니면 호스트가 모든 tsconfig를 해석할 책임이 있습니까?

편의성/관습과 유연성 사이에 절충점이 있는 것 같습니다.

이것은 #2568에 설명된 대로 d.ts 파일을 빌드하는 기능으로 시작되지 않습니까(또는 최소한 상대 가져오기가 있어야 함)?

@spion 여기에 종속성이 있는지 확실하지 않습니다. 프로젝트의 여러 출력을 가질 수 있지만 단일 선택 파일이 아닙니다. 빌드 시스템은 이를 알고 종속 프로젝트에 대한 입력으로 연결할 수 있어야 합니다.

@mhegazy 죄송합니다. 문제를 다시 보면 이는 언어 서비스와 더 관련이 있는 것으로 보입니다. 나는 다음을 읽었다

• 중간 규모 프로젝트: 표준 빌드 및 공유 구성 요소가 있는 프로젝트

프로젝트의 일부가 외부 모듈인 npm/browserify(또는 webpack) 빌드 워크플로에 대한 더 나은 지원과 관련이 있다고 자동으로 가정합니다.

AFAIK 아직 외부 모듈용 .d.ts 파일을 생성할 방법이 없습니까? 그렇다면 언어 서비스가 외부 모듈을 가져오는 프로젝트를 연결할 수 있는 유일한 방법은 tsconfig.json에 다음과 같은 내용을 포함하는 것입니다.

{ 
  "provides": "external-module-name"
}

프로젝트가 다른 tsconfig.json 에서 참조될 때 LS에 알립니다.

AFAIK 아직 외부 모듈용 .d.ts 파일을 생성할 방법이 없습니까?

나는 이것이 사실이라고 생각하지 않는다. tsc --m --d 호출하면 외부 모듈 자체인 선언 파일이 생성됩니다. 해결 논리는 .ts를 찾으려고 시도하고 그렇지 않은 경우 동일한 이름의 .d.ts를 찾습니다.

@spion 타이프 라이터는 @mhegazy 말했듯이 외부 모듈 d.ts 파일을 생성 할 수 있지만 1에서이 결과 : 도서관의 타이프 라이터의 정의는 일반적으로 소비하는 방법과 다른 소스 파일에 정의 1의 비율. 이 문제를 해결하는 한 가지 방법은 다음 TypeStrong 라이브러리입니다. https://github.com/TypeStrong/dts-bundle

@mhegazy 죄송합니다. "주변 외부 모듈"을 의미했습니다. 즉 TypeScript에 external-module-name 를 쓰고 다른 모듈에서 해당 클래스 중 하나를 가져오는 경우입니다.

import {MyClass} from 'external-module-name'

'external-module-name' 를 선언하는 적절한 .d.ts 파일을 tsc 생성할 수 있는 방법이 없습니다.

@nycdotnet dts-bundle 및 dts-generator 를 알고 있지만 여전히 언어 서비스가 내 다른 프로젝트의 소스에 대해 알아야 하는 경우 가져오기를 올바르게 추적할 수 있도록 제공하는 모듈 이름도 알아야 합니다.

이 기능의 상태는 무엇입니까? 이것은 중간 규모 프로젝트에 중요한 옵션인 것 같습니다. 특정 "requirejs" 구성으로 다른 폴더에 소스가 있는 프로젝트를 어떻게 구성합니까?

@llgcode https://github.com/Microsoft/TypeScript/issues/5039 를 살펴보십시오. typescript@next 에서 사용할 수 있습니다.

중간 규모 프로젝트에 필요한 대로 하위 프로젝트를 컴파일하는 작업으로 gulpfile을 작성하는 것이 그렇게 어려운지 잘 모르겠습니다. 소규모 프로젝트에서도 이 작업을 수행합니다. 내가 tsconfig.json을 사용하는 유일한 이유는 VS Code 때문입니다.

먼저 꿀꺽꿀꺽 사용하지 않습니다. 두 번째로 이것은 매번 재컴파일하고 싶지 않은 큰 프로젝트가 될 수 있습니다. 그러나 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시는 좋은 해결책이 있다면이를 수행하는 방법을 알려주십시오.

@llgcode 글쎄, gulp.task() 하여 원하는 만큼 작업을 정의하는 gulpfile.js를 작성합니다. 작업 내에서 gulp.src() 로 입력 파일 스트림을 가져온 다음 컴파일, 연결, 축소, 소스 맵, 자산 복사와 같은 변환 파이프라인을 통해 .pipe() 할 수 있습니다. 노드 및 NPM 모듈로 가능한 모든 작업을 수행하십시오.
여러 프로젝트를 컴파일해야 하는 경우 이 작업을 수행하는 작업을 정의하기만 하면 됩니다. 여러 tsconfig.json을 사용하려는 경우 gulp -typescript 가 이를 지원하거나 json 파일을 읽을 수 있습니다. 증분 빌드도 가능합니다. 다른 저장소에 있고 하위 모듈을 사용하는 경우 프로젝트가 어떻게 구성되어 있는지 모르겠습니다. 그러나 꿀꺽 꿀꺽 꿀꺽 꿀꺽꿀꺽하는 것은 100% 유연합니다.

좋아요 감사합니다 훌륭한 도구인 것 같습니다. require("mylibs/lib")와 같은 매핑이 필요하고 내 파일이 예를 들어 project/src/lib.js 폴더에 있으면 완성이 원자에서 작동하지 않고 typescript 또는 gulp가 해결되는 방법을 모르겠습니다. 매핑/구성은 "mylibs" 및 로컬 경로로 수행됩니다. 그래서 #5039에 있는 이 새로운 옵션 경로가 이 문제에 대한 좋은 해결책이라고 생각합니다.

@llgcode gulp를 사용하면 glob이 포함된 모든 파일(.d.ts 파일 포함)을 얻을 수 있습니다( https://www.npmjs.com/package/gulp-typescript#resolve -files 참조).

TypeScript가 여기에서 많은 일을 하려고 한다고 생각합니다. 이것은 빌드 도구가 아니라 트랜스파일러입니다. 제안서에 언급된 "종속성"을 관리하는 것은 실제로 패키지 관리자 또는 버전 제어 시스템의 작업이며 이들을 함께 연결하는 것은 빌드 도구의 작업입니다.

@felixfbecker 동의하지 않습니다. 내가 아는 모든 컴파일러(유형 검사 포함)에는 이와 같은 옵션이 있습니다. 예를 들어:
gcc -> 파일 포함
자바 -> 클래스 경로 및 소스 경로
이동 -> GOPATH
파이썬 -> 파이썬 패스
컴파일러/트랜스파일러는 트랜스파일되어야 하는 소스 파일이 무엇인지 알아야 합니다. 어떤 소스 파일이 단지 include/lib 파일인지 알아야 합니다.
파일이 변경되었을 때 무엇을 해야 하는지 알기 위해서는 gulp와 같은 빌드 도구가 필요합니다.

@llgcode 에 동의합니다. 또한 TypeScript는 컴파일러로 노출하는 것 외에도 IDE에 구문 강조 표시(실제로 감지) 및 완성 기능을 제공하는 언어 서비스로 노출합니다. 그리고 그것은 또한 의존성 트리를 걸어야 합니다.

@llgcode @unional 유효 포인트. 또한 도움이 될 수 있는 한 가지는 tsconfig.json의 files 속성이 glob을 허용하도록 하여 포함하려는 모든 폴더의 모든 파일을 정의할 수 있도록 하는 것입니다. 그러나 나는 당신이 어디에서 왔는지, 왜 더 큰 프로젝트에 여러 tsconfig.json이 필요한지 알 수 있습니다.

CommonJS용 AFAIK는 node_modules 및 npm link ../path/to/other-project 를 통해 이미 지원됩니다.

npm 링크는 프로젝트에서 라이브러리 재사용을 시작하자마자 작동하지 않습니다. 두 개의 별도 프로젝트 간에 공통 라이브러리를 사용하는 경우(rxjs를 예로 들자면) typescript는 'Observable을 Observable에 할당할 수 없습니다'라고 알려줍니다. 이는 포함 경로가 동일한 라이브러리임에도 불구하고 두 개의 다른 node_modules 폴더에 대한 심볼릭 링크 폴더를 따르기 때문입니다. 해결 방법은 기본적으로 대규모 프로젝트 옵션으로 돌아가는 gulp 작업 또는 로컬/개인 npm 리포지토리를 빌드하는 결과를 가져옵니다.

@EricABC 아마도 앰비언트 외부 모듈 선언을 사용하기 때문일 것입니다. 이 경우 새로 지원되는 node_modules 기반 .d.ts 파일에 대한 정의도 포함해야 합니다. 그 외에는 TS 유형이 구조적으로만 확인되기 때문에 문제가 없어야 하므로 구조가 일치하는 한 다른 모듈에서 오든 다른 이름을 가지든 상관 없습니다.

@spion 감사합니다. 파일 기반이라고 가정

또한 도움이 될 수 있는 한 가지는 tsconfig.json의 files 속성이 glob을 허용하도록 하는 것입니다...

토론 중인 include 속성이 있습니다.

질문 및 의견:

• dependencies 는 tsc가 허용 하기 때문에 전체 tsconfig.json 경로를
• files 이미 있고 괜찮은데 새 키워드( dependencies )를 도입하는 이유는 무엇입니까?
  예시:

{
    "compilerOptions": {
        // ...
    },
    "files": [
        "../common/tsconfig.json", // <== takes the `files` part of the tsconfig.json
        "../common/tsconfig.util.json", // <==
        "core.ts",
        "sys.ts"
    ]
}

• 종속성 tsconfig.json이 compilerOptions 도 지정하면 어떻게 됩니까?

더 멀리/야생적으로 :-) 그리고 가능하면 (미래에) compilerOptions , exclude ... 가 다른 tsconfig.json을 참조하도록 허용합니다.

// File app/tsconfig.json
{
    "compilerOptions": "../common/tsconfig.compilerOptions.json",
    "files": [
        "../common/tsconfig.json",
        "../common/tsconfig.util.json",
        "core.ts",
        "sys.ts"
    ],
    "exclude": "../common/exclude.json"
}

// File ../common/tsconfig.compilerOptions.json
{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "sourceMap": true
    }
}

// File ../common/exclude.json
{
    "exclude": [
        "node_modules",
        "wwwroot"
    ]
}

// File ../common/tsconfig.util.json
{
    "files": [
        "foo.ts",
        "bar.ts"
    ]
}

files , compilerOptions , exclude ... 논리가 있습니다. 다른 tsconfig.json 파일을 참조할 수 있으며 다른 tsconfig에서 일치하는 키워드 부분만 "가져옵니다" .json 파일 => 쉽고 확장 가능합니다. 따라서 원하는 경우 tsconfig.json을 여러 파일로 분할하여 재사용할 수 있습니다.

토론의 일부를 읽으면 이 "언어 서비스"/goto 정의를 올바르게 얻는 것과 가장 관련이 있습니다. JavaScript 디버거는 sourceMaps를 사용합니다. 이제 tsc가 .js뿐만 아니라 .d.ts 파일에서도 sourceMap 데이터를 생성했다면...

그 외에는 tsconfig.json 파일 내에서 자식 프로젝트의 빌드를 트리거하는 데 큰 이점이 없습니다. 이러한 기본적인 빌드 시간 종속성이 필요한 경우 간단한 셸 스크립트가 작업을 수행합니다. 반면에 지능형 점진적 구축이 필요한 경우 제안된 접근 방식이 너무 단순해 보입니다. 많은 시나리오에서 tsc는 다른 것들 사이에서 단지 하나의 빌드 단계로 끝납니다. tsconfig.json에서 tsc에 대한 종속성을 작성하지만 나머지 파일에 대해서는 다른 파일을 작성하는 것이 얼마나 이상한가요? 다시 말하지만, tsc가 쉘 스크립트가 수행할 수 있는 유일한 빌드 단계인 간단한 작업을 위해.

어쨌든, .js 파일에서처럼 .d.ts 파일에서 소스 매핑을 생성하는 것은 어떻습니까?

우리는 단순히 노드 모듈 + npm 링크를 사용합니다. 작동하지 않는 유일한 것은 moduleResolution: node가 인라인/트리 쉐이킹 최적화를 활성화하는 ES6 모듈과 호환되지 않는다는 것입니다( #11103 참조).

주제를 벗어나는 것이 아니라 어떤 면에서 이것은 여러 노드 패키지 프로젝트를 로컬에서 작업하는 문제와 평행을 이루는 것처럼 보입니다. "npm link"를 사용하는 것만큼 간단하지 않다고 생각합니다. 그들은 다른 빌드 스크립트를 가질 수 있습니다. 올바른 순서로 모든 스크립트를 실행해야 합니다. 점진적으로 수행하기가 더 어렵습니다. 감시 모드를 사용하기가 더 어렵습니다. 디버그하기가 더 어렵고 소스 맵을 해결하기가 더 어렵습니다. 선택한 편집자에 따라 훨씬 더 어려울 수 있습니다.

일반적으로 저는 그냥 포기하고 하나의 거대한 프로젝트에 모든 것을 넣은 다음 안정화되면 별도의 패키지로 나눕니다. 그러나 문제에 덜 자주 직면하기 때문에 도움이 될 뿐입니다. 나는 전체 경험이 정말 정말 짜증난다. 내가 뭔가를 놓치고 있습니까?

그래서 이것이 무엇이든간에, 마침내 전체 개발 경험에 대한 우아한 솔루션을 가질 수 있기를 바랍니다.

이것이 우리의 일상 업무에 좋을 것이라는 점에서 차임!

웹 개발의 특성으로 인해 각 프로젝트에는 단일 js 파일( --outFile )로 컴파일된 여러 ts 파일이 포함된 여러 ts 프로젝트가 있습니다. 이들은 앱과 유사한 프로젝트(특정 작업을 수행하거나 특정 기능을 추가함) 또는 lib와 같은 프로젝트(앱에 재사용 가능한 코드)입니다. 종종 우리는 이러한 ts-projects 중 여러 개를 동시에 작업하여 앱 개발을 용이하게 하기 위해 라이브러리를 개선합니다. 하지만 내 동료 개발자 중 어느 누구도 언제든지 로컬 환경에 모든 ts-projects를 가지고 있다고 생각하지 않습니다.

워크플로를 개선하기 위해 현재 옵션은

• 1 ts 프로젝트에 모든 것을 던지십시오.
  
  
  
  • .ts 파일을 직접 참조할 수 있습니다. 이는 d.ts 파일을 사용하는 것보다 훨씬 좋습니다.
  
  
  • 그러나 앱(기능 또는 페이지별)의 모듈성을 유지하면서 인터웹을 통해 요청된 js 파일을 제한해야 하기 때문에 파일 세트를 매핑하고 연결하기 위한 외부 도구가 필요합니다.
  
  
  • 언급했듯이 이러한 모든 ts-projects가 항상 모든 사람에게 필요한 것은 아니므로 파일 시스템에 많은 팽창이 추가됩니다. 프로젝트 X에서 작업하는 누군가는 프로젝트 A, B, D가 필요할 수 있지만 Y에서 작업하는 누군가는 A와 C가 필요할 수 있습니다.
  
  
• 프로젝트 분리 유지(현재 상황)
  
  
  
  • .ts 파일을 직접 포함하면 출력에 추가되므로 다른 ts-projects에서 컴파일된 d.ts 파일을 참조해야 합니다. 우리 자신의 소스 코드에 직접 f12를 입력할 수 있다면 훨씬 더 빠를 것입니다.
  
  
  • 그리고 이러한 프로젝트를 동시에 여러 개 컴파일하려면 도구/스크립트를 추가해야 합니다. 현재 우리는 여러 터미널에서 tsc -d -w 명령을 시작하거나 tsconfig가 있는 모든 하위 디렉토리에 대해 이를 수행하는 스크립트를 실행합니다.
  
  
  • 다른 도구(예: 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시면서 도움이 될 수 있음) 또는 tsconfigs의 파일 globs로 무언가를 알아낼 수 있다는 것을 이해하지만 d.ts 파일의 첫 번째 문제에는 도움이 되지 않습니다.
  
  

우리 프로젝트는 단순히 라이브러리의 개발을 앱과 엄격하게 분리할 만큼 크지는 않지만 모든 것을 함께 던질 수 있을 만큼 작지는 않습니다. 우리는 typescript에 우아한 옵션이 부족하다는 것을 알게 되었습니다.

dependencies 가 최고의 옵션이 될 수 있다면 정말 대단할 것입니다. 의 기능종속성의 모든 ts 파일에 태그를 추가하지만 해당 종속성의 자체 tsconfig에 따라 출력을 컴파일합니다.

이 주제에 대한 업데이트가 있습니까? 어떻게 서로 독립적으로 컴파일되는 여러 타입스크립트 프로젝트를 가질 수 있습니까? tsconfig.json에서 이러한 종속성을 어떻게 설명할 수 있습니까?

이것은 이제 "프로젝트 참조 지원"이라는 제목의 향후 섹션의 로드맵에 포함됩니다. 따라서 .tsconfig 파일은 다른 .tsconfig 파일을 종속성으로 연결할 수 있다고 생각합니다.

이 주제에 대한 업데이트가 있습니까? 어떻게 서로 독립적으로 컴파일되는 여러 타입스크립트 프로젝트를 가질 수 있습니까? tsconfig.json에서 이러한 종속성을 어떻게 설명할 수 있습니까?

빌드 종속성은 빌드 시스템에서 인코딩되어야 합니다. gulp, grunt, broccoli, msbuild, basal 등과 같은 빌드 시스템은 이러한 경우를 처리하기 위해 구축되었습니다.
유형 정보의 경우 한 프로젝트의 출력에 .d.ts가 포함되어야 하며 다른 프로젝트에 입력으로 전달되어야 합니다.

@mhegazy 우리 프로젝트는 다음과 같이 작동합니다. 우리는 lerna monorepo에서 패키지의 번호를 가지고, 각 패키지는 package.json에서 자신의 종속성과의 그 같은 의존성이 "types" 자신의 재산 tsconfig.json . 각 프로젝트는 --outFile (아직 ES 모듈로 이동하지 않은 이전 프로젝트임)로 컴파일되며 "typings" package.json 키는 번들된 .d.ts 가리킵니다.

우리는 묶음/보기를 위해 꿀꺽 꿀꺽 꿀꺽 꿀꺽 사용합니다.

대부분의 경우 작동하지만 몇 가지 문제가 있습니다.

• #15488 및 #15487과 같은 문제로 인해 참조가 올바르게 작동하려면 명시적 링크가 필요합니다.
• Go-to-definition은 번들 .d.ts 파일로 이동합니다. 이상적으로는 다른 프로젝트의 소스로 이동합니다.
• 전체 빌드를 수행하는 가장 빠른 방법은 lerna run build --sort (각 디렉토리에서 효과적으로 tsc )입니다. 이는 각 패키지에 대해 하나의 TypeScript 컴파일러 프로세스를 생성하여 많은 반복 작업을 수행하기 때문에 추가 오버헤드가 있습니다. .

우리도 다른 사람들이 설명한 것과 같은 상황에 있기 때문에 이 문제를 면밀히 주시하고 있습니다.
각각의 tsconfig.json 파일이 있는 여러 "프로젝트".

@mhegazy가 지적한 것처럼 빌드 프로세스가 작동합니다. 각 프로젝트는 .d.ts 파일을 내보내고 이 파일 은

진짜 문제는 IDE 지원입니다. 참조를 찾을 때 단일 tsconfig.json 범위 내에서만 참조를 찾을 수 있습니다. 더 나쁜 것은 tsconfig.json 범위를 벗어난 종속 파일이 다시 컴파일되지 않기 때문에 변경된 파일의 계단식 효과가 프로젝트 간에 전파되지 않는다는 것입니다. 이것은 우리 프로젝트의 유지 관리에 매우 좋지 않으며 때때로 IDE에서 잡을 수 있는 빌드 오류를 유발합니다.

맙소사

내가 갖고 싶은 업데이트된 시나리오에는 React 구성 요소가 포함됩니다. 우리 회사의 모든 응용 프로그램에 적절한 UI 구성 요소를 렌더링하는 JSX 모듈(원자, 분자 및 유기체)이 포함된 구성 요소 저장소가 있습니다. 이 구성 요소 저장소는 개별 응용 프로그램에서 작업할 때 모든 프런트 엔드 개발자가 사용합니다. 특정 응용 프로그램의 UI를 편집하고 공통 UI 구성 요소 저장소로 "정의로 이동"할 수 있는 TypeScript 언어 서비스 경험이 있다면 정말 좋을 것입니다. 오늘날 우리는 이러한 구성 요소를 개별적으로 번들로 묶어 복사해야 합니다. 이것은 내가 수정되었으면 하는 "자신의 프로젝트 배관 만들기" 문제입니다(.NET 세계에는 솔루션 아래에 있는 프로젝트가 있는 아주 좋은 이야기가 있습니다).

프로젝트 참조: TypeScript의 기본 제공 확장성

소개

TypeScript는 수십만 줄의 프로젝트로 확장되었지만 기본적으로 이러한 종류의 확장을 기본 제공 동작으로 지원하지 않습니다. 팀은 다양한 효율성의 해결 방법을 개발했으며 대규모 프로젝트를 나타내는 표준화된 방법은 없습니다. 시간이 지남에 따라 typechecker의 성능이 크게 향상되었지만 TS가 합리적으로 얻을 수 있는 속도 측면에서 여전히 어려운 제한이 있습니다.
언어 서비스가 대화형 시나리오에서 "무한하게" 확장되는 것을 방지하는 32비트 주소 공간과 같은 제약 조건이 있습니다.

직관적으로 프론트 엔드 구성 요소에서 JSX의 한 줄을 변경하는 경우 500,000 LOC 프로젝트의 전체 핵심 비즈니스 논리 구성 요소를 다시 유형 검사할 필요가 없습니다 . 프로젝트 참조 의 목표는 개발자에게 코드를 더 작은 블록으로 분할 할 수 있는 도구를 제공하는 것입니다. 도구가 한 번에 더 작은 작업 단위로 작동할 수 있도록 함으로써 응답성을 개선하고 핵심 개발 루프를 강화할 수 있습니다.

우리는 현재 아키텍처에 성능이나 메모리 소비의 급격한 개선 측면에서 "무료 점심"이 거의 남아 있지 않다고 생각합니다. 대신, 이 분할은 일부 선행 작업을 희생시키면서 속도를 높이는 명시적인 절충안 입니다. 개발자는 시스템의 종속성 그래프에 대해 추론하는 데 시간을 할애해야 하며, 도구를 추가로 개선할 때까지 특정 대화형 기능(예: 프로젝트 간 이름 변경)을 사용하지 못할 수 있습니다.

이 시스템에 의해 부과된 주요 제약 조건을 식별하고 프로젝트 크기, 디렉터리 구조 및 빌드 패턴에 대한 지침을 설정합니다.

시나리오

고려해야 할 세 가지 주요 시나리오가 있습니다.

관련 모듈

일부 프로젝트는 상대 가져오기를 광범위하게 사용합니다. 이러한 가져오기는 디스크의 다른 파일로 명확하게 확인됩니다. ../../core/utils/otherMod 와 같은 경로는 일반적으로 찾을 수 있지만 이러한 저장소에서는 일반적으로 더 평평한 디렉토리 구조가 선호됩니다.

예시

다음은 Khan Academy의 페르세우스 프로젝트의 예입니다.

https://github.com/Khan/perseus/blob/master/src/components/graph.jsx 에서 수정

const Util = require("../util.js");
const GraphUtils = require("../util/graph-utils.js");
const {interactiveSizes} = require("../styles/constants.js");
const SvgImage = require("../components/svg-image.jsx");

관찰

디렉토리 구조는 프로젝트 구조를 의미 하지만 반드시 확정적인 것은 아닙니다. 위의 Khan Academy 샘플에서 은 util , styles 및 components 가 자신의 프로젝트일 것이라고 추론할 수 있습니다. 그러나 이러한 디렉토리가 매우 작아 실제로 하나의 빌드 단위로 그룹화될 수도 있습니다.

모노레포

모노 리포지토리는 상대가 아닌 경로를 통해 가져온 여러 모듈로 구성됩니다. 하위 모듈(예: import * as C from 'core/thing )에서 가져오는 것이 일반적일 수 있습니다. 일반적으로 항상 그런 것은 아니지만 각 루트 모듈은 실제로 NPM에 게시됩니다.

예시

https://github.com/angular/angular/blob/master/packages/forms/src/validators.ts 에서 수정

import {InjectionToken, ɵisObservable as isObservable, ɵisPromise as isPromise} from '@angular/core';
import {forkJoin} from 'rxjs/observable/forkJoin';
import {map} from 'rxjs/operator/map';
import {AbstractControl, FormControl} from './model';

관찰

나눗셈의 단위는 반드시 모듈 이름의 선두 부분일 필요는 없습니다 . 예를 들어 rxjs 는 범위가 지정된 패키지(예: @angular/core )와 마찬가지로 실제로 하위 파트( observable , operator )를 별도로 컴파일합니다.

아웃파일

TypeScript는 입력 파일을 단일 출력 JavaScript 파일로 연결할 수 있습니다. 참조 지시문 또는 tsconfig.json의 파일 순서는 결과 파일에 대한 결정적 출력 순서를 생성합니다. 이것은 새 프로젝트에는 거의 사용되지 않지만 이전 코드베이스(TypeScript 자체 포함)에서는 여전히 널리 사용됩니다.

예시

https://github.com/Microsoft/TypeScript/blob/master/src/compiler/tsc.ts

/// <reference path="program.ts"/>
/// <reference path="watch.ts"/>
/// <reference path="commandLineParser.ts"/>

https://github.com/Microsoft/TypeScript/blob/master/src/harness/unittests/customTransforms.ts

/// <reference path="..\..\compiler\emitter.ts" />
/// <reference path="..\harness.ts" />

관찰

이 구성을 사용하는 일부 솔루션은 별도의 script 태그(또는 이에 상응하는 태그)를 통해 각 outFile 를 로드하지만 다른 솔루션(예: TypeScript 자체)은 모놀리식 출력을 구축하기 때문에 이전 파일을 연결해야 합니다. .

프로젝트 참조: 새로운 격리 단위

실제 프로젝트와의 상호 작용에서 얻은 몇 가지 중요한 관찰:

• TypeScript는 일반적으로 구현(비.d.ts) 코드의 50,000 LOC 미만의 프로젝트를 확인할 때 "빠른"(< 5-10초)입니다.
• .d.ts 파일, 특히 skipLibCheck 아래의 파일은 유형 검사 및 메모리 비용 측면에서 거의 "무료"입니다.
• 거의 모든 소프트웨어는 50,000 LOC보다 작은 구성 요소로 세분될 수 있습니다.
• 거의 모든 대형 프로젝트는 이미 적당한 크기의 하위 구성 요소를 생성하는 방식으로 디렉토리별로 파일을 구조화합니다.
• 대부분의 편집은 전체 솔루션을 다시 확인하거나 다시 내보낼 필요가 없는 리프 노드 또는 니어 리프 노드 구성 요소에서 발생합니다.

이것들을 종합하면, 구현 코드의 50,000 LOC 청크 하나만 한 번에 유형 검사할 수 있다면 대화형 시나리오에서 "느린" 상호 작용이 거의 없고 메모리가 거의 부족하지 않을 것입니다.

종속 단위의 구현 코드가 확인 되지 않는 두 TypeScript 컴파일 단위 간에 새로운 종류의 종속성을 선언하는 프로젝트 참조 라는 새로운 개념을 도입했습니다. 대신에 결정적 위치에서 .d.ts 출력을 로드하기

통사론

새로운 references 옵션(TODO: Bikeshed!)이 tsconfig.json 추가되었습니다.

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "outDir": "../bin",
    "references": [
      { "path": "../otherProject" }
    ]
  }
}

references 배열은 이 프로젝트에서 참조할 다른 프로젝트 세트를 지정합니다.
각 references 개체의 path 는 tsconfig.json 파일 또는 tsconfig.json 파일이 포함된 폴더를 가리킵니다.
우리가 그들의 필요를 발견하는 대로 이 개체에 다른 옵션을 추가할 수 있습니다.

의미론

프로젝트 참조는 다음 동작을 변경합니다.

• 모듈 확인이 프로젝트 rootDir 의 하위 디렉토리에 있는 .ts 파일로 해석되면 대신 해당 프로젝트의 outDir 에 있는 .d.ts 파일로 해석됩니다.
  
  
  
  • 이 해결 방법이 실패하면 이를 감지하고 단순한 "파일을 찾을 수 없음" 대신 Referenced project "../otherProject" is not built 와 같은 더 똑똑한 오류를 발행할 수 있습니다.
  
  
• 다른 것은 없습니다(TODO: 지금까지?)

참조 프로젝트 수행에 대한 제한 사항

빌드 성능을 의미 있게 개선하려면 프로젝트 참조를 볼 때 TypeScript의 동작을 제한해야 합니다.

특히 다음 사항이 충족되어야 합니다.

• 참조된 프로젝트의 입력 .ts 파일을 읽거나 구문 분석 하지 마십시오.
• 만 tsconfig.json 참조 된 프로젝트는 디스크로부터 읽어야
• 최신 검사는 위의 제약 조건을 위반할 필요가 없습니다.

이러한 약속을 지키려면 참조하는 프로젝트에 몇 가지 제한 사항을 적용해야 합니다.

• declaration 는 자동으로 true 됩니다. 이 설정을 무시하려고 하면 오류가 발생합니다.
• rootDir 기본적으로 입력 파일 세트에서 추론되지 않고 "." ( tsconfig.json 파일을 포함하는 디렉토리)로 설정됩니다.
• files 배열이 제공되면 모든 입력 파일의 이름을 제공해야 합니다.
  
  
  
  • 예외: 유형 참조의 일부로 포함된 파일(예: node_modules/@types )은 지정할 필요가 없습니다.
  
  
• 참조되는 모든 프로젝트에는 references 배열이 있어야 합니다(비어 있을 수 있음).

왜 "declaration": true 입니까?

프로젝트 참조는 구현 파일(.ts) 대신 선언 파일(.d.ts)을 사용하여 빌드 속도를 향상시킵니다.
따라서 당연히 참조된 모든 프로젝트에는 declaration 설정이 있어야 합니다.
이것은 "project": true 의해 암시됩니다.

rootDir 변경하는 이유는 무엇입니까?

rootDir 는 입력 파일이 출력 파일 이름에 매핑되는 방식을 제어합니다. TypeScript의 기본 동작은 입력 파일의 전체 그래프의 공통 소스 디렉토리 를 계산하는 ["src/a.ts", "src/b.ts"] 입력 파일 세트는 ["a.js", "b.js"] 출력 파일을 생성합니다.
그러나 ["src/a.ts", "b.ts"] 입력 파일 세트는 ["src/a.js", "b.js"] 출력 파일을 생성합니다.

입력 파일 세트를 계산하려면 모든 루트 파일과 모든 참조를 재귀적으로 구문 분석해야 합니다.
대규모 프로젝트에서 비용이 많이 듭니다. 그러나 우리는 기존 프로젝트를 나쁜 방식으로 중단하지 않고 오늘 이 동작을 변경할 수 없으므로 이 변경은 references 배열이 제공될 때만 발생합니다.

원형 없음

당연히 프로젝트는 원형이 있는 그래프를 형성하지 않을 수 있습니다. (TODO: 빌드 오케스트레이션 악몽 외에 실제로 어떤 문제가 발생합니까?) 이 문제가 발생하면 형성된 순환 경로를 나타내는 오류 메시지가 표시됩니다.

TS6187: Project references may not form a circular graph. Cycle detected:
    C:/github/project-references-demo/core/tsconfig.json ->
    C:/github/project-references-demo/zoo/tsconfig.json ->
    C:/github/project-references-demo/animals/tsconfig.json ->
    C:/github/project-references-demo/core/tsconfig.json

tsbuild

이 제안은 "실제" 빌드 시스템에서 어떻게 사용되는지에 대해 의도적으로 모호합니다. .ts 코드를 컴파일하기 위해 tsc 이외의 것을 도입하지 않고 50,000 LOC "빠른" 경계를 넘어 확장하는 프로젝트는 거의 없습니다.

" bar 가 아직 빌드되지 않았기 때문에 foo 빌드할 수 없습니다"라는 사용자 시나리오는 컴퓨터가 처리해야 하는 명백한 "가서 가져오기" 종류의 작업입니다. 개발자의 정신적 부담보다

gulp , webpack 등과 같은 도구(또는 해당 TS 플러그인)가 프로젝트 참조를 이해하고 최신 확인을 포함하여 이러한 빌드 종속성을 올바르게 처리할 것으로 기대합니다.

이것이 가능 하도록 하기 위해 다음 동작을 보여주는 TypeScript 빌드 오케스트레이션 도구에 대한 참조 구현 을 제공합니다.

• 빠른 최신 확인
• 프로젝트 그래프 순서
• 병렬화 구축
• (TODO: 다른 사람?)

이 도구는 공개 API만 사용해야 하며 빌드 도구 작성자가 프로젝트 참조를 구현하는 올바른 방법을 이해하는 데 도움이 되도록 잘 문서화되어야 합니다.

할 것

이 제안을 완전히 완료하기 위해 채워야 할 섹션

• 기존 프로젝트를 전환하는 방법
  
  
  
  • 기본적으로 tsconfig.json 파일을 드롭한 다음 빌드 오류를 수정하는 데 필요한 참조를 추가합니다.
  
  
• baseUrl 에 미치는 영향
  
  
  
  • 구현을 어렵게 하지만 효과적으로 최종 사용자에게 영향을 미치지 않음
  
  
• 중첩 프로젝트에 대한 간략한 논의(TL, DR 허용해야 함)
• "너무 큰" 프로젝트를 소비자를 손상시키지 않고 더 작은 프로젝트로 세분화하는 개요 시나리오
• Lerna 시나리오 파악
  
  
  
  • 사용 가능한 데이터 포인트(N = 1)는 빌드가 이미 이러한 방식으로 효과적으로 구성되어 있기 때문에 이것이 필요하지 않을 것이라고 말합니다.
  
  
  • 사람들이 이것을 하는 방법을 더 잘 이해하기 위해 더 많은 예 또는 반례를 찾으십시오.
  
  
• 예를 들어 webpack/babel/rollup을 통해 JS를 연결하는 사람들을 위해 dtsEmitOnly 설정이 필요합니까?
  
  
  
  • 아마도 references + noEmit 이것을 의미합니다
  
  

환상적이야!

Lerna 시나리오 파악

• 사용 가능한 데이터 포인트(N = 1)는 빌드가 이미 이러한 방식으로 효과적으로 구성되어 있기 때문에 이것이 필요하지 않을 것이라고 말합니다.

"이것"은 제안 또는 참조 빌드 구현을 나타냅니까? lerna를 사용하여 빌드를 수행할 수 있지만(저희 팀이 수행합니다), TS(또는 이 제안에서 빌드된 도구)가 자체적으로 처리하는 경우 엉성하고 훨씬 더 효율적입니다.

TODO 섹션은 전체 제안에 대한 TODO입니다.

멋진!

참조되는 모든 프로젝트에는 참조 배열이 있어야 합니다(비어 있을 수 있음).

이것이 정말 필요한가? 이러한 패키지에 .d.ts 파일이 있으면 충분하지 않을까요?
(이 경우 tsconfig.json 도 있기 때문에 필요하지 않을 수도 있죠?)

내 사용 사례: outDir 사용하지 않는 (예: 타사) 프로젝트를 고려하면 .ts , .js 및 .d.ts 옆에 있습니다. 서로, 그리고 TS는 현재 컴파일하려고합니다 .ts 사용하는 대신 .d.ts .

나를 위해 outDir 를 사용하지 않는 이유는 import "package/subthing" 스타일 가져오기를 더 쉽게 허용하기 위한 것입니다. 그렇지 않으면 import "package/dist/subthing" with outDir: "dist" 이어야 합니다.
그리고 NPM 패키지나 소스 리포지토리를 직접 사용할 수 있습니다(예: npm link ).

( package.json 가 main 디렉토리를 지정하도록 허용한다면 도움이 될 것입니다. 그러나 아아...)

예를 들어 webpack/babel/rollup을 통해 JS를 파이프하는 사람들을 위해 dtsEmitOnly 설정이 필요합니까?

전적으로! 이것은 현재 큰 누락 부분입니다. 현재 outFile 사용할 때 단일 d.ts 파일을 얻을 수 있지만 모듈로 전환하고 번들러를 사용하면 이것을 잃게 됩니다. 모듈의 진입점( export as namespace MyLib )에 대해 단일 d.ts 파일을 내보낼 수 있다는 것은 놀라운 일입니다. 외부 도구가 이 작업을 수행할 수 있다는 것을 알고 있지만 이미터 및 언어 서비스에 통합된다면 정말 좋을 것입니다.

이것이 정말 필요한가? 그러한 패키지에 .d.ts 파일이 있으면 충분하지 않을까요?

출력 파일이 있어야 할 위치를 알려주는 대상 tsconfig에 무언가가 필요합니다. 이 제안의 이전 버전에는 "명시적인 rootDir 지정해야 합니다"가 있었는데 이는 다소 번거로웠습니다(모든 tsconfig에서 "rootDir": "." 를 작성해야 함). 우리는 이 세상에서 다양한 동작을 뒤집고 싶기 때문에 참조 배열이 있고 키오프된 항목이 있는 경우 "프로젝트" 동작을 얻는다고 말하는 것이 더 합리적입니다. 명시적으로 명시해야 하는 플래그입니다.

이 제안은 우리가 이미 TypeScript 프로젝트를 구성한 방식과 밀접하게 일치합니다. 우리는 각각 tsconfig.json이 있고 꿀꺽꿀꺽(gulp)을 통해 독립적으로 빌드되는 더 작은 단위로 세분화했습니다. 프로젝트는 d.ts 파일을 참조하여 서로를 참조합니다.

이상적인 세계에서는 참조된 프로젝트를 미리 빌드할 필요가 없습니다. 즉. TypeScript는 참조된 프로젝트의 "빌드"를 수행하고 언어 서비스의 메모리에 해당하는 "d.ts"를 유지 관리합니다. 이렇게 하면 "소스" 프로젝트에서 변경한 내용을 다시 빌드할 필요 없이 "종속" 프로젝트에 표시할 수 있습니다.

출력 파일이 있어야 할 위치를 알려주는 대상 tsconfig에 무언가가 필요합니다.

outDir 가 사용된 경우에만 해당되지 않습니까?

다음과 같이: tsconfig가 있는 경우:

• outDir 사용하지 않습니다(물론 declaration: true ). 그러면 rootDir 도 필요하지 않습니다. references 도 필요하지 않습니다.
• outDir 가 있으면 references 및/또는 rootDir (및 declaration: true )를 설정해야 합니다.

질문하는 이유는 모든 TS 패키지를 참조하여 '프로젝트 모드'를 활성화할 수 있기 때문입니다. 즉, 제 제어에 있습니다.

이 경우 찾고 있는 .d.ts 파일을 찾는 즉시 작동하는 것도 좋을 것입니다(즉, .ts 파일이나 tsconfig 파일이 없으면 불평하지 않습니다). 필요한 경우 NPM 버전(.d.ts 파일만 있을 수 있음)을 해당 소스 버전으로 '교체'하는 또 다른 경우가 가능하기 때문입니다.

예를 들어 NPM 패키지 MyApp 및 SomeLib를 고려하십시오.
SomeLib에는 tsconfig: declaration: true 가 있을 수 있습니다.

다음과 같은 저장소:

package.json
tsconfig.json
index.ts
sub.ts

컴파일하면 다음과 같습니다.

package.json
tsconfig.json
index.ts
index.d.ts
index.js
sub.ts
sub.d.ts
sub.js

이 구조는 예를 들어

// somewhere in MyApp
import something from "SomeLib/sub";

게시된 NPM 패키지에서 현재 항상 .ts 파일을 제거해야 합니다. 그렇지 않으면 MyApp에서 SomeLib를 사용하는 경우 모든 소스가 TS에서 다시 컴파일됩니다.

따라서 NPM에서는 다음과 같이 됩니다.

package.json
index.d.ts
index.js
sub.d.ts
sub.js

이제 MyApp의 tsconfig에 references: ["SomeLib"] 를 넣으면 NPM 버전과 SomeLib의 소스 버전 모두에 대해 '있는 그대로' 작동 하는 것이 sub.d.ts 를 찾는 한.

관련되지만 다른 질문:

SomeLib 의 작성자가 자신의 tsconfig에 references 를 넣으면 나중에 .ts 파일이 있는 NPM 패키지를 게시할 수 있다는 것을 이제 깨달았습니다. 그러나 종속 패키지가 tsconfig에 references: ["SomeLib"] 를 명시적으로 넣지 않은 경우 TS가 여전히 이를 다시 컴파일한다고 가정합니다.

아니면 MyLib의 references 가 import '할 때(즉, references '하지 않음) '프로젝트 경계'도 자동으로 도입하려는 의도입니까?

IIRC, 초기 아이디어 중 하나는 모듈이 예를 들어 node_modules 를 통해 찾은 경우 .d.ts 파일이 .ts 파일보다 선호되지만 나중에 다시 변경되었습니다. , 발견적 방법("through node_modules ")이 일반적으로 너무 문제가 많았기 때문입니다. 명시적인 '프로젝트 경계'가 있으면 이 문제가 해결될 수 있습니다(예: projectRoot: true 대신 또는 추가로 references )?

lerna의 경우 더 간단한 솔루션을 원했습니다.

1. 개별 패키지 디렉토리에서 패키지는 모노리포지토리 구조에 관한 정보를 알 수 없습니다 . 개별 tsconfig JSON 파일 참조를 포함 할 수 없습니다.
   
   
   
   • 이를 통해 개별 패키지를 별도의 리포지토리로 분할하고 기본 리포지토리 도구에서 이를 복제하도록 할 수 있습니다(예: ProseMirror: https://github.com/ProseMirror/prosemirror).
   
   
2. 루트 "작업 공간" 리포지토리(모든 코드를 포함할 수 있지만 단순히 다른 리포지토리를 복제할 수도 있음)에서 tsconfig.json에 참조가 있어야 합니다.
   
   
   
   • 이것은 도구가 .d.ts 파일로 이동하는 대신 소스에 대한 참조를 인식하고 따를 수 있도록 수행됩니다.
   
   

내 전체 관심사는 개별 프로젝트 구성 파일에 대한 상대 내림차순 "../xx" 경로를 사용하여 참조를 추가하면 더 이상 독립 실행형 모듈로 사용할 수

"작업 공간" tsconfig.json의 새로운 개념을 추가하면 이 문제가 해결됩니다. 그렇게 하면 예를 들어 개별 패키지를 "git clone"하는 경우 해당 종속성을 일반적인 방법(예: npm 또는 yarn 사용)으로 설치하면 컴파일된 종속성이 정의 파일을 가져오기 때문에 별도로 작업할 수 있습니다. 전체 작업 공간을 복제하고 모든 패키지를 가져오는 명령을 실행하면 작업 공간 구성을 통해 모든 소스를 탐색할 수 있습니다.

tsconfig.json 작업 공간도 Yarn의 작업 공간 package.json https://yarnpkg.com/lang/en/docs/workspaces/ 와 완벽하게 정렬됩니다.

여기서 약간의 개념 증명을 했습니다.

https://github.com/spion/typescript-workspace-plugin

개별 저장소의 모든 tsconfig.json 파일에 플러그인을 추가하기

{
  "plugins": [{"name": "typescript-workspace-plugin"}]
}

그런 다음 yarn의 "workspaces" 항목과 함께 최상위 package.json에 "workspace-sources" 항목을 추가합니다.

{
  "workspaces": ["packages/*"],
  "workspace-sources": {
    "*": ["packages/*/src"]
  }
}

이 필드는 tsconfig.json의 "경로" 필드와 완전히 동일하게 작동하지만 패키지 소스를 가리키는 개별 프로젝트의 언어 서비스에만 영향을 줍니다. 적절한 "정의/유형으로 이동" 기능 등을 복원합니다.

그것은 outDir이 사용될 때만 사실입니다. 그렇지 않습니까?

옳은. 우리는 대규모 프로젝트를 가진 거의 모든 사람들이 outDir 사용하고 있다고 가정했습니다. 그렇지 않은 프로젝트에 대해 듣고 싶습니다.

이제 MyApp의 tsconfig에 ["SomeLib"] 참조를 넣으면 NPM 버전과 SomeLib의 소스 버전 모두에서 '있는 그대로' 작동하는 것이 좋습니다.

빅 팬, 나는 이 아이디어를 아주 좋아합니다. 정말 필요한지 아닌지 생각해봐야 합니다.

여기에 한 가지주의해야 할 점은 내가 b)는 어느 쪽도 게시하지 만 .d.ts에 도달 할 파일이 패키지의 저자) 중 하나에 필요 TS 그들을 발견 한 곳의 장소에서 함께 두 .TS 및 tsconfig 파일을 게시 생각, 또는이다. (a)의 경우 프로젝트 참조를 재귀적으로 따르고 올바른 일이 발생하고 (b)의 경우 잘못된 위치로 스파이더 아웃되지 않습니다.

아니면 MyLib의 참조가 그냥 가져올 때(즉, 참조하지 않음) 자동으로 '프로젝트 경계'도 도입하려는 의도입니까?

@mhegazy 와 이야기를 references 배열이 있는 모든 프로젝트는 프로젝트 폴더 외부의 .ts 파일을 절대 "보지" exclude d 디렉토리 아래에 있습니다. 이 변경만으로도 lerna 시나리오 작업("모듈 참조는 항상 .d.ts로 확인됨"을 의미하는 "작업")과 다른 시나리오를 즉시 사용할 수 있습니다.

"작업 공간" 모델을 더 살펴봐야 합니다.

그것은 outDir이 사용될 때만 사실입니다. 그렇지 않습니까?

옳은. 우리는 대규모 프로젝트를 가진 거의 모든 사람들이 outDir을 사용하고 있다고 가정했습니다. 그렇지 않은 프로젝트에 대해 듣고 싶습니다.

Visual Studio 솔루션에는 outdir 없이 컴파일된 67개의 TS 프로젝트가 있고 출력 디렉토리 구조를 만들기 위한 postbuild grunttasks(및 uglify 및 기타 후처리)가 있습니다.

대부분의 프로젝트에는 이러한 tsconfig.json이 있습니다.

 "include": [
    "../baseProj/Lib/jquery.d.ts",
    "../baseProj/baseProj.d.ts"
  ]

나는 참조 제안을 읽는 데 시간이 걸렸고 수정했습니다. AFAICT lerna 및 yarn 작업 공간 사용자는 여기에 제안된 작업 공간 기능이 필요하지 않습니다.

1. 우리는 이미 package.json을 기반으로 하는 종속성 그래프를 가지고 있으므로 빌드를 실행할 순서를 알고 있습니다. 사실, lerna에는 이것을 순서대로 실행할 수 있는 일반적인 실행 명령이 있으며, 해당되는 경우 병렬 처리도 추가하는 도구를 작성하는 것은 어렵지 않습니다. skipLibCheck 는 성능 영향을 무시할 수 있도록 해야 하지만 확인하지 않았습니다.
2. Lerna와 Yarn은 이미 적절한 node_modules 위치에 다른 모듈에 대한 심볼릭 링크를 생성합니다. 결과적으로 모든 종속 항목은 다른 모듈의 package.json을 따르고 유형/유형 필드를 읽고 참조된 module.d.ts 유형 정의 파일을 찾을 수 있습니다.

우리가 가지고 있지 않은 것과 내가 작성한 플러그인이 제공하는 것은 모든 소스를 동시에 로드하는 방법입니다. 두 개 이상의 모듈을 동시에 변경해야 할 때 "정의로 이동" 및 "유형 정의로 이동"을 통해 .d.ts 파일로 보내는 것을 원하지 않습니다. 편집할 수 있도록 원래 소스 코드 위치로 나를 보내길 원합니다. 그렇지 않으면 개별 프로젝트 디렉토리를 로드하기만 하면 lerna/yarn에 의해 생성된 node_modules 심볼릭 링크가 작동합니다.

우리에게도 마찬가지입니다. Lerna 대신 Rush 를 사용하여 종속성 그래프를 계산하지만 효과는 동일합니다. 프로젝트를 빌드할 때 tsc 는 실행해야 하는 많은 작업 중 하나일 뿐입니다. 우리의 컴파일러 옵션은 더 큰 빌드 시스템에서 계산되며 tsconfig.json 이 입력 파일이 아니라 생성된 출력(주로 VS Code의 이점을 위해)인 모델로 이동하고 있습니다.

우리가 가지고 있지 않은 것과 내가 작성한 플러그인이 제공하는 것은 모든 소스를 동시에 로드하는 방법입니다. 두 개 이상의 모듈을 동시에 변경해야 할 때 "정의로 이동" 및 "유형 정의로 이동"을 통해 .d.ts 파일로 보내는 것을 원하지 않습니다. 편집할 수 있도록 원래 소스 코드 위치로 나를 보내길 원합니다.

+1 이것은 굉장할 것입니다.

더 나은 다중 프로젝트 지원을 꿈꾸는 경우 첫 번째 요청은 VS Code IntelliSense 작동 방식과 같은 컴파일러 서비스입니다. Rush가 컴파일러 엔진을 100번 회전하지 않고도 tsc 100번 호출할 수 있다면 빌드가 훨씬 더 빨라질 것입니다. 컴파일러는 가장 비용이 많이 드는 빌드 단계 중 하나입니다. 모노레포에서는 빌드 시간이 정말 중요합니다.

@ylanton @nickpape-msft @qz2017

예, 부탁합니다!

프로젝트 시스템의 가장 유용한 결과 중 하나는 다음과 같습니다.
'정의로 이동'은 d.ts 파일 대신 소스 파일로 이동했으며
프로젝트 참조 트리를 통해 '모든 참조 찾기'를 검색했습니다.

아마도 이것은 '전역 이름 바꾸기' 유형 리팩토링도 잠금 해제할 것입니다.

2017년 11월 9일 목요일 오후 9시 30분 Salvatore Previti [email protected]
썼다:

예, 부탁합니다!

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-343356868 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AANX6d19Zz7TCd_GsP7Kzb-9XJAisG6Hks5s07VXgaJpZM4E-oPT
.

@mhegazy 와 이야기를

좋습니다. 그렇다면 왜 특정 참조를 지정해야 합니까?
플래그(예 projectRoot: true )가 있으면 충분할 것 같습니다.
예를 들어 references: ["foo"] 와 references: [] 의 차이점은 무엇입니까?
내가 import "foo" 또는 import "bar" 이면 둘 다 .ts 파일을 무시하기 때문입니다.

따라서 이 경우 제안은 다음과 같습니다.

이 tsconfig.json( projectRoot TODO 자전거 보관소):

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "projectRoot": true
   }
}

tsc 가 프로젝트 폴더 외부의 항목(제외된 디렉토리 아래의 파일 포함)을 해결해야 할 때 .d.ts 파일만 봅니다(또는 .d.ts _선호할 수도 있습니다. 파일을 보고 tsconfig 및/또는 .ts 되돌아가는 경우에만 해당).

이렇게 하면 컴파일 중 해결이 빠르고 간단해집니다.
모노레포 참조(예: import "../foo" ) 및 패키지 기반 참조(예: import "foo" )에 대해 작동합니다.
NPM 패키지 및 해당 소스 코드 표현에 대해 작동합니다.
그리고 .d.ts 를 찾을 수 없으면 오류 메시지가 덜 도움이 될지라도 컴파일하는 동안 tsconfig.json 기계를 해결할 필요가 없습니다.

사실이라고 하기에는 너무 좋은 것 같습니다. 실제로 이렇게 간단하다면 중요한 것을 간과하고 있는 것 같습니다. :)

다른 사람들도 지적했듯이 'IntelliSense'가 .ts 파일을 계속 사용하는 것이 여전히 매우 중요합니다.

따라서 '정의로 이동', '참조 찾기' 등을 요청하면 역 매핑을 사용하여 .d.ts 파일에서 해당 .ts 파일을 찾아야 합니다. 멀리.

이 매핑은 다음을 사용하여 수행할 수 있습니다.

• 같은 임베디드 주석 문자열 사용하여 //# sourceURL = ../src/foo.ts 에서 .d.ts
  
  
  
  • 더 정교한 소스 맵을 사용하여 '롤업' .d.ts 에서 원래 .ts 다시 매핑할 수 있습니다.
  
  
• .js 파일을 확인하고 소스맵을 사용하여 `.ts

이것은 .ts 가 변경될 때 .d.ts 를 재구축하는 주제를 소개하지만 이 제안으로 해결되어야 하는지 확신이 서지 않습니다. 예를 들어, 루트 프로젝트 자체에서조차 .js 파일을 다시 빌드하는 프로세스가 필요한 오늘날의 경우입니다. 그래서 나는 그것이 존재한다면 의존성을 재구축할 무언가가 있을 것이라고 가정하는 것이 안전할 것이라고 생각합니다. 각 패키지에 대해 병렬 tsc 의 무리가 될 수 있고 tsbuild 가 될 수 있으며 compileOnSave 와 같은 동작을 가진 스마트 IDE가 될 수 있습니다.

@pgonzal @michaelaird https://github.com/spion/typescript-workspace-plugin 은 이 작업만 수행합니다. 복원은 정의로 이동하고 multi-tsconfig yarn/lerna/etc 작업 공간 프로젝트에 대한 모든 참조를 찾습니다.

흥미롭습니다... Rush와 함께 이 작업을 수행할 수 있는지 궁금합니다. 살펴보겠습니다.

참고로 이 노력의 일환으로 만든 또 다른 간단한 도구는 wsrun

lerna run 와 유사하게 작업 공간의 모든 패키지에 대한 명령을 실행합니다.

typescript 종속성은 순서대로 컴파일해야 하므로 wsrun은 package.json 종속성을 기반으로 토폴로지 순서로 패키지 명령을 실행할 수 있습니다. 빌드하는 동안 병렬 처리를 지원합니다. 최적의 병렬은 아니지만 나중에 개선할 수 있습니다.

참고로 oao 는 원사를 위한 또 다른 monorepo 도구입니다. 최근에는 명령의 '토폴로지' 순서에 대한 지원도 추가했습니다.

현재 제안(https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-341317069)과 관련이 있을 수 있지만 우리에게 중요한 목표이기 때문에 "리팩토링"이라는 단어를 여기에 게시하고 싶습니다. 이 문제에서 자주 언급되지 않습니다.

우리의 사용 사례는 여러 TS 프로젝트가 있는 단일 리포지토리이며 기본적으로 common-library 및 app1 및 app2 앱 두 개로 줄일 수 있습니다. IDE에서 작업할 때는 단일 프로젝트로 처리해야 합니다. 예를 들어 이름 바꾸기 리팩토링은 세 모듈 모두에서 작동해야 하지만 app1 및 app2 도 두 개의 개별 빌드 대상입니다. 빌드가 일반적으로 별도의 관심사라는 데 동의하지만 사실은 우리 앱이 매우 작고 cd app1 && tsc 와 같은 작업을 수행하는 것이 우리에게 완벽할 것이라는 점입니다.

TypeScript가 이를 지원하는 좋은 방법을 제시한다면 정말 좋을 것입니다.

monorepo 프로젝트 간 리팩토링/참조의 경우 vscode에서 작업하는 경우 이 설정이 작동하는 것으로 나타났습니다.

루트 tsconfig:

"compilerOptions": {
   "baseUrl": ".",
   // global types are different per project
   "types": [],
   "paths": {
      "lib": ["packages/lib/src"],
      "xyz1": ["packages/xyz1/src"],
      "xyz2": ["packages/xyz2/src"],
   }
},
"include": ["./stub.ts"], // empty file with export {} to stop vscode complaining about no input files
"exclude": ["node_modules"]

패키지/xyz1/tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["node"],
   },
   "include": ["src/**/*"]
}

패키지/xyz2/tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["webpack-env"]
   },
  "include": ["src/**/*"]
} 

패키지/lib/tsconfig.json

{
   "extends": "../../tsconfig",
    "compilerOptions": { ... },
    "include": ["src/**/*"],
    // special file to load referenced projects when inside in lib package, without it they won't be 
    // visible until you open some file in these projects 
    "files": ["./references.ts"],
}

패키지/lib/tsconfig-build.json

{
   "extends": "./tsconfig",
    // exclude referenced projects when building
   "files": []
}

패키지/lib/references.ts

import "xyz1";
import "xyz2";

export {};

패키지의 package.json 올바른 main 속성이 필요하며 라이브러리가 없는 패키지의 경우에도 types 수 있습니다. 예를 들면 다음과 같습니다.

  "main": "src/main.tsx",
  "types": "src/main.tsx",

이런 식으로 lib 항목을 리팩토링/이름 변경하면 xyz1 및 xyz2 참조도 리팩터링됩니다. 또한 프로젝트는 이러한 방식으로 다른 전역/대상 라이브러리를 가질 수 있습니다.

Gradle에서는 단순히 이것을 합성 빌드 라고 부릅니다.

그건 그렇고, TypeScript 컴파일러에 기여하고 싶다면 한 가지 포인트를 줄 수 있습니까? 나는 repo를 복제했고 작은 거래가 아닙니다 (나는 소스를 읽는 데 사용합니다 : angular, ionic, 문서에서 얻을 수 없거나 인터넷에서 멀리 떨어져있을 때 표현 ...) 나는 정말 도움이 필요합니다. 갈 길을 알려주세요.

감사 해요!
TypeScript의 밝은 미래.

사람들이 상대 모듈 경로를 사용하는 경우 시도해보고 싶은 프로토타입이 있습니다. https://github.com/RyanCavanaugh/project-references-demo 에 기본 시나리오를 설명하고 작동 방식을 보여주는 샘플 리포지토리가 있습니다.

로컬에서 시도하는 경우:

git clone https://github.com/RyanCavanaugh/TypeScript
git checkout pr-lkg
npm install
npm run build
npm link

그런 다음 다른 폴더에서:

npm link typescript

pr-lkg 태그가 변경되면 최신 작업 커밋을 가리키는 상태로 유지하겠습니다. 내 할 일에 대한 다음 단계:

• [x] 종속 프로젝트가 빌드되지 않은 경우 더 나은 오류 메시지 추가
• [ ] 비상대 모듈 경로에 리디렉션 동작 적용
• [ ] 빌드 도구가 사용할 API 노출

@RyanCavanaugh del 모듈 또는 Error: Cannot find module 'C:\github\TypeScript\built\local\tsc.js' (아마도 로컬 경로?) 누락과 같은 오류로 인해 실제로 빌드할 수 없지만 전반적으로 구조가 좋아 보입니다.

이것은 tsc 전용입니까 아니면 언어 서버를 사용하여 VSCode의 프로젝트 전체 리팩토링도 설명합니까?

...또한 pr-lkg 태그가 없습니다.

태그가 있습니다(분기가 아님). https://github.com/RyanCavanaugh/TypeScript/tree/pr-lkg 참조

references in tsconfig.json 는 종속성별 옵트인입니다. rootDir 외부에서 해결되는 모든 것에 적용하는 것이 더 합리적이지 않을까요?

다음과 같은 sandbox 속성과 같은 것을 상상하고 있습니다.

# tsconfig.json
{
  "compilerOptions": {
    "outDir": "lib",
    "sandbox": "."
  },
  "include": ["src/index.ts"]
}

샌드박스는 rootDir 동일한 값으로 설정합니다. tsconfig.json 가 포함된 디렉토리에 대한 경로를 명시적으로 제공하는 대신 일반 모듈 확인이 적용되며 FS 트리를 검색하여 tsconfig.json 자동으로 찾을 수 있습니다.

# package.json
{
  "name": "animals",
  "module": "src",
  "typings": "lib",
  "dependencies": {
    "core": "*"
  }
}

이 방법:

• 두 개의 동기화된 목록( references 및 dependencies )을 유지할 필요가 없습니다.
• 패키지는 자체 외부의 파일 시스템에 대한 지식이 없습니다.
• 사용자 지정 경로 대신 노드 모듈 확인 전략을 사용합니다.

@RyanCavanaugh , 내가 이해하는 한 이러한 변경 사항 으로 로컬에서만 작업할 수 있으며 예를 들어 travis-ci.org에서 테스트를 위해 이러한 프로젝트를 보낼 수 없습니다. 오른쪽?

오늘 @billti / @mhegazy 와의 회의 메모

• 참조 찾기/이름 바꾸기는 적어도 프로젝트의 종료를 결정하는 데 필요한 컴파일 컨텍스트가 메모리에 맞는 시나리오에서 작동해야 합니다.
• 솔루션 전체 이름 바꾸기는 "솔루션" 파일을 찾기 위해 이동하고, 참조하는 프로젝트를 찾기 위해 뒤로 작업한 다음, 기호가 표시되는 그래프 섹션을 구현 로드 합니다. 이것은 진정한 원래 선언을 찾기 위한 반복적인 프로세스일 수 있습니다.
• tsbuild는 -w 모드를 처리해야 합니다.
• 솔루션에는 솔루션 폴더 외부에서 시작된 하위 프로젝트가 없을 수 있습니다.
• gulp, webpack과 같은 명확한 문서가 필요합니다.

사이드바: 이 이름 바꾸기는 오늘 작동하지 않습니다.

function f() {
  if (Math.random() > 0.5) {
    return { foo: 10 };
  } else {
    return { foo: 20 };
}
// rename foo here doesn't rename *both* instances in the function body
f().foo;

Ryan, Mohamed, Bill에게 감사드립니다. 프로젝트 전체에서 작동하는 참조 찾기/이름 바꾸기 시나리오를 가져오는 것은 중간 규모 프로젝트를 지원하지 않는 TypeScript에 대한 원래 불만을 제기할 때 염두에 두었던 핵심 사용 사례 중 하나였습니다. 중간 규모의 프로젝트는 모듈식이지만 크지는 않습니다. 지금까지 여기에서 본 제안과 작업은 확장성 플레이에 더 가깝습니다. 이것은 TypeScript의 장기적인 상태에 매우 중요하지만 대부분 중간 규모가 아닌 대규모 프로젝트에 유용합니다. Ryan의 이 댓글 에서 들은 내용은 TypeScript에서 중간 규모 프로젝트를 개발할 때 인체 공학을 개선하는 데 필요한 사항에 더 가깝습니다.

항상 그렇듯이 TypeScript 팀 전체에 노력에 감사드립니다! 당신은 멋진 일을하고 있습니다.

lerna/yarn 작업 공간에는 당신의 삶을 훨씬 더 쉽게 만들어 줄 트릭이 있습니다.
하위 프로젝트의 package.json에 있는 main 및 types 항목을 src/index를 가리킵니다. ts 파일 및 참조 찾기/이름 바꾸기 시나리오는 간단하게 작동합니다.
그리고 단일 tsc를 실행하여 전체 프로젝트를 컴파일할 수 있습니다.
일부 패키지에 대해 그렇게 할 수도 있고 모든 패키지에 대해 그렇게 할 수도 있습니다. 당신의 전화.

몇 가지 단점과 함정이 있지만(한 패키지에 기능을 추가하거나 전역 기호를 가져오면 전체 프로그램을 오염시킬 수 있음) 일반적으로 매우 잘 작동합니다.
NPM에 게시하려면 기본 및 유형을 적절한 값으로 설정하기만 하면 됩니다(빌드의 일부로).

위의 설정으로 예상되는 모든 기능을 어느 정도 얻었습니다.

여기 당신의 삶을 훨씬 더 쉽게 만들어줄 lerna/yarn 작업 공간의 트릭이 있습니다.
하위 프로젝트의 package.json에 있는 기본 항목과 유형 항목이 src/index.ts 파일을 가리키도록 하면 참조 찾기/이름 바꾸기 시나리오가 간단하게 작동합니다.

내 경험에 따르면 해당 설정의 문제는 TypeScript가 _external_ 패키지의 ts 파일을 외부 라이브러리가 아니라 이를 필요로 하는 패키지의 _소스_인 것처럼 취급하기 시작한다는 것입니다. 이로 인해 여러 문제가 발생합니다.

• 외부 패키지는 _requireing_ 패키지의 tsconfig를 사용하여 매번 여러 번 컴파일됩니다. 필요한 패키지에 다른 tsconfig(예: 다른 라이브러리)가 있는 경우 다시 컴파일할 때까지 필수 패키지에 잘못된 컴파일 오류가 나타날 수 있습니다.

• 또한 필수 패키지는 필요한 것보다 더 많은 파일을 포함하기 때문에 더 느리게 컴파일됩니다.

• 모든 패키지의 rootDir 는 최상위 디렉토리가 되어 잠재적으로 index 포함하는 대신 모든 패키지의 TS 파일을 직접 포함할 수 있습니다. 개발자가 주의하지 않으면 필수 패키지 API를 우회할 수 있습니다. 또한 빌드 프로세스가 강력하지 않은 경우 필요한 패키지에 외부에 있어야 하는 필수 패키지의 중복 코드가 포함될 수 있습니다.

우리 프로젝트에서는 단점 때문에 TS 파일에 의존하는 것을 배제했습니다. 모든 패키지 간 종속성은 index.d.ts 파일에 있으므로 컴파일러는 이를 외부로 처리하고 모두 양호합니다.

물론 .d.ts 에 따라 다단계 빌드가 필요한 문제(webpack과 같은 도구로 즉시 사용 불가능)와 IDE 경험이 좋지 않은 문제(이름 변경, 패키지 경계를 넘지 않는 참조)가 있습니다. ).

다른 감정에 동의합니다. typescript는 빌드 시스템이 아니라 컴파일러입니다. 더 나은 다중 프로젝트 빌드를 지원하려면 도구가 필요합니다. 커뮤니티에 이 작업을 시작하는 몇 가지 옵션이 있다는 것을 알고 있습니다. 예를 들어 C#에는 Roslyn이라는 컴파일러와 MSBuild라는 빌드 도구가 있습니다.

오늘은 @mhegazy 와 함께 이름 바꾸기 작업을 가능한 한 적은 고통으로 작동시키는 방법에 대해 논의했습니다.

이름 바꾸기에 대한 비퇴화 최악의 경우는 다음과 같습니다.

// alpha.ts
const v = { a: 1 };
export function f() { return v; }
export function g() { return v; }

// alpha.d.ts (generated)
export function f(): { a: number };
export function g(): { a: number };

// beta.ts (in another project)
import { f } from '../etc/alpha';
f().a;

// gamma.ts (in yet another project)
import { g } from '../etc/alpha';
g().a;

핵심 관찰은 alpha.ts 를 상호 연관시키는 것을 볼 수 없다면 f().a 이름을 바꾸는 것이 g().a 이름을 바꿔야 한다는 것을 아는 것은 불가능하다는 것입니다.

구현 계획의 대략적인 스케치:

• .d.ts 파일의 "풍부한" 및 "린" 메모리 내 SourceFile 표현이 있습니다. "린" 파일은 디스크에서 읽습니다. "풍부한" 것은 메모리 내 .d.ts 생성의 결과로 생성됩니다.
• "Rich" .d.ts SourceFiles에는 식별자 노드에서 원본 소스 파일의 원래 이름에 대한 참조가 있습니다.
• 이름을 바꾸는 동안 평소와 같이 먼저 문제의 기호로 이동합니다. 이것이 프로젝트 참조 .d.ts에서 시작되면 구현 로드하고 "Rich" .d.ts 파일을 만듭니다.
  
  
  
  • 참고: 이 프로세스는 반복적입니다. 즉, 실제 구현 파일(프로젝트 참조로 인해 .d.ts 리디렉션이 아닌 파일)에 도달할 때까지 여러 수준을 다시 추적해야 할 수 있습니다.
  
  
• 이제 "풍부한" 포인터를 사용하여 프로젝트의 .d.ts에 있는 다른 식별자가 동일한 소스 파일 식별자에서 유래했는지 알아냅니다.
• 각 다운 스트림 프로젝트에서 텍스트 스캔 이름이 바뀐 식별자하고 있는지의 "이동 - 투 데프"결과가 .d.ts에서 "동일한 심볼에서 시작"위치 중 하나입니다
• 구현 파일에서 이름 바꾸기 수행

@RyanCavanaugh 는 정의로 이동하여 모든 참조가 이 모델에서 작동하는지 찾을 수 있습니까?

수많은 미해결 질문에 대해 Anders 및 Mohamed와의 이전 토론에서 나온 메모

• prepend 는 .d.ts 에도 적용됩니까? 예
• dogfood 지점에서 @internal 로 무엇을 하나요? 로컬 .d.ts 파일에 내부 선언을 유지해야 하지만 출력 버전에는 표시되지 않도록 해야 합니다.
  
  
  
  • --stripInternal 제거
  
  
  • 그러나 그것을 비하하지 마십시오 (아직 ...?)
  
  
  • Ryan, remove-internal 도구 작성(완료)
  
  
  • 내장 -> LKG 프로세스가 @internal 선언을 제거합니다.
  
  
• 예를 들어 @types 에서 .d.ts 파일을 변경하면 어떻게 됩니까?
  
  
  
  • 가능한 새로운 오류를 보려면 수동으로 강제로 다시 빌드해야 합니다. ☹️
  
  
  • 이것이 실제로 문제가 되는 경우 출력 폴더에 "files I look at.txt" 파일을 결국 쓸 수 있습니다.
  
  
• noEmitOnError 필수인가요? 예.
  
  
  
  • 그렇지 않으면 다시 빌드하면 오류가 숨겨집니다!
  
  
• referenceTarget -> composable ✨ 🚲 🏡 ✨
• 선언 방출을 원하지 않지만 빠른 재구축을 원하는 리프 노드 프로젝트는 어떻습니까?
  
  
  
  • tsbuild 또는 이에 상응하는 항목은 composable 의 업스트림과 관련이 없는 요구 사항을 준수하는지 확인할 수 있습니다.
  
  
• 순환 참조, (어떻게) 작동합니까?
  
  
  
  • 기본적으로
  
  
  • 이렇게 하려면 예를 들어 { path: "../blah", circular: true } 지정할 수 있습니다.
  
  
  • 그렇게 하면 빌드가 결정적이고 항상 고정된 지점에 도달하는지 확인하는 것은 여러분에게 달려 있습니다(아마도 그렇지 않을 수도 있습니다?!)
  
  
  • 순환:true 가져오기의 재매핑은 선택 사항 이지만 우선 순위가 지정된 재매핑입니다.
  
  

잡록

• @weswigham 에는 @mhegazy 와 논의해야 하는 이름 바꾸기에 대한 대체 아이디어가

나는 이미 졌다. 나는 대부분 컴파일러에서 소스맵의 해석을 유지하고 싶었지만(별도 도구에 대한 별도의 책임) 당신이 없는 동안 어쨌든 추가 작업을 했습니다(분명히 원활한 go-to def가 바람직하기 때문에).

@RyanCavanaugh
#23944 병합 후 참조된 프로젝트에서 모든 참조의 이름을 바꾸거나 찾아야 합니까? 또한 언어 서비스(tsbuild는 제외)만 필요한 경우 composite: true 및 projectReferences: [] 를 사용해야 합니까?

#23944 병합 후 참조된 프로젝트에서 모든 참조의 이름을 바꾸거나 찾아야 합니까?

아직 아님. 그러나 우리는 다음에 이것을 작업하고 있습니다.

또한 언어 서비스(tsbuild가 아님)만 필요한 경우에 복합: true 및 projectReferences: []를 사용해야 합니까?

질문을 이해했는지 확실하지 않습니다. "빌드"가 아닌 "언어 서비스"가 무엇을 의미합니까?

질문을 이해했는지 확실하지 않습니다. "빌드"가 아닌 "언어 서비스"가 무엇을 의미합니까?

새로운 빌드 도구( build mode 라고도 함)(#22997)가 아니라 monorepo의 여러 프로젝트에서 편집기 지원(이름 바꾸기/모든 참조 찾기/등...)에만 관심이 있습니다. 내 컴파일에 대한 babel.

그냥 작동해야합니다. build는 옵트인 기능이므로 원하지 않는 경우 사용할 필요가 없습니다. 예를 들어 VSCode에서 언어 서비스 경험에 tsc 가 필요하지 않은 것과 유사합니다.

그러나 교차 프로젝트 참조가 작동하는 데 필요한 메타데이터를 생성하려면 선언 및 선언 맵을 사용하여 빌드해야 할 수 있습니다.

제안의 모든 측면을 올바르게 이해하고 있는지 확실하지 않지만 개별 프로젝트가 경로가 아닌 이름으로 다른 프로젝트를 참조하도록 할 수 있습니까? 작업 공간 프로젝트에는 globs를 통해 또는 모든 개별 프로젝트 이름을 나열하여 원사 작업 공간과 유사하게 모든 프로젝트 경로를 지정하는 방법이 있어야 합니다.

기본적으로 다음 대신:

"dependencies": [
    "../common", 
    "../util"
],

우리가 가질 수 있습니까?

"dependencies": [
    "common", 
    "util"
],

작업 공간이 있습니다. tsconfig.json

"workspace": {
  "common": "packages/common",
  "util": "packages/util"
}

또는 더 나은 방법은 경로 구문입니다.

"workspace": {
  "*":"packages/*"
}

혜택:

• 모듈 시스템에 따라 다른 조회 규칙을 지정하는 기능
• 예를 들어 작업 공간 외부에서 패키지를 다운로드할 때 node_modules로 대체하는 기능
• 여러 저장소를 복제하고 경로에 대해 다른 구성을 사용하여 작업할 여러 작업 공간을 자유롭게 집계하여 더 많은 패키지에서 병렬로 작업할 수 있습니다.

아니면 최소한 미래 사용을 위해 비경로 이름('./' 또는 '../'로 시작하지 않는 이름)을 예약할 수 있습니까?

이것이 얼마나 관련이 있는지는 잘 모르겠지만 Yarn 1.7은 최근 "집중된 작업 공간"이라는 개념을 도입했습니다. 이 블로그 게시물을 참조하십시오.

작업 공간과 @RyanCavanaugh 가 TypeScript 프로젝트 참조/빌드 모드와 관련하여 수행하고 있는 작업에 대해 잘 알고 있는 사람이 있습니까? 내 직감으로는 Yarn 작업 공간(올해 npm에서도 사용할 수 있음)과 향후 TypeScript 버전 사이의 _somewhere_가 여러 프로젝트 및 공유 라이브러리가 있는 단일 저장소에 대한 좋은 지원이 있다는 것입니다. (우리는 현재 고통을 느낀다.)

이 기능의 진행 상황에 대한 업데이트를 받고 싶습니다. 우리는 다음 달 정도에 Aurelia vNext를 모노레포로 옮길 계획입니다. 우리의 새 버전은 100% TypeScript이며 가능하다면 Lerna보다 공식 TS 프로젝트 시스템을 사용하고 싶습니다. 우리는 또한 새로운 기능의 얼리 어답터/테스터를 기쁘게 생각합니다. :)

소스 맵 지원을 핵심 지원 및 goto def 가 마지막 릴리스(TS 2.9)에 추가되었습니다. 빌드 지원을 위한 tsc --b 는 이미 TS 3.0에 있으며 이에 바인딩됩니다. typescript 코드 베이스가 그것을 사용하기 위해 옮겨졌습니다 . 우리는 현재 typescript repo를 사용하여 이 지원을 테스트하고 있습니다.

이 시점에서 수행해야 하는 작업은 다음과 같습니다. 1. 다중 프로젝트 시나리오에서 작업하기 위해 모든 참조 찾기/이름 바꾸기를 가져옵니다. 2. 편집기의 백그라운드에서 .d.ts 파일 업데이트 문제 해결 및 3. 다중 프로젝트 시나리오에 대한 --watch 지원. 또한 많은 테스트.

이 티켓은 그가 3년 동안 예약한 것입니다. 아직 3/6 미해결 항목이 있습니까?

@claudeduguay 이것은 TypeScript가 지원하는 프로젝트에 대한 근본적인 변화입니다. 축하할 시간이 아니겠습니까? 나는 이것에 대해 매우 기쁩니다!

@mhegazy 이것은 좋은 소식입니다. TS 팀이 자체 프로젝트에서도 이를 도그푸딩하고 있다는 소식을 들으니 매우 기쁩니다. 마지막 몇 가지 작업이 완료되고 이것을 Aurelia의 옵션으로 사용할 수 있기를 기대합니다. :) 설정에 대한 문서가 나오는 즉시 vNext를 새 프로젝트 시스템으로 이동할 것입니다. 기다릴 수 없어!

@mhegazy 이 모든 것이 ES2015 모듈을 기반으로 하는 package.json 파일 및 프로젝트에서 어떻게 작동하는지 설명해 주시겠습니까? 예를 들어 Aurelia vNext에는 @aurelia/kernel , @aurelia/runtime , @aurelia/jit 등과 같은 패키지가 있습니다. import 에서 사용할 모듈 이름입니다. 다양한 프로젝트 전반에 걸친 진술. TS 컴파일러는 이러한 모듈 이름이 다양한 참조 폴더에 매핑된다는 것을 어떻게 이해합니까? 참조된 각 폴더에 있는 package.json 파일을 선택합니까? Lerna 또는 Yarn Workspace와 어떻게 다릅니까? 위의 링크를 처음 살펴보면 작동하는 솔루션을 얻기 위해 TS 프로젝트(빌드)를 Lerna(dep linking and Publishing)와 함께 사용해야 한다고 생각하지만 TS가 어떻게 제대로 빌드되는지는 알 수 없습니다. package.json 및 node_modules와 통합할 수 없는 경우. TS repo 소스는 일반적인 Lerna 프로젝트와 상당히 다르기 때문에(실제로는 전혀 그렇지 않음) 이것이 우리의 요구를 충족할 수 있을지 궁금해지기 시작했습니다. 제공할 수 있는 추가 정보, 특히. 여기에서 설명한 것과 유사한 작동하는 데모 솔루션 설정이 매우 도움이 될 것입니다. 감사 해요!

@EisenbergEffect와 같은 질문을 공유합니다. 특히 나는 이것이 lerna 관리되는 monorepo와 잘 작동하기를 바랍니다.

고려해야 할 두 가지 단일 리포지토리 시나리오

lerna로 모든 것을 심볼릭 링크한 설정부터 시작하겠습니다.

/packages
  /a
    /node_modules
      /b -> symlink to b with package.json "types" pointing to dist/index.d.ts
  /b
    /dist
      /index.d.ts -> built output of entry point declaration file

여기서 우리가 원하는 핵심은 a a 가 오래된 경우 a 를 빌드한 b 를 다시 빌드하는 것입니다. 그래서 우리는 추가 할 것 "references": [ { "path": "../b" } ] 에 a 의 tsconfig.json 실행 tsc --build 에서 a 올바른 상류 빌드 얻을 b . 이 세계에서 프로젝트 참조는 단순히 빌드 그래프를 나타내는 역할을 하며 더 스마트한 증분 재구축을 허용합니다. 이상적으로 lerna와 TS는 여기에서 협력하고 적절한 경우 package.json 종속성을 tsconfig.json 로 미러링할 수 있습니다.

또 다른 시나리오(덜 일반적일 수 있음)는 심볼릭 링크를 연결하지 않았지만 여전히 라이브 패키지 세트에서 작업하는 것처럼 "마치처럼 작동"하려는 경우입니다. 오늘날 상당히 지루한 경로 매핑으로 이 작업을 수행할 수 있으며 일부 사람들은 그렇게 합니다. 여기의 프로젝트 참조는 빌드 순서에 유사하게 도움이 되지만 참조될 때마다 경로 매핑을 자동으로 생성하기 위해 참조하는 tsconfig 파일의 속성을 지원하는 것이 매우 바람직할 것입니다. 예를 들어 당신이 있었다면

{
  "compilerOptions": { "outDir": "bin" },
  "package": "@RyanCavanaugh/coolstuff"
}

"references": [{ "path": "../cool" }] 를 추가하면 @RyanCavanaugh/coolstuff -> ../cool/bin/ 의 경로 매핑이 자동으로 추가됩니다. 아직 추가하지 않았지만 더 일반적인 시나리오로 판명되면 조사할 수 있습니다.

이상적으로 lerna와 TS는 여기에서 협력하고 적절한 경우 package.json 종속성을 tsconfig.json으로 미러링할 수 있습니다.

외부 도구에 의존하는 대신 composite: true 가 설정된 경우 package.json (tsconfig와 함께 제공되는 경우)를 잠재적 참조로 읽도록 선택할 수 있습니다(각 해결된 패키지에 tsconfig.json , 하나가 있으면 빌드 가능한 프로젝트 노드로 간주하고 반복). 모든 것이 제자리에 심볼릭 링크되어 있으므로 작업 공간을 처리하기 위해 해상도를 변경할 필요도 없습니다. Lerna는 실제로 afaik처럼 ts 관련(또는 빌드 관련) 항목을 설정하지 않고 모든 것을 제자리에 심볼릭 링크하고 버전 관리를 관리합니다. 이것은 ts 파일을 로드하고 (선언보다 파일을 선호하기 때문에) 오늘날 우리가 하는 일에 대한 최적화가 될 것이며 구식 여부에 관계없이 모든 것을 재컴파일합니다.

@RyanCavanaugh 이것은 꽤 흥미롭게 들립니다. Rush의 심볼릭 링크 전략과 함께 작동하는지 알 수 있습니까? 간단히 말해서 Rush는 리포지토리의 모든 패키지에 대한 모든 종속성의 상위 집합을 포함하는 합성 패키지 common/temp/package.json 을 만듭니다. 그런 다음 pnpm 을 사용하여 이 합성 패키지에 대한 단일 설치 작업을 수행합니다. (PNPM은 중복된 라이브러리 인스턴스를 제거하는 NPM의 트리 구조 대신 심볼릭 링크를 사용하여 방향성 비순환 그래프를 만듭니다.) 그런 다음 Rush는 리포지토리의 각 프로젝트에 대해 common/temp 아래의 적절한 폴더를 가리키는 심볼릭 링크로 구성됩니다. 결과는 TypeScript 및 표준 NodeJS 해상도 알고리즘과 완벽하게 호환됩니다. 전체 리포지토리에 대해 하나의 수축 포장 파일과 하나의 버전 관리 방정식이 있기 때문에 매우 빠르며 각 패키지가 고유한 종속성을 지정할 수 있습니다.

우리는 이 모델에 대해 tsconfig.json 에 특별한 것을 넣지 않습니다. goto-definition 기능에 특별한 TypeScript 구성이 필요한 경우 Git에 저장하는 것보다 설치 중에 자동 생성하는 것이 이상적입니다.

@pgonzal Rush에 대한 링크를 주셔서 감사합니다! 나는 아직 그것을 보지 못했다. 오늘 밤에 확인하겠습니다.

@RyanCavanaugh 설명 감사합니다. lerna를 사용한 첫 번째 시나리오는 우리가 가진 것과 가장 비슷합니다. 다음은 https://github.com/aurelia/ux 에서 새 프로젝트 지원을 사용하려는 TS 및 lerna가 포함된 UX 리포지토리입니다.

@weswigham 당신이 설명하는 것이 우리 시나리오에도 맞는 것 같습니다. 위의 예 리포지토리.

yarn 작업 공간의 경우 모듈은 각 개별 패키지의 디렉토리에서 심볼릭 링크되지 않고 대신 최상위 작업 공간 node_modules 에서 심볼릭 링크됩니다.

이것이 내가 점('./' 또는 '../')으로 시작하지 않는 참조를 미래를 위해 예약해야 한다고 생각하는 이유입니다. 상대 경로로 처리되는 대신 활성 모듈 확인 전략을 통해 처리되는 "명명된 참조"가 되기를 바랍니다.

@spion 필요한 경우 path 이외의 속성 이름을 사용합니다(예: "references": [ { "module": "@foo/baz" } ] ). "bar" 및 "./bar" 가 files 에서는 동일한 것을 의미하지만 references 에서는 다른 것을 의미하는 혼동을 일으키고 싶지 않습니다 "./bar"

아래에서 문서/블로그 포스트 작업 진행 중(피드백에 따라 수정 예정)

이 스레드를 팔로우하는 사람은 누구나 시도해 볼 것을 권장합니다. 저는 현재 모노레포 시나리오를 작성하여 마지막 버그/기능을 수정하고 있으며 곧 이에 대한 지침을 제공해야 합니다.

프로젝트 참조

프로젝트 참조는 TypeScript 프로그램을 더 작은 조각으로 구성할 수 있는 TypeScript 3.0의 새로운 기능입니다.

이렇게 하면 빌드 시간을 크게 개선하고 구성 요소 간에 논리적 분리를 적용하며 새롭고 더 나은 방식으로 코드를 구성할 수 있습니다.

또한 더 빠른 TypeScript 빌드를 가능하게 하기 위해 프로젝트 참조와 함께 작동하는 tsc , --build 플래그에 대한 새로운 모드를 도입합니다.

예시 프로젝트

상당히 정상적인 프로그램을 살펴보고 프로젝트 참조가 프로그램을 더 잘 구성하는 데 어떻게 도움이 되는지 봅시다.
converter 및 units 두 개의 모듈이 있는 프로젝트와 각각에 해당하는 테스트 파일이 있다고 상상해 보십시오.

/src/converter.ts
/src/units.ts
/test/converter-tests.ts
/test/units-tests.ts
/tsconfig.json

테스트 파일은 구현 파일을 가져오고 몇 가지 테스트를 수행합니다.

// converter-tests.ts
import * as converter from "../converter";

assert.areEqual(converter.celsiusToFahrenheit(0), 32);

이전에는 단일 tsconfig 파일을 사용하는 경우 이 구조를 사용하는 것이 다소 어색했습니다.

• 구현 파일에서 테스트 파일을 가져올 수 있었습니다.
• src 가 출력 폴더 이름에 표시되지 않고 test 및 src 를 동시에 빌드할 수 없었습니다.
• 이 이제까지 새로운 오류가 발생하지 않을지라도, 다시 테스트를 유형 검사 구현 파일에 단지 내부를 필수 변경
• 테스트만 변경하면 아무 것도 변경되지 않았더라도 구현을 다시 형식 확인해야 했습니다.

여러 tsconfig 파일을 사용하여 이러한 문제 중 일부 를 해결할 수 있지만 새로운 문제가 나타납니다.

• 내장된 최신 확인 기능이 없으므로 결국 tsc 두 번 실행하게 됩니다.
• tsc 두 번 호출하면 더 많은 시작 시간 오버헤드가 발생합니다.
• tsc -w 는 한 번에 여러 구성 파일에서 실행할 수 없습니다.

프로젝트 참조는 이러한 모든 문제 등을 해결할 수 있습니다.

프로젝트 참조란 무엇입니까?

tsconfig.json 파일에는 새로운 최상위 속성 references 있습니다. 참조할 프로젝트를 지정하는 객체의 배열입니다.

{
    "compilerOptions": {
        // The usual
    },
    "references": [
        { "path": "../src" }
    ]
}

각 참조의 path 속성은 tsconfig.json 파일이 포함된 디렉토리 또는 구성 파일 자체(이름이 있을 수 있음)를 가리킬 수 있습니다.

프로젝트를 참조하면 다음과 같은 새로운 일이 발생합니다.

• 참조된 프로젝트에서 모듈을 가져오면 대신 출력 선언 파일( .d.ts )이 로드됩니다.
• 참조된 프로젝트가 outFile 를 생성하면 출력 파일 .d.ts 파일의 선언이 이 프로젝트에서 표시됩니다.
• 빌드 모드(아래 참조)는 필요한 경우 참조된 프로젝트를 자동으로 빌드합니다.

여러 프로젝트로 분리하면 유형 검사 및 컴파일 속도를 크게 향상시키고 편집기를 사용할 때 메모리 사용량을 줄이며 프로그램의 논리적 그룹화 시행을 개선할 수 있습니다.

composite

참조된 프로젝트에는 새 composite 설정이 활성화되어 있어야 합니다.
이 설정은 TypeScript가 참조된 프로젝트의 출력을 찾을 위치를 빠르게 결정할 수 있도록 하는 데 필요합니다.
composite 플래그를 활성화하면 몇 가지 사항이 변경됩니다.

• rootDir 설정은 명시적으로 설정하지 않으면 기본적으로 tsconfig 파일이 포함된 디렉토리로 설정됩니다.
• 모든 구현 파일은 include 패턴과 일치하거나 files 배열에 나열되어야 합니다. 이 제약 조건을 위반하면 tsc 지정되지 않은 파일을 알려줍니다.
• declaration 가 켜져 있어야 합니다.

declarationMaps

선언 소스 맵에 대한 지원도 추가했습니다.
--declarationMap 를 활성화하면 "정의로 이동" 및 이름 바꾸기와 같은 편집기 기능을 사용하여 지원되는 편집기에서 프로젝트 경계를 넘어 코드를 투명하게 탐색하고 편집할 수 있습니다.

prepend outFile

참조에서 prepend 옵션을 사용하여 종속성의 출력을 앞에 추가할 수도 있습니다.

   "references": [
       { "path": "../utils", "prepend": true }
   ]

프로젝트를 추가하면 현재 프로젝트의 출력 위에 프로젝트의 출력이 포함됩니다.
이것은 .js 파일과 .d.ts 파일 모두에서 작동하며 소스 맵 파일도 올바르게 내보내집니다.

tsc 는 이 프로세스를 수행하기 위해 디스크의 기존 파일만 사용하므로 일부 프로젝트의 출력이 결과 파일에 두 번 이상 있기 때문에 올바른 출력 파일을 생성할 수 없는 프로젝트를 생성할 수 있습니다. .
예를 들어:

  ^ ^ 
 /   \
B     C
 ^   ^
  \ /
   D

이 상황에서는 D 의 출력에 A 의 두 복사본이 생성되므로 각 참조 앞에 추가하지 않는 것이 중요합니다. 이는 예기치 않은 결과를 초래할 수 있습니다.

프로젝트 참조에 대한 주의 사항

프로젝트 참조에는 알고 있어야 하는 몇 가지 절충점이 있습니다.

종속 프로젝트는 종속성에서 빌드된 .d.ts 파일을 사용하기 때문에 특정 빌드 출력을 체크인 하거나 복제한 후 프로젝트를 빌드해야 가짜를 보지 않고 편집기에서 프로젝트를 탐색할 수 있습니다. 오류.
우리는 이것을 완화할 수 있어야 하는 .d.ts 생성 프로세스 뒤에서 작업하고 있지만 현재로서는 개발자에게 복제 후 빌드해야 함을 알리는 것이 좋습니다.

또한 기존 빌드 워크플로와의 호환성을 유지하기 위해 --build 스위치로 호출하지 않는 한 tsc 는 종속성을 자동으로 빌드 하지 않습니다 .
--build 에 대해 자세히 알아보겠습니다.

TypeScript용 빌드 모드

오랫동안 기다려온 기능은 TypeScript 프로젝트를 위한 스마트 증분 빌드입니다.
3.0에서는 tsc 와 함께 --build 플래그를 사용할 수 있습니다.
이것은 단순한 컴파일러보다 빌드 오케스트레이터처럼 작동하는 tsc 의 새로운 진입점입니다.

tsc --build (줄여서 tsc -b )를 실행하면 다음이 수행됩니다.

• 참조된 모든 프로젝트 찾기
• 최신 상태인지 감지
• 올바른 순서로 오래된 프로젝트 빌드

tsc -b 에 여러 구성 파일 경로를 제공할 수 있습니다(예: tsc -b src test ).
그냥 같은 tsc -p 이 이름 않다면 자체가 불필요 설정 파일 이름 지정, tsconfig.json .

tsc -b 명령줄

원하는 수의 구성 파일을 지정할 수 있습니다.

 > tsc -b                                # Build the tsconfig.json in the current directory
 > tsc -b src                            # Build src/tsconfig.json
 > tsc -b foo/release.tsconfig.json bar  # Build foo/release.tsconfig.json and bar/tsconfig.json

명령줄에서 전달하는 파일 순서에 대해 걱정하지 마십시오. tsc 는 종속성이 항상 먼저 빌드되도록 필요한 경우 파일을 재정렬합니다.

tsc -b 관련 플래그도 있습니다.

• --verbose : 무슨 일이 일어나고 있는지 설명하기 위해 자세한 로깅을 인쇄합니다(다른 플래그와 결합될 수 있음)
• --dry : 수행할 작업을 표시하지만 실제로는 아무 것도 빌드하지 않습니다.
• --clean : 지정된 프로젝트의 출력을 삭제합니다( --dry 와 결합 가능).
• --force : 모든 프로젝트가 오래된 것처럼 작동
• --watch : 감시 모드( --verbose 제외한 플래그와 결합할 수 없음)

주의 사항

보통 tsc 출력 (생산할 예정 .js 및 .d.ts 않는) 구문 또는 입력 에러의 존재를 noEmitOnError 에있다.
증분 빌드 시스템에서 이 작업을 수행하는 것은 매우 나쁩니다. 오래된 종속성 중 하나에 새로운 오류가 있는 경우 후속 빌드가 현재 최신 프로젝트 빌드를 건너뛰기 때문에 한 번만 표시됩니다.
이러한 이유로 tsc -b noEmitOnError 는 모든 프로젝트에 대해

빌드 출력( .js , .d.ts , .d.ts.map 등)을 체크인하는 경우 특정 소스 제어 후에 --force 빌드를 실행해야 할 수 있습니다. 소스 제어 도구가 로컬 복사본과 원격 복사본 사이의 타임스트맵을 유지하는지 여부에 따라 작업이 달라집니다.

msbuild

msbuild 프로젝트가 있는 경우 다음을 추가하여 빌드 모드를 활성화할 수 있습니다.

    <TypeScriptBuildMode>true</TypeScriptBuildMode>

당신의 프로젝트 파일에. 이렇게 하면 자동 증분 빌드 및 정리가 활성화됩니다.

tsconfig.json / -p 와 마찬가지로 기존 TypeScript 프로젝트 속성은 존중되지 않습니다. 모든 설정은 tsconfig 파일을 사용하여 관리해야 합니다.

일부 팀은 tsconfig 파일이 짝을 이루는 관리되는 프로젝트와 동일한 암시적 그래프 순서를 갖는 msbuild 기반 워크플로를 설정했습니다.
솔루션이 이와 같으면 프로젝트 참조와 함께 tsc -p 와 함께 msbuild 를 계속 사용할 수 있습니다. 이들은 완전히 상호 운용 가능합니다.

안내

전체 구조

tsconfig.json 파일이 더 많으면 일반적으로 구성 파일 상속 을 사용하여 공통 컴파일러 옵션을 중앙 집중화할 수 있습니다.
이렇게 하면 여러 파일을 편집할 필요 없이 하나의 파일에서 설정을 변경할 수 있습니다.

또 다른 좋은 방법은 모든 리프 노드 프로젝트에 references 가 있는 "솔루션" tsconfig.json 파일을 갖는 것입니다.
이것은 간단한 진입점을 나타냅니다. 예를 들어 TypeScript 저장소에서 src/tsconfig.json 에 모든 하위 프로젝트를 나열하기 때문에 모든 엔드포인트를 빌드하기 위해 tsc -b src 를 실행합니다.
3.0부터는 tsconfig.json 파일에 reference 가 하나 이상 있는 경우 files 배열이 비어 있는 것이 더 이상 오류가 아닙니다.

TypeScript 리포지토리에서 이러한 패턴을 볼 수 있습니다. src/tsconfig_base.json , src/tsconfig.json 및 src/tsc/tsconfig.json 를 주요 예로 참조하세요.

상대 모듈을 위한 구조화

일반적으로 상대 모듈을 사용하여 repo를 전환하는 데 필요한 것은 많지 않습니다.
주어진 상위 폴더의 각 하위 디렉토리에 tsconfig.json 파일을 배치하고 이러한 구성 파일에 reference 추가하여 프로그램의 의도된 계층과 일치시키기만 하면 됩니다.
outDir 를 출력 폴더의 명시적 하위 폴더로 설정하거나 rootDir 를 모든 프로젝트 폴더의 공통 루트로 설정해야 합니다.

outFile을 위한 구조화

outFile 사용한 컴파일 레이아웃은 상대 경로가 그다지 중요하지 않기 때문에 더 유연합니다.
명심해야 할 한 가지는 일반적으로 "마지막" 프로젝트까지 prepend 사용하지 않으려는 것입니다. 이렇게 하면 빌드 시간이 향상되고 주어진 빌드에 필요한 I/O 양이 줄어듭니다.
TypeScript 리포지토리 자체는 여기에서 좋은 참조입니다. 일부 "라이브러리" 프로젝트와 일부 "종점" 프로젝트가 있습니다. "엔드포인트" 프로젝트는 가능한 한 작게 유지되고 필요한 라이브러리만 가져옵니다.

모노레포를 위한 구조화

TODO: 더 많이 실험하고 이것을 알아내십시오. Rush와 Lerna는 우리 쪽에서 다른 것을 암시하는 다른 모델을 가지고 있는 것 같습니다.

또한 #25164에 대한 피드백을 찾고 있습니다.

@RyanCavanaugh 아주 멋진 글과 뛰어난 기능을 사용해 보시기 바랍니다. 특히. 구성 파일 참조가 있는 하위 프로젝트로 큰 프로젝트를 구성하는 데 며칠을 보낸 후.

몇 가지 메모가 있습니다.

1. 모노레포가 뭔가요? 이 사용 사례를 조금 더 설명하는 것이 좋습니다.
2. 대부분의 경우(특히 대규모 프로젝트의 경우) 빌드 중에 생성되는 추가 아티팩트가 많이 있습니다. 우리의 경우 꿀꺽꿀꺽(gulp)을 통한 CSS, HTML, 이미지 파일 등이 있습니다. 이러한 빌드 도구의 사용이 이 새로운 작업 방식에 어떻게 채택될지 궁금합니다. 예를 들어, *.ts 파일뿐만 아니라 다른 모든 파일(스타일, 마크업 등)에서도 watch를 실행하고 싶습니다. 그렇게하는 방법? gulp watch 및 tsc -b -w 를 병렬로 실행해야 합니까?

@vvs a monorepo는 일반적으로 Rush 또는 Lerna와 같은 도구로 관리되는 NPM 패키지 모음입니다.

꿀꺽 꿀꺽 꿀꺽 꿀꺽 꿀꺽 마시고 있다면 최고의 경험을 얻기 위해 기본적으로 프로젝트 참조를 이해하는 로더를 사용하고 싶을 것입니다. @rbuckton 은 내부적으로 gulpfile을 사용하는 일부 개발자가 있기 때문에 여기에서 몇 가지 작업을 수행했습니다. 아마도 그는 그곳에서 좋은 패턴이 어떻게 보이는지 가늠할 수 있을 것입니다.

@RyanCavanaugh 잘 보고 있습니다. Lerna 가이던스에 관심이 많습니다 :)

@RyanCavanaugh 이것은 멋져 보입니다. 저는 현재 lerna monorepo로 시험해 보기 위해 노력하고 있습니다.

당신의 글에서 나에게 유일하게 불분명한 것은 prepend 옵션이었습니다. 나는 그것이 어떤 문제를 다루고 있는지, 어떤 상황에서 그것을 사용하고 싶은지, 사용하지 않으면 어떻게 되는지 잘 알지 못했습니다.

이것은 굉장하다! 저는 ts-loader 및 관련 프로젝트에서 일하고 있습니다. TypeScript의 LanguageServiceHost / WatchHost 를 사용하는 프로젝트에서 이를 지원하기 위해 변경이 필요할 것 같습니까?

(제가 의미하는 바의 예는 https://github.com/TypeStrong/ts-loader/blob/master/src/servicesHost.ts를 참조하십시오.)

그렇다면 모든 안내/홍보 감사히 받겠습니다! 사실 웹팩 세계에서 이것을 테스트하기를 원하신다면 저는 이것을 지원하는 ts-loader 버전을 출시하는 데 도움을 드리고 싶습니다.

물론 "그냥 작동"한다면 훨씬 더 좋습니다.

훌륭한 일!

@yortus @EisenbergEffect 저는 https://github.com/RyanCavanaugh/learn-a에 샘플 lerna repo를 설정했으며 작동시키기 위해 취한 단계를 요약한 README가 있습니다.

내가 올바르게 이해하고 있다면 모든 것(X 및 모든 종속성 및 전이 종속성)이 최신 상태 tsc -b X 는 아무 작업도 수행하지 않습니까? 참조가 없는 개별 프로젝트에 대해 -b 플래그 없이도 얻을 수 있는 것이 있는지 궁금하십니까? (물론 이 경우 종속성은 제외됨)

이것은 꽤 멋지다. 저는 이와 같은 Lerna 구성을 사용하는 경향이 있습니다(모노 저장소를 기능별로 분리하기 위해). 나는 그것이 잘 작동할 것이라고 생각합니다.

{
"레르나": "2.11.0",
"패키지": [
"패키지/구성요소/ ","패키지/라이브러리/ ",
"패키지/프레임워크/ ","패키지/응용 프로그램/ ",
"패키지/도구/*"
],
"버전": "0.0.0"
}

typescript@next 있습니까?

우리의 원사 작업 공간 리포지토리로 이것을 테스트할 것입니다. 아직 작업 공간을 지원하지 않는 몇 가지 모듈에 대해 nohoist 를 사용해야 하므로 어떻게 처리하는지 보는 것이 좋습니다.

@RyanCavanaugh 오늘 밤 테스트 실행을 위해

정말 흥미로운! 현재 우리 회사에서는 mtsc 라는 자체 도구를 사용하여 동시에 여러 프로젝트의 감시 모드를 지원합니다. 동일한 리포지토리에서 컴파일하고 관찰해야 하는 약 5개의 프로젝트가 있습니다.

프로젝트에는 다음과 같은 다양한 구성이 있습니다. ECMA 타겟팅(es5, es6), 유형(노드, jest, DOM 등), 방출(일부는 웹팩을 사용하고 일부는 js 자체로 컴파일). 그들은 모두 한 가지를 공유합니다. 그것은 tslint 플러그인 입니다 . 나머지는 모두 다를 수 있습니다. 내 도구는 또한 프로젝트 컴파일 후에 tslint를 실행합니다(프로젝트당 및 tslint가 완료되기 전에 프로젝트가 다시 컴파일되는 경우 중지됨).

현재 제안에 대한 나의 주요 관심사는 어떤 프로젝트가 어떤 리소스를 공유하는지 말할 수 없다는 것입니다. 특수 유틸리티 폴더를 사용하지만 컴파일 오류가 두 번 발생하는 것을 원하지 않는 서버 및 클라이언트 프로젝트가 있습니다. 그러나 그것은 필터로 고칠 수 있으므로 큰 문제는 아닙니다. :)

저는 현재 17개의 상호 의존적인 패키지로 구성된 lerna monorepo로 새로운 --build 모드를 시도했습니다. 모든 것이 작동하는 데 시간이 걸렸지만 이제 모든 것이 작동하고 점진적으로 구축할 수 있다는 것은 우리에게 큰 개선입니다.

아래에서 설명하는 몇 가지 문제가 발생했습니다. 이것이 TS 팀에 유용한 피드백이고 다른 사람들이 프로젝트에서 --build 모드를 사용하는 데 도움이 되기를 바랍니다.

tsc --build 모드에 대한 피드백

1. 가짜 "\출력 파일 '2.map'이 존재하지 않기 때문에 오래된 것입니다"

모든 빌드의 모든 패키지에 대해 이 메시지를 받았으므로 아무 것도 변경되지 않은 경우에도 모든 빌드가 완전히 다시 빌드되었습니다. @RyanCavanaugh 가 이미 #25281에서 이 문제를 수정했으므로 20180628 또는 나중에 야간에 업데이트하면 더 이상 문제가 되지 않습니다. 다음 문제는 야간에 최소 20180628 업데이트했다고 가정합니다.

2. "\종속성에서 .d.ts 파일이 최신 상태입니다."

편집: #25337에서 보고됨.

이 문제를 재현하려면 그의 지시에 따라 @RyanCavanaugh 의 learn-a 샘플 저장소 를 설정하십시오. tsc -b packages --verbose 를 실행하여 모든 것이 처음 빌드되는지 확인합니다. 이제 pkg1/src/index.ts 1행을 import {} from "./foo"; 하고 저장합니다. tsc -b packages --verbose 다시 실행합니다. pkg2 대한 빌드는 건너뜁니다. pkg1 가 pkg2 의 소스를 손상시키는 방식으로 변경되었음에도 불구하고. 이제 pkg2/src/index.ts 에서 빨간색 물결선을 볼 수 있습니다. tsc -b packages --force 로 다시 빌드하면 빌드 오류가 표시됩니다. 다음 문제는 이 문제를 해결하기 위해 --force 로 빌드한다고 가정합니다.

3. 다운스트림 패키지에서 '중복 식별자' 빌드 오류를 일으키는 .d.ts 파일 생성

편집: #25338에서 보고됨.

이 문제를 재현하려면 그의 지시에 따라 @RyanCavanaugh 의 learn-a 샘플 저장소 를 설정하십시오. 이제 lerna add @types/node 를 실행하여 세 패키지 모두에 Node.js 입력을 추가합니다. tsc -b packages --force 를 실행하여 여전히 잘 빌드되는지 확인합니다. 이제 pkg1/src/index.ts 다음 코드를 추가합니다.

// CASE1 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// export const bar = () => parse('bar');

// CASE2 - no build errors in pkg1 or in downstream packages
// import {parse, UrlWithStringQuery} from 'url';
// export const bar = (): UrlWithStringQuery => parse('bar');

// CASE3 - no build errors in pkg1 or in downstream packages
// export declare const bar: () => import("url").UrlWithStringQuery;

// CASE4 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// type UrlWithStringQuery = import("url").UrlWithStringQuery;
// export const bar = (): UrlWithStringQuery => parse('bar');

한 번에 하나의 케이스 주석을 제거하고 tsc -b packages --force . 사례 1과 4는 pkg2 에서 엄청난 빌드 오류를 일으킵니다. 사례 2와 3에서는 빌드 오류가 없습니다. 사례 1과 4의 중요한 차이점은 생성된 pkg1/lib/index.d.ts 의 첫 번째 줄인 것 같습니다.

/// <reference path="../node_modules/@types/node/index.d.ts" />

사례 2와 3은 이 줄을 생성하지 않습니다. pkg2 가 사례 1과 4에서 빌드되면 다른 경로에 @types/node 선언의 동일한 복사본 두 개가 포함되어 '중복 식별자' 오류가 발생합니다.

아마도 이것은 사례 2와 3이 작동하기 때문에 의도적으로 설계된 것일 수 있습니다. 그러나 그것은 꽤 혼란스러워 보입니다. 이러한 4가지 경우에 대해 pkg1 에는 빌드 오류 또는 경고가 없지만 다운스트림 빌드 동작은 내보낸 선언의 정확한 스타일에 매우 민감합니다. (a) pkg1 가 사례 1과 4에 대해 오류가 발생하거나 (b) 4가지 사례 모두에 동일한 다운스트림 빌드 동작이 있어야 하거나 (c) TS 팀의 명확한 지침이 있어야 한다고 생각합니다. 이 문제를 피하기 위해 선언문을 작성하는 방법.

4. Yarn 작업 공간을 사용할 때 생성된 .d.ts 파일의 import 유형 문제

17 패키지 monorepo로 빌드 모드를 작동시키려고 할 때 생성된 .d.ts 파일에서 import 유형의 상대 경로로 인해 발생하는 여러 빌드 오류를 해결했습니다. 나는 마침내 모듈 호이스팅과 관련된 문제를 해결했습니다. 즉, yarn 작업 공간을 사용할 때 설치된 모든 모듈은 monorepo의 모든 패키지에 대한 심볼릭 링크를 포함하여 monorepo-root node_modules 디렉토리로 호이스트됩니다. lerna.json 에서 packages 속성을 사용하도록 monorepo를 변경했는데, 이로 인해 lerna 가 자체 비호이스팅 부트스트래핑 알고리즘을 사용하여 문제가 해결되었습니다. 어쨌든 느리지 만 더 좋고 안전한 접근 방식입니다.

TS가 모듈 호이스트 설정을 지원할 의도인지 확실하지 않으므로 발생한 문제에 대한 재현을 개발하지 않았지만 관심이 있다면 만들 수 있습니다. 문제는 일부 빌드가 최상위 packages 디렉토리(tsconfig 설정에 따라)와 최상위 node_modules 디렉토리( import 생성된 .d.ts 파일의 import 유형). 이것은 구조적 유형으로 인해 때때로 작동하지만 내보낸 고유 기호와 같은 경우에는 실패합니다.

5. 반복적인 구성

lerna를 사용하도록 monorepo를 설정하려면 기본적으로 "packages": ["packages/*"] in lerna.json 와 같은 것을 넣으면 됩니다. Lerna는 globstars를 확장하여 정확한 패키지 목록을 작성한 다음 각 패키지의 package.json 선언된 종속성을 확인하여 정확한 종속성 그래프를 작성합니다. 패키지와 종속성을 마음대로 추가 및 제거할 수 있으며 lerna 구성을 건드릴 필요 없이 유지됩니다.

TypeScript --build 모드에는 좀 더 많은 의식이 필요합니다. 글로브 패턴은 인식되지 않으므로 모든 패키지는 @RyanCavanaugh 의 learn-a 샘플 저장소에 명시적으로 나열되고 유지되어야 합니다(예: packages/tsconfig.json ). 빌드 모드는 package.json 종속성을 확인하지 않으므로 모든 패키지는 package.json 파일( "dependencies" )과 tsconfig.json 파일입니다( "references" ).

이것은 사소한 불편이지만 lerna's 접근 방식에 비해 리그마롤이 눈에 띄는 것을 발견했기 때문에 여기에 포함시킵니다.

6. tsc 전역 모듈 확장으로 인한 충돌

편집: #25339에서 보고되었습니다.

이 문제를 재현하려면 그의 지시에 따라 @RyanCavanaugh 의 learn-a 샘플 저장소 를 설정하십시오. 이제 lerna add @types/multer 를 실행하여 세 패키지 모두에 multer 타이핑을 추가합니다. tsc -b packages --force 를 실행하여 여전히 잘 빌드되는지 확인합니다. 이제 pkg1/src/index.ts 다음 줄을 추가합니다.

export {Options} from 'multer';

tsc -b packages --force 다시 실행합니다. 어설션 위반으로 인해 컴파일러가 충돌합니다. 스택 추적과 주장을 간략히 살펴보니 Express 네임스페이스의 글로벌 확장과 관련이 있는 것 같습니다.

피드백에 대해 @yortus 에게 감사드립니다. 감사합니다. 3의 경우 https://github.com/Microsoft/TypeScript/issues/25278 이라고 생각합니다

4의 경우 모듈 호이스팅이 개념으로 익숙하지 않습니다. 자세히 설명하거나 재현을 공유할 수 있습니까?

@mhegazy lerna와 yarn을 사용하는 많은 사람들이 (저를 포함하여) 작업 공간을 사용합니다. 추가 정보: https://yarnpkg.com/lang/en/docs/workspaces/

기본 tsconfig 선언 어디는 현재 실 작업 공간, lerna, 확장 tsconfigs을 사용하고 paths 게양 모듈과 모든 패키지에 대한 공유 아래에 root/node_modules . yarn 및 monorepo 들을 때 workspaces 라고 생각합니다. 그것이 바로 사용을 용이하게 하고 중복을 줄이기 위한 기능의 의도이기 때문입니다. 이 변경 사항이 기본 tsconfig에 선언된 길고 고통스러운 paths 간단히 제거할 것으로 예상했습니다.

다음은 루트 monorepo tsconfig의 샘플입니다(도움이 되는 경우):

{
  "extends": "./packages/build/tsconfig.base.json",
  "compilerOptions": {
    "baseUrl": "./packages",
    "paths": {
      "@alienfast/build/*": ["./build/src/*"],
      "@alienfast/common-node/*": ["./common-node/src/*"],
      "@alienfast/common/*": ["./common/src/*"],
      "@alienfast/concepts/*": ["./concepts/src/*"],
      "@alienfast/faas/*": ["./faas/src/*"],
      "@alienfast/math/*": ["./math/src/*"],
      "@alienfast/notifications/*": ["./notifications/src/*"],
      "@alienfast/ui/*": ["./ui/src/*"],
      "@alienfast/build": ["./build/src"],
      "@alienfast/common-node": ["./common-node/src"],
      "@alienfast/common": ["./common/src"],
      "@alienfast/concepts": ["./concepts/src"],
      "@alienfast/faas": ["./faas/src"],
      "@alienfast/math": ["./math/src"],
      "@alienfast/notifications": ["./notifications/src"],
      "@alienfast/ui": ["./ui/src"],
    }
  },
  "include": ["./typings/**/*", "./packages/*/src/**/*"],
  "exclude": ["node_modules", "./packages/*/node_modules"]
}

샘플을 위해 포크를 시도해 보겠습니다.
https://github.com/RyanCavanaugh/learn-a

다음은 원사 작업 공간이 있는 @RyanCavanaugh 의 저장소에 대한 병합
https://github.com/RyanCavanaugh/learn-a/pull/3/files

우리는 또한에 모듈 게양을 사용 Jupyterlab lerna와 원사. 기본적으로 모든 패키지 간에 설치된 종속성을 공유할 수 있으므로 루트 프로젝트의 파일 시스템에 한 번만 존재합니다.

나는 작업 공간이 모든 패키지 간에 link 명령을 사용하여 서로 액세스할 수 있도록(또는 최소한 종속 항목에 액세스할 수 있도록 하는 것보다 조금 더 깔끔한 것으로 이해합니다.)

위와 같이 모듈 호이스팅은 모든 종속성을 루트 node_modules 디렉토리로 이동합니다. 이것은 노드 모듈 확인이 항상 디렉토리 트리를 탐색하고 필요한 모듈을 찾을 때까지 모든 node_modules 디렉토리를 검색한다는 사실을 이용합니다. 그런 다음 monorepo의 개별 모듈이 이 루트 node_modules 에서 심볼릭 링크되고 모든 것이 제대로 작동합니다. 원사 블로그 게시물은 아마도 내가 할 수 있는 것보다 더 잘 설명할 것입니다.

호이스팅 발생이 보장되지 않습니다. 동일한 패키지의 일치하지 않는 버전이 있는 경우 해당 패키지는 호이스팅되지 않습니다. 또한 기존의 많은 도구는 node_modules 위치를 가정하거나 노드 모듈 확인을 올바르게 따르지 않기 때문에 호이스팅을 지원하지 않습니다. 이 때문에 특정 모듈이나 종속성에 대한 호이스팅을 비활성화할 수 있는 nohoist 설정이 있습니다.

이전 피드백에 여섯 번째 항목을 추가했습니다. tsc 는 거기에 설명된 시나리오에서 충돌합니다.

@mhegazy 3번 항목이 #25278과 관련이 있는지 잘 모르겠습니다. #25278은 잘못된 선언 방출을 설명합니다. 생성된 선언 파일은 구문 및 의미상 유효했지만 다운스트림 프로젝트가 두 개의 노드 유형 사본으로 빌드되어 '중복 식별자' 오류가 발생했습니다.

위와 같이 모듈 호이스팅은 모든 종속성을 루트 node_modules 디렉토리로 이동합니다. 이것은 노드 모듈 확인이 항상 디렉토리 트리를 탐색하고 필요한 모듈을 찾을 때까지 모든 node_modules 디렉토리를 검색한다는 사실을 이용합니다.

Btw 이 모델에는 프로젝트가 package.json 파일에 명시적으로 선언되지 않은 종속성을 가져올 수 있는 "팬텀 종속성"으로 이어지는 단점이 있습니다. 라이브러리를 게시할 때 (1) 테스트/예상된 것과 다른 버전의 종속성이 설치되거나 (2) 설치되지 않은 관련 없는 프로젝트에서 호이스트되었기 때문에 종속성이 완전히 누락되는 것과 같은 문제가 발생할 수 있습니다. 이 맥락에서. PNPM과 Rush에는 모두 팬텀 종속성으로부터 보호하기 위한 아키텍처 선택이 있습니다.

tsc --build 에 대한 일반적인 질문이 있습니다. TypeScript 컴파일러가 모노레포에서 프로젝트 빌드를 조정하는 역할을 인수하려고 합니까? 일반적으로 도구 체인에는 다음과 같은 작업의 전체 파이프라인이 있습니다.

• 전처리
• 지역화된 문자열 생성
• 자산을 JavaScript(css, 이미지 등)로 변환
• 컴파일(타입 체크/트랜스파일)
• .js 파일 롤업(예: webpack)
• .d.ts 파일 롤업(예: API 추출기)
• 단위 테스트 및 문서 생성을 포함한 사후 처리

일반적으로 Gulp 또는 Webpack과 같은 시스템은 이 파이프라인을 관리하고 컴파일러는 체인의 중간에 있는 한 단계에 불과합니다. 때로는 보조 도구가 다른 방식으로 빌드를 실행하기도 합니다(예: jest --watch 용 Jest+ts-jest ).

tsc 이러한 것들을 스스로 관리하는 것을 목표로 하고 있습니까? 그리고 그렇지 않은 경우 기존 빌드 오케스트레이터가 종속성 그래프 자체를 해결하는 방법이 있습니까? 예를 들어 각 프로젝트 폴더에서 tsc를 올바른 순서로 반복적으로 호출하는 방법이 있습니까(전처리가 업데이트된 후)?

또는 디자인이 단일 패스로 전체 monorepo를 처리하는 것이라면(오늘 우리는 별도의 NodeJ 프로세스에서 각 프로젝트를 빌드함) 다른 빌드 작업이 어떻게 참여할지 궁금합니다. 예를 들어, 다음에서 webpack을 실행할 것인가? 모든 프로젝트를 한 번에? (과거에 메모리 부족 문제가 발생했습니다.) 다중 프로세스 동시성을 활용하는 기능을 잃게 될까요?

이것은 BTW에 대한 비판이 아닙니다. 나는 단지 큰 그림과 의도된 사용법을 이해하려고 노력하고 있습니다.

@pgonzal 맞습니다. 실제 모노레포를 구축하는 데에는 tsc가 아닌 부분이 많이 있습니다. lerna monorepo의 경우 다음과 같은 접근 방식을 취했습니다.

• monorepo의 각 패키지는 선택적으로 정의 prebuild 스크립트 및 / 또는 postbuild 그것에서 스크립트 package.json . 여기에는 빌드의 비 tsc 측면이 포함됩니다.
• monorepo의 package.json 에는 다음 스크립트가 있습니다.
  "prebuild": "lerna run prebuild", "build": "tsc --build monorepo.tsconfig.json --verbose", "postbuild": "lerna run postbuild",
• 그게 다야 monorepo 수준에서 yarn build 를 실행하면 스크립트를 정의하는 각 패키지에 대해 prebuild 스크립트를 실행한 다음 tsc --build 단계를 실행한 다음 모든 postbuild 실행합니다. 스크립트. (NPM 원사 모두 규칙에 따라 실행 npm run foo 대략 동일하다 npm run prefoo && npm run foo && npm run postfoo .)

jest --watch 또는 webpack-dev-server 어떻게 처리합니까? 예를 들어 소스 파일이 수정되면 사전 빌드/사후 빌드 단계가 다시 실행됩니까?

이것이 ts-node 및 관련 워크플로에 영향을 미칩니까? "start": "ts-node ./src/app.ts" 또는 "start:debug": "node -r ts-node/register --inspect-brk ./src/app.ts" 와 같은 일부 도우미 앱은 TypeScript에서 "직접" 실행됩니다.

#25355에서 빌드 모드와 관련된 또 다른 문제를 보고했습니다.

지금까지 모든 훌륭한 피드백과 조사에 감사드립니다. 시간을 내어 테스트해보고 타이어를 걷어차주신 모든 분들께 진심으로 감사드립니다.

@yortus re https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -400439520

좋은 글입니다. 제공해주셔서 다시 한 번 감사드립니다. 귀하의 문제를 순서대로 -

1. 결정된
2. #25370에서 홍보하세요
3. 기록된 문제에 대해 논의 - 올바른 수정 사항이 무엇인지 즉시 명확하지 않지만 조치를 취하겠습니다.
4. 조사 중(아래)
5. 기록 #25376
6. 기술적으로 --build AFAICT와 관련이 없습니다. 이것은 우리가 최근에 추가한 새로운 주장입니다. 네이선의 조사

learn-a 리포지토리의 PR을 위해 @rosskevin 🎉! 더 잘 비교하고 대조할 수 있도록 분기로 병합하겠습니다.

@pgonzal 다시 https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401577442

tsc --build에 대한 일반적인 질문이 있습니다. TypeScript 컴파일러가 모노레포에서 프로젝트의 빌드를 조정하는 역할을 인수하려고 합니까?

좋은 질문입니다. 저는 이 질문에 매우 명확하게 대답하고 싶습니다. 확실히 아닙니다 .

tsc 를 사용하여 프로젝트를 빌드하는 것이 오늘 행복했다면 내일도 tsc -b 를 사용하여 여러 부분으로 구성된 프로젝트를 빌드하는 것이 행복하기를 바랍니다. gulp 를 사용하여 프로젝트를 빌드하는 것이 오늘 행복했다면 내일도 gulp 를 사용하여 여러 부분으로 구성된 프로젝트를 빌드하는 것이 행복하기를 바랍니다. 우리는 첫 번째 시나리오를 제어할 수 있지만 두 번째 시나리오를 도와줄 도구 및 플러그인 작성자가 필요합니다. 그래서 tsc -b 조차도 도구 작성자가 프로젝트 참조가 원활하게 재생되도록 돕는 데 사용할 수 있는 노출된 API에 대한 얇은 래퍼일 뿐입니다. 그들의 빌드 모델에서.

더 넓은 맥락은 tsc -b 가 존재해야 하는지, 아니면 별도의 도구/진입점이어야 하는지에 대해 상당히 강력한 내부 논쟁이 있었습니다 tsc 를 사용했고 이제 동일한 작업 실행기로 tsc -b 사용합니다. 마이그레이션하는 다른 사람도 기존 빌드 체인을 제자리에 유지하기를 기대합니다. 작은 조정만으로.

@borekb re https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401593804

이것이 ts-node 및 관련 워크플로에 영향을 미칩니까? 일부 도우미 앱은 TypeScript에서 "직접" 실행됩니다.

암시적으로 프로젝트 참조를 가질 수 없는 단일 파일 스크립트의 경우 영향이 없습니다.

@EisenbergEffect 는 learn-a 리포지토리 에서 프로젝트 간 이름 변경 및 기타 언어 서비스 기능에 대해 몇 가지 질문을 했습니다. 여기서 가장 큰 미해결 질문은 이 기능을 3.0에서 사용 가능한 상태로 만들 수 있는지 여부입니다. 그렇다면 프로젝트 간 이름 바꾸기는 "정상 작동"할 것이며, 모든 다운스트림 프로젝트를 결정적으로 찾고 업데이트하는 것은 분명히 불가능하다는 경고에 따라 - 이것은 다른 프로젝트를 찾기 위한 몇 가지 발견적 방법을 기반으로 하는 "최선의 노력"이 될 것입니다. 프로젝트.

프로젝트 간 이름 바꾸기가 3.0에 대해 안정적이고 완전하다고 생각하지 않으면 이름이 변경된 기호가 다른 프로젝트의 .d.ts 출력 파일에 있는 경우 에만 이름 바꾸기 작업을 차단할 수 있습니다. 업스트림 프로젝트가 수정된 후 업스트림 프로젝트의 후속 빌드에서 .d.ts 파일이 업데이트되기 때문에 매우 혼란스럽습니다. 즉, 로컬 이름을 변경할 때와 선언 코드가 실제로 업데이트되지 않았습니다.

정의로 이동과 같은 기능의 경우 현재 VS Code에서 작동하고 있으며 Visual Studio의 향후 버전에서 즉시 사용할 수 있습니다. 이러한 기능은 모두 .d.ts.map 파일을 활성화해야 합니다( declarationMap 켜기). 이를 밝히기 위한 몇 가지 기능별 작업이 있으므로 예상대로 작동하지 않는 것이 보이면 일부 사례를 놓쳤을 수 있으므로 버그를 기록하십시오.

현재 추적 중인 미해결 문제:

• 프로젝트 간 이름 바꾸기 - @andy-ms가 구현 중입니다.
• 호이스팅된 모듈 설정을 분석하고 그 의미를 이해해야 함 - 나에게
• 샘플의 버전이 있어야합니다 learn-a REPO 그 용도 yarn , 다른 그 용도 pnpm , 다른 용도 게양 모드에서 그 중 하나를 그

열린 질문

• 프로젝트 참조를 추론하기 위해 package.json 를 읽는 로직을 구현해야 합니까? 기록 #25376
• composite 프로젝트에 대해 .d.ts.map 방출을 암시적으로 켜야 합니까?

@RyanCavanaugh 추가

현재 추적 중인 미해결 문제

또한 LS의 백그라운드에서 선언을 업데이트하는 것과 같은 작업을 처리하기 위해 실제 프로젝트 출력 위치와 분리된 증분 출력 캐시가 있다고 언급했습니다(오늘날 변경 사항은 빌드할 때까지 편집기에서 프로젝트 경계를 넘어 전파되지 않습니다). stripInternal 및 빌드 프로세스 변경(여기서 빌드 출력이 제자리에서 변경되어 LS 작업에 적합하지 않음).

질문 죄송합니다. 로드맵에서 확인했기 때문에 이 기능을 활성화하려면 어떻게 해야 합니까?

@aleksey-bykov typescript@next 에서 사용할 수 있습니다

방금 우리의 원사 작업 공간 기반 모노레포에서 이것을 시도했고 잘 작동합니다.

내가 알아차린 한 가지는 tsc --build --watch 가 오류를 보고하지만 빌드가 이제 수정되었다는 아무 것도 출력하지 않는다는 것입니다. 2.9의 표준 tsc 감시 모드는 오류 카운트를 제공하기 시작했으며 거기에 0이 표시되어 건물이 완료되었음을 알 수 있습니다.

나는 *.d.ts로 가득 찬 폴더를 가지고 있고 그것에 대해 무엇을 해야 합니까?

• 그것을 프로젝트로 만들고 참조하십시오 (시도했지만 작동하지 않았습니다)
• "포함"을 사용하십시오.

@timfish 그 피드백이 내가 들은 다른 것과 일치합니다. 기록 #25562

@aleksey-bykov https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -400439520은 몇 가지 개념을 설명하는 데 도움이 됩니다.

@RyanCavanaugh 프로젝트 참조는 commonjs 및 노드 모듈 해결에만 작동하는 것 같습니까?

당신의 예에서 :

import * as p1 from "@ryancavanaugh/pkg1";
import * as p2 from "@ryancavanaugh/pkg2";

p1.fn();
p2.fn4();

1. @ryancavanaugh 모듈이 무엇입니까? TS가 모듈을 해결하는 방법과 관련이 있습니까?
2. 이 예제는 AMD(클래식 모듈 해상도)와 함께 작동해야 합니까?
3. 정의를 찾으려면 outFile 필요합니까?
4. d.ts 파일은 참조 프로젝트에서 찾을 수 있는 위치여야 합니다(아직도 outDir를 사용할 수 있습니까? TS에서 파일을 찾을 수 있습니까?)

나는 2개의 간단한 프로젝트 essentials 및 common 를 가지고 있으며 공통점은 필수 항목으로 컴파일된 항목을 해결할 수 없습니다.

@aleksey-bykov

1. 일반적인 노드 모듈 확인 알고리즘에 따라 확인된 범위가 지정된 모듈 이름일 뿐입니다.
2. 클래식을 포함한 모든 모듈 시스템에서 프로젝트 참조를 사용할 수 있지만 예제 이름(범위가 지정된 모듈)은 노드 외부에서 사용하기에는 그다지 친숙하지 않습니다.
3. 아니요
4. TypeScript는 .d.ts 파일이 참조된 프로젝트가 파일을 빌드하는 위치에 있는지 찾습니다.

샘플 리포지토리가 있는 경우 해당 오류가 발생하는 이유를 진단할 수 있습니다.

@RyanCavanaugh 제발 해주세요
예.zip

@RyanCavanaugh , tsc --build --watch 소스 파일의 수정 사항을 볼 때까지 처음에는 파일을 출력하지 않는 것처럼 보입니다.

스레드가 너무 깁니다(시간과 공간 모두에서). Lucky Issue number 100 * 2^8 : #25600에서 토론을 시작합시다.