From 28bbf38fd5d3e2cf41351745cd874e02d8d862b3 Mon Sep 17 00:00:00 2001 From: "guyeol, jeong" Date: Thu, 21 May 2020 01:33:18 +0900 Subject: [PATCH 1/8] =?UTF-8?q?project=20references=20=EB=B2=88=EC=97=AD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- pages/Project References.md | 188 ++++++++++++++++++------------------ 1 file changed, 94 insertions(+), 94 deletions(-) diff --git a/pages/Project References.md b/pages/Project References.md index 5e64dfa2..9bbb0edb 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -1,13 +1,13 @@ -Project references are a new feature in TypeScript 3.0 that allow you to structure your TypeScript programs into smaller pieces. +프로젝트 레퍼런스는 TypeScript 프로그램을 더 작은 조각으로 구조화하게 해주는 TypeScript 3.0의 새로운 기능입니다. -By doing this, you can greatly improve build times, enforce logical separation between components, and organize your code in new and better ways. +이 기능을 사용함으로써 빌드 시간을 크게 향상시킬 수 있고, 컴포넌트 사이의 논리적인 분리를 시행하며, 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다. -We're also introducing a new mode for `tsc`, the `--build` flag, that works hand in hand with project references to enable faster TypeScript builds. +TypeScript 빌드를 빠르게 하기 위해 프로젝트 레퍼런스와 함께 동작하는 `tsc`를 위한 새로운 모드인 `--build` 플래그를 소개합니다. -# An Example Project +# 예제 프로젝트 (An Example Project) -Let's look at a fairly normal program and see how project references can help us better organize it. -Imagine you have a project with two modules, `converter` and `units`, and a corresponding test file for each: +아주 일반적인 프로그램을 보고 프로젝트 레퍼런스가 어떻게 잘 구성할 수 있게 도와주는지 살펴보겠습니다. +`converter`와 `units`이라는 두 모듈이 프로젝트 안에 있고, 각 모듈에 대응되는 테스트 파일이 있다고 상상해봅시다: ```shell /src/converter.ts @@ -17,7 +17,7 @@ Imagine you have a project with two modules, `converter` and `units`, and a corr /tsconfig.json ``` -The test files import the implementation files and do some testing: +테스트 파일은 구현 파일을 import 하고 테스트를 진행합니다: ```ts // converter-tests.ts @@ -26,24 +26,24 @@ import * as converter from "../converter"; assert.areEqual(converter.celsiusToFahrenheit(0), 32); ``` -Previously, this structure was rather awkward to work with if you used a single tsconfig file: +이전에는 이 구조가 단일 tsconfig 파일을 사용했다면 어색하게 동작했습니다: -* It was possible for the implementation files to import the test files -* It wasn't possible to build `test` and `src` at the same time without having `src` appear in the output folder name, which you probably don't want -* Changing just the *internals* in the implementation files required *typechecking* the tests again, even though this wouldn't ever cause new errors -* Changing just the tests required typechecking the implementation again, even if nothing changed +* 구현 파일을 테스트 파일에 import 하는 것이 가능합니다 +* 아마도 원치 않았겠지만 `src`가 출력 폴더 이름에 나타나지 않고는 `test`와 `src`를 동시에 빌드 하는 것이 불가능합니다 +* 구현 파일 안에 *내용물* 만 바꿔도 새로운 오류를 절대 발생시키지 않지만 테스트 파일에 대한 *타입 검사*를 다시 해야 합니다 +* 테스트 파일만 바꿔도 아무 변화 없지만 구현 파일의 타입 검사를 다시 해야 합니다 -You could use multiple tsconfig files to solve *some* of those problems, but new ones would appear: +여러 개의 tsconfig 파일을 사용하여 이 문제들 중 *몇 가지*는 해결할 수 있지만, 새로운 문제가 발생합니다: -* There's no built-in up-to-date checking, so you end up always running `tsc` twice -* Invoking `tsc` twice incurs more startup time overhead -* `tsc -w` can't run on multiple config files at once +* 내장된 최신 검사가 없기 때문에, 항상 `tsc`를 두 번 실행해야 합니다 +* `tsc`를 두 번 호출하면 시작 시간 오버헤드가 더 많이 발생합니다 +* `tsc-w`는 한 번에 여러 config 파일을 실행할 수 없습니다 -Project references can solve all of these problems and more. +프로젝트 레퍼런스는 이 모든 문제를 해결할 수 있습니다. -# What is a Project Reference? +# 프로젝트 레퍼런스는 무엇인가? (What is a Project Reference?) -`tsconfig.json` files have a new top-level property, `references`. It's an array of objects that specifies projects to reference: +`tsconfig.json` 파일은 새로운 최상위-레벨 프로퍼티 `reference`를 가집니다. 이는 참조할 프로젝트를 지정하는 객체의 배열입니다: ```js { @@ -56,34 +56,34 @@ Project references can solve all of these problems and more. } ``` -The `path` property of each reference can point to a directory containing a `tsconfig.json` file, or to the config file itself (which may have any name). +각 참조의 `path` 프로퍼티는 `tsconfig.json` 파일을 가지는 디렉터리를 가리키거나, config 파일 자체(어떤 이름도 가질 수 있음)를 가리킵니다. -When you reference a project, new things happen: +프로젝트를 참조하면, 새로운 일이 일어납니다: -* Importing modules from a referenced project will instead load its *output* declaration file (`.d.ts`) -* If the referenced project produces an `outFile`, the output file `.d.ts` file's declarations will be visible in this project -* Build mode (see below) will automatically build the referenced project if needed +* 참조된 프로젝트에서 모듈을 import 하면 모듈의 *출력* 선언 파일을 대신 로드합니다 (`.d.ts`) +* 만약 참조된 프로젝트가 `outFile`를 생성하면, 출력 파일 `.d.ts` 파일의 선언은 이 프로젝트 안에서 노출됩니다 +* 빌드 모드(아래 참조)는 필요하다면 자동으로 참조된 프로젝트를 빌드 합니다 -By separating into multiple projects, you can greatly improve the speed of typechecking and compiling, reduce memory usage when using an editor, and improve enforcement of the logical groupings of your program. +여러 프로젝트로 분리하는 것은, 타입 검사와 컴파일 속도를 크게 향상시키고, 에디터를 사용할 때 메모리 사용량을 줄이며, 프로그램의 논리적 그룹화를 향상시킵니다. # `composite` -Referenced projects must have the new `composite` setting enabled. -This setting is needed to ensure TypeScript can quickly determine where to find the outputs of the referenced project. -Enabling the `composite` flag changes a few things: +참조 된 프로젝트는 반드시 새로운 `composite` 설정이 활성화되어야 합니다. +이 설정은 TypeScript가 참조된 프로젝트의 출력을 어디서 찾아야 할지 빠르게 결정하도록 하기 위해 필요합니다. +`composite` 플래그를 활성화하면 몇 가지가 변합니다: -* The `rootDir` setting, if not explicitly set, defaults to the directory containing the `tsconfig` file -* All implementation files must be matched by an `include` pattern or listed in the `files` array. If this constraint is violated, `tsc` will inform you which files weren't specified -* `declaration` must be turned on +* 만약 `rootDir` 설정이 명시적으로 지정되지 않으면, 기본 값은 `tsconfig` 파일을 가진 디렉터리입니다 +* 모든 구현 파일은 반드시 `include` 패턴에 맞거나 `files` 배열 안에 있어야 합니다. 만약 이 제약조건을 위반하면, `tsc`는 어떤 파일이 지정되지 않았는지 알려줍니다 +* `declaration`은 반드시 켜져 있어야 합니다 # `declarationMap`s -We've also added support for [declaration source maps](https://github.com/Microsoft/TypeScript/issues/14479). -If you enable `--declarationMap`, you'll be able to use editor features like "Go to Definition" and Rename to transparently navigate and edit code across project boundaries in supported editors. +[선언 소스 맵](https://github.com/Microsoft/TypeScript/issues/14479)에 대한 지원도 추가했습니다. +만약 `--declarationMap`을 활성화하면, "정의로 이동"과 이름 변경과 같은 에디터 기능을 사용하여 지원하는 에디터에서 투명하게 탐색하고 프로젝트 경계를 넘어 코드를 수정할 수 있습니다. -# `prepend` with `outFile` +# `prepend`와 `outFile` (`prepend` with `outFile`) -You can also enable prepending the output of a dependency using the `prepend` option in a reference: +레퍼런스에서 `prepend` 옵션을 사용하여 의존성의 출력을 덧붙이는 것을 활성화할 수 있습니다: ```js "references": [ @@ -91,11 +91,11 @@ You can also enable prepending the output of a dependency using the `prepend` op ] ``` -Prepending a project will include the project's output above the output of the current project. -This works for both `.js` files and `.d.ts` files, and source map files will also be emitted correctly. +프로젝트를 덧붙이는 것은 프로젝트의 출력을 현재 프로젝트의 출력 위에 포함시킵니다. +이는 `.js` 파일과 `.d.ts` 파일에 모두 동작하고, 소스맵 파일 역시 올바르게 방출됩니다. -`tsc` will only ever use existing files on disk to do this process, so it's possible to create a project where a correct output file can't be generated because some project's output would be present more than once in the resulting file. -For example: +`tsc`는 이 작업을 위해 디스크에 있는 기존 파일만 사용합니다, 그래서 어떤 프로젝트의 출력이 결과 파일에 한 번 이상 나타날 수 있기 때문에, 올바른 출력 파일이 생성될 수 없는 프로젝트를 생성하는 것이 가능합니다. +예를 들어: ```txt A @@ -107,103 +107,103 @@ B C D ``` -It's important in this situation to not prepend at each reference, because you'll end up with two copies of `A` in the output of `D` - this can lead to unexpected results. +이 상황에서 각 레퍼런스에 덧붙이지 않는 것이 중요한데, 왜냐하면 `D`의 출력에 `A`의 두 가지 복사본이 나오기 때문입니다 - 이는 예상치 못한 결과를 초래할 수 있습니다. -# Caveats for Project References +# 프로젝트 레퍼런스에 대한 주의사항 (Caveats for Project References) -Project references have a few trade-offs you should be aware of. +프로젝트 레퍼런스는 반드시 주의해야 할 몇 가지 트레이드오프가 있습니다. -Because dependent projects make use of `.d.ts` files that are built from their dependencies, you'll either have to check in certain build outputs *or* build a project after cloning it before you can navigate the project in an editor without seeing spurious errors. -We're working on a behind-the-scenes .d.ts generation process that should be able to mitigate this, but for now we recommend informing developers that they should build after cloning. +왜냐하면 의존성 있는 프로젝트는 의존성으로부터 빌드 된 `.d.ts` 파일을 사용하기 때문에, 에디터에서 잘못된 오류를 보지 않고 프로젝트를 탐색할 수 있기 전에 특정 빌드 출력을 검사하거나 *혹은* 클론 후 프로젝트를 빌드 해야 합니다. +이를 개선할 수 있는 .d.ts 생성 과정을 작업하고 있습니다만, 지금은 클론 이후에 빌드 하는 것을 개발자분들에게 추천드립니다. -Additionally, to preserve compatibility with existing build workflows, `tsc` will *not* automatically build dependencies unless invoked with the `--build` switch. -Let's learn more about `--build`. +추가적으로, 기존 빌드 작업 흐름과의 호환성을 유지하기 위해, `tsc`는 `--build` 스위치를 호출하지 않는 한 자동으로 의존성 빌드를 하지 *않습니다*. +`--build`에 대해 배워봅시다. -# Build Mode for TypeScript +# TypeScript를 위한 빌드 모드 (Build Mode for TypeScript) -A long-awaited feature is smart incremental builds for TypeScript projects. -In 3.0 you can use the `--build` flag with `tsc`. -This is effectively a new entry point for `tsc` that behaves more like a build orchestrator than a simple compiler. +오래 기다린 기능은 TypeScirpt 프로젝트를 위한 똑똑한 증분 빌드입니다. +3.0에서 `tsc`에서 `--build` 플래그를 사용할 수 있게 되었습니다. +이것은 단순한 컴파일러보다 빌드 관리자처럼 동작하는 `tsc`의 새로운 진입점입니다. -Running `tsc --build` (`tsc -b` for short) will do the following: +`tsc --build` (약식은 `tsc -b`)를 실행하면 다음의 작업을 합니다: -* Find all referenced projects -* Detect if they are up-to-date -* Build out-of-date projects in the correct order +* 참조된 모든 프로젝트를 찾습니다 +* 최신 상태인지 감지합니다 +* 올바른 순서로 최신 상태가 아닌 프로젝트를 빌드 합니다 -You can provide `tsc -b` with multiple config file paths (e.g. `tsc -b src test`). -Just like `tsc -p`, specifying the config file name itself is unnecessary if it's named `tsconfig.json`. +`tsc -b`에 여러 config 파일 경로를 제공할 수 있습니다 (예를 들어. `tsc -b src test`). +`tsc -p`처럼, 만약 config 파일 이름이 `tsconfig.json`이라면 이름을 지정하지 않아도 됩니다. -## `tsc -b` Commandline +## `tsc -b` 명령줄 (`tsc -b` Commandline) -You can specify any number of config files: +config 파일을 원하는 만큼 지정할 수 있습니다: ```shell - > tsc -b # Use the tsconfig.json in the current directory - > tsc -b src # Use src/tsconfig.json - > tsc -b foo/prd.tsconfig.json bar # Use foo/prd.tsconfig.json and bar/tsconfig.json + > tsc -b # 현재 디렉터리에 있는 tsconfig.json 사용 + > tsc -b src # src/tsconfig.json 사용 + > tsc -b foo/prd.tsconfig.json bar # foo/prd.tsconfig.json 와 bar/tsconfig.json 사용 ``` -Don't worry about ordering the files you pass on the commandline - `tsc` will re-order them if needed so that dependencies are always built first. +명령줄에 전달한 파일의 순서에 대해서는 걱정하지 마세요 - `tsc`가 필요하면 재배열하기 때문에 의존성이 언제나 먼저 빌드 됩니다. -There are also some flags specific to `tsc -b`: +`tsc -b`에 지정할 수 있는 몇 가지 플래그들이 더 있습니다: -* `--verbose`: Prints out verbose logging to explain what's going on (may be combined with any other flag) -* `--dry`: Shows what would be done but doesn't actually build anything -* `--clean`: Deletes the outputs of the specified projects (may be combined with `--dry`) -* `--force`: Act as if all projects are out of date -* `--watch`: Watch mode (may not be combined with any flag except `--verbose`) +* `--verbose`: 어떻게 진행되고 있는지 자세한 로그를 출력해 줍니다 (다른 플래그와 결합할 수 있습니다) +* `--dry`: 실제로 빌드 하지 않지만 어떻게 될지 보여줍니다 +* `--clean`: 지정된 프로젝트의 출력을 제거합니다 (`--dry`와 결합할 수 있습니다) +* `--force`: 모든 프로젝트가 최신이 아닌 것처럼 동작합니다 +* `--watch`: 감시 모드 (`--verbose`를 제외한 다른 플래그와는 결합할 수 없습니다) -# Caveats +# 주의사항 (Caveats) -Normally, `tsc` will produce outputs (`.js` and `.d.ts`) in the presence of syntax or type errors, unless `noEmitOnError` is on. -Doing this in an incremental build system would be very bad - if one of your out-of-date dependencies had a new error, you'd only see it *once* because a subsequent build would skip building the now up-to-date project. -For this reason, `tsc -b` effectively acts as if `noEmitOnError` is enabled for all projects. +일반적으로, `tsc`는 `noEmitOnError`가 활성화되어있지 않으면, 구문 또는 타입 오류가 있을 때 출력 (`.js`와 `.d.ts`)을 생성합니다. +이것을 증분 빌드 시스템에서 하는 것은 매우 안 좋습니다 - 만약 최신 상태가 아닌 의존성 중 하나가 새로운 오류가 있으면, 다음 빌드가 현재 최신 상태인 프로젝트를 빌드 하는 것을 건너뛸 것이기 때문에, *한번* 만 볼 수 있습니다. +이 이유로, `tsc -b`는 `noEmitOnError`가 모든 프로젝트에서 활성화된 것처럼 효과적으로 동작합니다. -If you check in any build outputs (`.js`, `.d.ts`, `.d.ts.map`, etc.), you may need to run a `--force` build after certain source control operations depending on whether your source control tool preserves timestamps between the local copy and the remote copy. +아무 빌드 출력 (`.js`, `.d.ts`, `.d.ts.map`, 등)을 검사하는 경우, 소스 제어 도구가 로컬 사본과 원격 사본 사이의 타임스탬프를 보존하는지에 따라 특정 소스 제어 연산 후에 `--force` 빌드를 실행해야 할 수도 있습니다. # MSBuild -If you have an msbuild project, you can enable build mode by adding +만약 msbuild 프로젝트가 있으면, 다음을 추가하여 빌드 모드를 proj 파일에 ```xml true ``` -to your proj file. This will enable automatic incremental build as well as cleaning. +활성화할 수 있습니다. 이는 제거뿐만 아니라 자동 증분 빌드를 활성화합니다. -Note that as with `tsconfig.json` / `-p`, existing TypeScript project properties will not be respected - all settings should be managed using your tsconfig file. +`tsconfig.json` / `-p`와 마찬가지로, 기존 TypeScript 프로젝트 프로퍼티는 고려되지 않음에 유의하십시오 - 모든 설정은 tsconfig 파일을 사용하여 관리해야 합니다. -Some teams have set up msbuild-based workflows wherein tsconfig files have the same *implicit* graph ordering as the managed projects they are paired with. -If your solution is like this, you can continue to use `msbuild` with `tsc -p` along with project references; these are fully interoperable. +일부 팀들은 tsconfig 파일들이 함께 병행하여 관리되는 프로젝트와 같은 *암시적* 그래프 순서를 가지며 msbuild 기반의 작업 흐름을 설정했습니다. +만약 해결책이 이와 같다면, 프로젝트 레퍼런스와 함께 `msbuild`를 `tsc -p`와 계속 사용할 수 있습니다; 이들은 완전히 상호 운용 가능합니다. -# Guidance +# 안내 (Guidance) -## Overall Structure +## 전체 구조 (Overall Structure) -With more `tsconfig.json` files, you'll usually want to use [Configuration file inheritance](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) to centralize your common compiler options. -This way you can change a setting in one file rather than having to edit multiple files. +더 많은 `tsconfig.json` 파일과 함께, 공통의 컴파일러 옵션들을 중앙 통제하기 위해 [구성 파일 상속](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)을 사용하고 싶으실 겁니다. +이 방법으로 여러 파일을 수정하지 않고 한 파일에서 설정을 변경할 수 있습니다. -Another good practice is to have a "solution" `tsconfig.json` file that simply has `references` to all of your leaf-node projects and sets `files` to an empty array (otherwise the solution file will cause double compilation of files). Note that starting with 3.0, it is no longer an error to have an empty `files` array if you have at least one `reference` in a `tsconfig.json` file. +또 다른 좋은 방법은 단순히 모든 리프-노드 프로젝트에 `references`를 가지고 `files`를 빈 배열로 설정하는 "솔루션" `tsconfig.json` 파일을 갖는 것입니다 (그렇지 않으면 솔루션 파일 때문에 파일이 두 번 컴파일됩니다). 3.0부터 적어도 하나의 `reference`가 `tsconfig.json`에 있으면, 빈 `files` 배열을 갖는 것은 더 이상 오류가 아님에 유의하세요. -This presents a simple entry point; e.g. in the TypeScript repo we simply run `tsc -b src` to build all endpoints because we list all the subprojects in `src/tsconfig.json` +이는 간단한 진입점을 제공합니다; 예를 들어, TypeScript 저장소에서 `src/tsconfig.json` 안에 모든 하위 프로젝트를 나열하기 때문에 단순히 `tsc -b src` 실행하여 모든 엔드포인트를 빌드 합니다. -You can see these patterns in the TypeScript repo - see `src/tsconfig_base.json`, `src/tsconfig.json`, and `src/tsc/tsconfig.json` as key examples. +이 패턴들은 TypeScript 저장소에서 볼 수 있습니다 - 주 예제로 `src/tsconfig_base.json`, `src/tsconfig.json`, 그리고 `src/tsc/tsconfig.json`를 보세요. -## Structuring for relative modules +## 상대 모듈 구조화하기 (Structuring for relative modules) -In general, not much is needed to transition a repo using relative modules. -Simply place a `tsconfig.json` file in each subdirectory of a given parent folder, and add `reference`s to these config files to match the intended layering of the program. -You will need to either set the `outDir` to an explicit subfolder of the output folder, or set the `rootDir` to the common root of all project folders. +일반적으로, 상대 모듈을 사용하여 저장소를 전환하는 데에는 별 다른 것이 필요 없습니다. +간단하게 부모 폴더의 `tsconfig.json` 파일을 각 하위 디렉터리 안에 위치시키고, 프로그램의 의도된 계층과 일치하도록 `reference`를 이 config 파일에 추가하십시오. +`outDir`을 출력 폴더의 명시적인 하위 폴더로 설정하거나, `rootDir`을 모든 프로젝트 폴더의 공통 루트로 설정해야 합니다. -## Structuring for outFiles +## outFiles 구조화하기 (Structuring for outFiles) -Layout for compilations using `outFile` is more flexible because relative paths don't matter as much. -One thing to keep in mind is that you'll generally want to not use `prepend` until the "last" project - this will improve build times and reduce the amount of I/O needed in any given build. -The TypeScript repo itself is a good reference here - we have some "library" projects and some "endpoint" projects; "endpoint" projects are kept as small as possible and pull in only the libraries they need. +`outFile`을 사용한 컴파일의 레이아웃은 상대 경로가 크게 중요하지 않기 때문에 더 유연합니다. +기억해야 할 한 가지는 "마지막" 프로젝트 전까지는 `prepend`를 사용하고 싶지 않다는 것입니다 - 이는 빌드 시간을 개선하고 주어진 빌드에 필요한 I/O 숫자를 줄여줄 것입니다. +TypeScript 저장소 자체는 여기서 좋은 레퍼런스입니다 - 몇 가지 "라이브러리" 프로젝트와 "엔드포인트" 프로젝트가 있습니다: "엔드포인트" 프로젝트는 가능한 작게 유지되고 있고 필요한 라이브러리만 pull 합니다. +--> \ No newline at end of file From 038052d575ea7f00b6ece143ba5986de5120d09b Mon Sep 17 00:00:00 2001 From: GuyeolJeong Date: Mon, 25 May 2020 10:49:35 +0900 Subject: [PATCH 2/8] Update pages/Project References.md Co-authored-by: YeonJuan --- pages/Project References.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/Project References.md b/pages/Project References.md index 9bbb0edb..15e85f85 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -1,6 +1,6 @@ 프로젝트 레퍼런스는 TypeScript 프로그램을 더 작은 조각으로 구조화하게 해주는 TypeScript 3.0의 새로운 기능입니다. -이 기능을 사용함으로써 빌드 시간을 크게 향상시킬 수 있고, 컴포넌트 사이의 논리적인 분리를 시행하며, 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다. +이를 통해, 빌드 시간을 크게 개선하고, 컴포넌트 사이의 논리적인 분리를 강제하여 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다. TypeScript 빌드를 빠르게 하기 위해 프로젝트 레퍼런스와 함께 동작하는 `tsc`를 위한 새로운 모드인 `--build` 플래그를 소개합니다. @@ -206,4 +206,4 @@ TypeScript 저장소 자체는 여기서 좋은 레퍼런스입니다 - 몇 가 ## Structuring for monorepos TODO: Experiment more and figure this out. Rush and Lerna seem to have different models that imply different things on our end ---> \ No newline at end of file +--> From 76145b706c95c833a7c83445f2e7192b8afc7197 Mon Sep 17 00:00:00 2001 From: GuyeolJeong Date: Mon, 25 May 2020 10:49:50 +0900 Subject: [PATCH 3/8] Update pages/Project References.md Co-authored-by: YeonJuan --- pages/Project References.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/Project References.md b/pages/Project References.md index 15e85f85..3fd940e3 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -2,7 +2,7 @@ 이를 통해, 빌드 시간을 크게 개선하고, 컴포넌트 사이의 논리적인 분리를 강제하여 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다. -TypeScript 빌드를 빠르게 하기 위해 프로젝트 레퍼런스와 함께 동작하는 `tsc`를 위한 새로운 모드인 `--build` 플래그를 소개합니다. +또한, 빠른 TypeScript 빌드를 위해 프로젝트 레퍼런스와 함께 동작하는 `tsc` 의 새로운 모드인 `--build` 플래그를 도입했습니다. # 예제 프로젝트 (An Example Project) From 3c69b78d9d962d16e7b38dac37e92979ec9c8c0c Mon Sep 17 00:00:00 2001 From: GuyeolJeong Date: Mon, 25 May 2020 10:50:12 +0900 Subject: [PATCH 4/8] Update pages/Project References.md Co-authored-by: YeonJuan --- pages/Project References.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/Project References.md b/pages/Project References.md index 3fd940e3..0db25818 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -144,7 +144,7 @@ config 파일을 원하는 만큼 지정할 수 있습니다: > tsc -b foo/prd.tsconfig.json bar # foo/prd.tsconfig.json 와 bar/tsconfig.json 사용 ``` -명령줄에 전달한 파일의 순서에 대해서는 걱정하지 마세요 - `tsc`가 필요하면 재배열하기 때문에 의존성이 언제나 먼저 빌드 됩니다. +명령줄에 전달한 파일의 순서에 대해서는 걱정하지 마세요 - 필요하면 `tsc`가 재배열하기 때문에 의존성이 언제나 먼저 빌드 됩니다. `tsc -b`에 지정할 수 있는 몇 가지 플래그들이 더 있습니다: From 8fc3a24dc566d16108a535b6d9d0f92c7d17a648 Mon Sep 17 00:00:00 2001 From: GuyeolJeong Date: Mon, 25 May 2020 10:50:33 +0900 Subject: [PATCH 5/8] Update pages/Project References.md Co-authored-by: YeonJuan --- pages/Project References.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/Project References.md b/pages/Project References.md index 0db25818..8624d936 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -1,4 +1,4 @@ -프로젝트 레퍼런스는 TypeScript 프로그램을 더 작은 조각으로 구조화하게 해주는 TypeScript 3.0의 새로운 기능입니다. +프로젝트 레퍼런스는 TypeScript 프로그램을 더 작은 조각으로 구성할 수 있는 TypeScript 3.0의 새로운 기능입니다. 이를 통해, 빌드 시간을 크게 개선하고, 컴포넌트 사이의 논리적인 분리를 강제하여 코드를 새롭고 더 나은 방법으로 구성할 수 있습니다. From 2eae0cf79c13610573e9e723c2c7d2295924eaff Mon Sep 17 00:00:00 2001 From: GuyeolJeong Date: Mon, 25 May 2020 10:52:33 +0900 Subject: [PATCH 6/8] Update pages/Project References.md Co-authored-by: Seohee Park --- pages/Project References.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/Project References.md b/pages/Project References.md index 8624d936..b4e0dcbc 100644 --- a/pages/Project References.md +++ b/pages/Project References.md @@ -200,7 +200,7 @@ config 파일을 원하는 만큼 지정할 수 있습니다: `outFile`을 사용한 컴파일의 레이아웃은 상대 경로가 크게 중요하지 않기 때문에 더 유연합니다. 기억해야 할 한 가지는 "마지막" 프로젝트 전까지는 `prepend`를 사용하고 싶지 않다는 것입니다 - 이는 빌드 시간을 개선하고 주어진 빌드에 필요한 I/O 숫자를 줄여줄 것입니다. -TypeScript 저장소 자체는 여기서 좋은 레퍼런스입니다 - 몇 가지 "라이브러리" 프로젝트와 "엔드포인트" 프로젝트가 있습니다: "엔드포인트" 프로젝트는 가능한 작게 유지되고 있고 필요한 라이브러리만 pull 합니다. +TypeScript 저장소 자체는 여기서 좋은 레퍼런스입니다 - 몇 가지 "라이브러리" 프로젝트와 "엔드포인트" 프로젝트가 있습니다; "엔드포인트" 프로젝트는 가능한 작게 유지되고 있고 필요한 라이브러리만 pull 합니다.