You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Imagine that we're writing a library in TypeScript and we're exporting some function called `doStuff` as part of our public API.
75
-
The function's types declare that it takes two `string`s so that other TypeScript users can get type-checking errors, but it also does a runtime check (maybe only in development builds) to give JavaScript users a helpful error.
74
+
TypeScript로 라이브러리를 작성하고 퍼블릭 API의 일부분으로 `doStuff`라는 함수를 export 한다고 상상해보세요.
75
+
TypeScript 사용자가 타입-체크 오류를 받을 수 있도록 `doStuff` 함수의 타입은 두 개의 `string`을 갖는다고 선언하지만, 또한 JavaScript 사용자에게 유용한 오류를 제공하기 위해 런타임 오류 체크를 합니다 (개발 빌드 시에만 가능).
76
76
77
77
```ts
78
78
function doStuff(abc:string, xyz:string) {
79
79
assert(typeofabc==="string");
80
80
assert(typeofxyz==="string");
81
81
82
-
//do some stuff
82
+
//어떤 작업을 하세요
83
83
}
84
84
```
85
85
86
-
So TypeScript users will get a helpful red squiggle and an error message when they misuse this function, and JavaScript users will get an assertion error.
87
-
We'd like to test this behavior, so we'll write a unit test.
86
+
그래서 TypeScript 사용자는 함수를 잘못 사용할 경우 유용한 빨간 오류 밑줄과 오류 메시지를 받게 되며, JavaScript 사용자는 단언 오류를 얻게 됩니다.
87
+
이러한 작동을 테스트하기 위해서, 유닛 테스트를 작성하겠습니다.
88
88
89
89
```ts
90
90
expect(() => {
91
91
doStuff(123, 456);
92
92
}).toThrow();
93
93
```
94
94
95
-
Unfortunately if our tests are written in TypeScript, TypeScript will give us an error!
95
+
불행히도 위의 테스트가 TypeScript에서 작성된다면, TypeScript는 오류를 발생시킬 것입니다!
96
96
97
97
```ts
98
98
doStuff(123, 456);
99
99
// ~~~
100
-
//error: Type 'number' is not assignable to type 'string'.
100
+
//오류: 'number' 타입은 'string' 타입에 할당할 수 없습니다.
101
101
```
102
102
103
-
That's why TypeScript 3.9 brings a new feature: `// @ts-expect-error`comments.
104
-
When a line is prefixed with a `// @ts-expect-error`comment, TypeScript will suppress that error from being reported;
105
-
but if there's no error, TypeScript will report that `// @ts-expect-error` wasn't necessary.
103
+
그래서 TypeScript 3.9는 새로운 기능을 도입했습니다: `// @ts-expect-error`주석.
104
+
라인 앞에 `// @ts-expect-error`주석이 붙어 있을 경우, TypeScript는 해당 오류를 보고하는 것을 멈춥니다;
105
+
그러나 오류가 존재하지 않으면, TypeScript는 `// @ts-expect-error`가 필요하지 않다고 보고할 것입니다.
106
106
107
-
As a quick example, the following code is okay
107
+
간단한 예로, 다음 코드는 괜찮습니다
108
108
109
109
```ts
110
110
// @ts-expect-error
111
111
console.log(47*"octopus");
112
112
```
113
113
114
-
while the following code
114
+
그러나 다음 코드는
115
115
116
116
```ts
117
117
// @ts-expect-error
118
118
console.log(1+1);
119
119
```
120
120
121
-
results in the error
121
+
오류로 이어질 것입니다
122
122
123
123
```
124
124
Unused '@ts-expect-error' directive.
125
125
```
126
126
127
-
We'd like to extend a big thanks to [Josh Goldberg](https://github.com/JoshuaKGoldberg), the contributor who implemented this feature.
128
-
For more information, you can take a look at [the `ts-expect-error` pull request](https://github.com/microsoft/TypeScript/pull/36014).
127
+
이 기능을 구현한 컨트리뷰터, [Josh Goldberg](https://github.com/JoshuaKGoldberg)에게 큰 감사를 드립니다.
128
+
자세한 내용은 [the `ts-expect-error` pull request](https://github.com/microsoft/TypeScript/pull/36014)를 참고하세요.
In some ways `// @ts-expect-error` can act as a suppression comment, similar to `// @ts-ignore`.
133
-
The difference is that `// @ts-ignore` will do nothing if the following line is error-free.
132
+
어떤 점에서는 `// @ts-expect-error`가 `// @ts-ignore`과 유사하게 억제 주석(suppression comment)으로 작용할 수 있습니다.
133
+
차이점은 `// @ts-ignore`는 다음 행에 오류가 없을 경우 아무것도 하지 않는다는 것입니다.
134
134
135
-
You might be tempted to switch existing `// @ts-ignore`comments over to `// @ts-expect-error`, and you might be wondering which is appropriate for future code.
136
-
While it's entirely up to you and your team, we have some ideas of which to pick in certain situations.
135
+
기존 `// @ts-ignore`주석을 `// @ts-expect-error`로 바꾸고 싶은 마음이 들 수 있으며, 향후 코드에 무엇이 적합한지 궁금할 수 있습니다.
136
+
전적으로 당신과 당신 팀의 선택이지만, 우리는 어떤 상황에서 어떤 것을 선택할 것인지에 대한 몇 가지 아이디어를 가지고 있습니다.
137
137
138
-
Pick `ts-expect-error` if:
138
+
다음 경우라면 `ts-expect-error`를 선택하세요:
139
139
140
-
*you're writing test code where you actually want the type system to error on an operation
141
-
*you expect a fix to be coming in fairly quickly and you just need a quick workaround
142
-
*you're in a reasonably-sized project with a proactive team that wants to remove suppression comments as soon affected code is valid again
140
+
*타입 시스템이 작동에 대한 오류를 발생시키는 테스트 코드 작성을 원하는 경우
141
+
*수정이 빨리 이루어지길 원하며 빠른 해결책이 필요한 경우
142
+
*오류가 발생한 코드가 다시 유효해지면 바로 억제 주석을 삭제하길 원하는 혁신적인 팀이 이끄는 적당한-크기의 프로젝트에서 작업하는 경우
143
143
144
-
Pick `ts-ignore` if:
144
+
다음 경우라면 `ts-ignore`를 선택하세요:
145
145
146
-
*you have an a larger project and and new errors have appeared in code with no clear owner
147
-
*you are in the middle of an upgrade between two different versions of TypeScript, and a line of code errors in one version but not another.
148
-
*you honestly don't have the time to decide which of these options is better.
146
+
*더 큰 프로젝트를 갖고 있고 코드에서 발생한 새로운 오류의 명확한 책임자를 찾기 힘든 경우
147
+
*TypeScript의 두 가지 버전 사이에서 업그레이드하는 중이고, 한 버전에서는 코드 오류가 발생하지만 나머지 버전에서는 그렇지 않은 경우
148
+
*솔직히 어떤 옵션 더 나은지 결정할 시간이 없는 경우
149
149
150
-
## Uncalled Function Checks in Conditional Expressions
150
+
## <spanid="uncalled-function-checks-in-conditional-expressions" /> 조건문에서 호출되지 않은 함수 체크 (Uncalled Function Checks in Conditional Expressions)
151
151
152
-
In TypeScript 3.7 we introduced *uncalled function checks* to report an error when you've forgotten to call a function.
152
+
TypeScript 3.7에서 함수 호출을 잊어버렸을 경우 오류를 보고하기 위해 *호출되지 않은 함수 체크*를 도입했습니다.
153
153
154
154
```ts
155
155
function hasImportantPermissions():boolean {
156
156
// ...
157
157
}
158
158
159
-
//Oops!
159
+
//이런!
160
160
if (hasImportantPermissions) {
161
161
// ~~~~~~~~~~~~~~~~~~~~~~~
162
-
//This condition will always return true since the function is always defined.
163
-
//Did you mean to call it instead?
162
+
//hasImportantPermissions 함수가 항상 정의되어 있기 때문에, 이 조건문은 항상 true를 반환합니다.
163
+
//대신 이것을 호출하려 하셨나요?
164
164
deleteAllTheImportantFiles();
165
165
}
166
166
```
167
167
168
-
However, this error only applied to conditions in `if`statements.
169
-
Thanks to [a pull request](https://github.com/microsoft/TypeScript/pull/36402) from [Alexander Tarasyuk](https://github.com/a-tarasyuk), this feature is also now supported in ternary conditionals (i.e. the `cond ? trueExpr : falseExpr`syntax).
168
+
그러나, 이 오류는 `if`문의 조건에만 적용됩니다.
169
+
[Alexander Tarasyuk](https://github.com/a-tarasyuk)의 [a pull request](https://github.com/microsoft/TypeScript/pull/36402) 덕분에, 이 기능은 삼항 조건 연산자도 지원하게 되었습니다 (예. `cond ? trueExpr : falseExpr`구문).
0 commit comments