라벨이 Typescript인 게시물 표시

JetBrains WebStorm에서 Reference된 tsconfig 프로젝트를 인식하지 못하는 문제

이미지
JetBrains WebStorm에서 Reference된 tsconfig 프로젝트를 인식하지 못하는 문제 WebStorm이 tsconfig.*.json을 인식하지 못함 제목을 한 줄로 정리하려니 참 머리가 아프다. 제목만 보고 무슨 문제인지 잘 감이 안 잡힐 수도 있겠다 싶어서 방금 내가 겪은 일을 간단히 요약하고 들어가겠다. electron-vite 프로젝트 구성 : npx create electron-vite 명령어로 electron-vite 프로젝트를 구성했다. JetBrains WebStorm에서 프로젝트 열기 : 구성된 프로젝트를 JetBrains WebStorm으로 열었다. tsconfig.web.json의 compilerOptions.paths 에 alias 추가 : @renderer/*, @lib/* 등 path aliases를 추가했다. 코드 자동완성으로 import 시도 : @lib/abc 를 import하려 하였으나 ../../lib/abc 가 임포트됨 🤬 시도해 본 방법들 WebStorm이 업데이트된지 얼마 되지 않았기에 혹시 업데이트 관련해서 문제가 생긴 것인지 확인하기 위해 tsconfig.json 자체에서 paths를 추가해봤더니 정상 작동했다. 그 상태에서 tsconfig.web.json 의 paths를 제거해봤다. 기존 절대 경로 임포트들에서 에러가 발생했다. (IDE 자체 에러) tsconfig.paths.json 을 만들고 tsconfig.json 및 tsconfig.web.json 에서 reference를 해봤다. IDE에서는 잘 작동하는 것처럼 보이지만 프로젝트 전체 구성에 문제가 발생해 개발 및 프로덕션에서 사용할 수 없었다. 올바른 해결 방법 우선 문제를 확실히 하기 위해 완전히 새로운 electron-vite 프로젝트를 만들고 내 tsconfig.web.json 과 비교해 봤더니 기본적으로 @renderer/* 경로가 paths에 추가되어 ...

puppeteer의 waitForXpath는 더 이상 사용되지 않는다. 대체 방법.

puppeteer의 waitForXpath는 더 이상 사용되지 않는다. Obsolete API - waitForXpath 조금 늦은 감이 있지만, 아무튼 Puppeteer 16.1.0 부터 waitForXpath 메서드 등 XPath 관련 독립 메서드들이 모두 더 이상 사용되지 않게 됐다. 그렇다고 더 이상 XPath를 사용하여 엘리먼트를 선택할 수 없는 것은 아니다. waitForSelector를 사용한 xpath 쿼리 이제부터는 waitForSelector를 사용해 xpath를 쿼리할 수 있다. 이렇게 하려면 셀렉터에 xpath/ prefix를 붙여주면 된다. await elementHandle . waitForSelector ( 'xpath/' + xpathExpression ) ; 즉 xpath/ 까지가 본체이고 이후에는 통상 xpath를 입력하면 된다는 말. 즉 ../input[@id='query'] 를 쿼리하고자 한다면 await elementHandle . waitForSelector ( 'xpath/../input[@id="query"]' ) ; 와 같이 사용하면 된다. //button[@type='submit'] 을 찾고자 한다면, 슬래쉬 세 개가 들어간다고 두려워하지 말고 await elementHandle . waitForSelector ( 'xpath///button[@type="submit"]' ) ; 과 같이 사용하면 된다. PuppeteerSharp puppeteer 의 C#용 포팅 라이브러리인 PuppeteerSharp 역시 이와 같은 변경 사항이 적용되었으니 같은 방식으로 사용하면 되겠다.

타입스크립트에서 이벤트 처리기 구현하기

타입스크립트에서 이벤트 처리기 구현하기 이벤트 처리 C#을 할 땐 이벤트 처리가 굉장히 간편했다. 언어 자체에서 event-driven 방식을 지원하기 때문이다. 자바스크립트(및 타입스크립트)를 처음 접했을 땐 당연히 자바스크립트에서도 이런 방식으로 손쉽게 이벤트 처리를 할 수 있을 줄 알았다. 그도 그럴 것이 NodeJS가 출시되지도 않았던 시절에 자바스크립트 하면 프론트엔드 개발에서 접할 수밖에 없었고, element.addEventListener 와 같은 메서드가 기본적으로 제공되었기 때문이다. 그러나 이런 추측은 반은 맞고 반은 틀렸다. NodeJS 이끌어가는 현 시대 자바스크립트 생태계에서 EventEmitter 클래스를 상속하여 손쉽게 이벤트 기반 클래스를 작성할 수 있기는 하다. 마찬가지로, 브라우저 단에서도 DOM 기반 클래스를 상속하면 대게 이벤트 처리가 가능하다. 여기까지 반이 맞고. 사용자 정의 프론트엔드 클래스에서 이벤트 핸들링 웹팩 이나 Vite 등을 사용해 번들링된 프론트엔드 코드가 있다고 치자. 물론, 바닐라 코드여도 마찬가지다. 아무튼 프론트엔드에서 특정 용도로 제작한 어떠한 클래스가 이벤트 기반으로 동작하게 하려면 어떻게 해야 할까? 여기가 반이 틀린 부분이다. 이런 경우에는 직접 EventEmitter 클래스를 제작하여 사용해야 한다. addEventListener , on , off , emit 등을 사용할 수 있게 만들기 위해 다음과 같은 코드를 짜서 상속해야 한다. export type IDisposable = { dispose ( ) : void ; } ; export type IListener < TEvent > = ( event : TEvent ) => void ; export type IEventEmitter < TEvent > = { emit : < TKey extends...

브라우저에서 사용할 간단한 로거 만들기

이미지
브라우저에서 사용할 간단한 로거 만들기 로깅 개발 단계에서든 프로덕션 단계에서든 로깅은 필수다. 각 단계마다 로그에 포함되는 정보의 차이는 있을지라도 로깅 기능이 없는 프로그램은 개인적으로 제대로 된 프로그램이 아니라고 생각한다. 디스코드의 로그 개발 단계에서는 더 상세한 로그를 작성하게 하여 번거롭게 브레이크포인트를 걸지 않고서 간단한 로직들이 제대로 돌아가는 중인지 확인할 수 있고, 프로덕션 단계에서는 문제가 발생할 경우 개발자가 사용자의 로그를 보고 어떤 문제가 어떻게 발생한 것인지 분석하는 데 사용할 수 있다. 로깅 라이브러리 이러한 로깅의 중요성 덕분에 언어를 막론하고 다양한 로깅 라이브러리가 꾸준히 업데이트되고 있다. C#에서는 NLog를, Java에서는 log4j를 사용했었는데, 이제는 NodeJS용 라이브러리를 찾아야만 했다. 검색하니 나오는 것들이 몇 개 있었는데, 그 중 Winston 라이브러리가 좋아 보여서 사용하려 했다. 그러나 실행해보니 process is undefined 관련 예외를 쓰로우하면서 정상적으로 작동하지 않았다. 설마 하는 마음에 이슈를 뒤져보니 윈스턴은 공식적으로 브라우저 로깅을 지원하지 않는다고 한다. 굳이 라이브러리를 써야 하나? 그러던 중 문득 의문이 들었다. 어차피 지금 하려는 작업은 로그를 DB에 전송하는 등의 복잡한 단계가 필요 없는 작업이다. 그냥 브라우저 콘솔에 디스코드마냥 로그를 출력해주면 되는 일이다. 단, 확장 프로그램에서 사용하는 로깅이기 때문에 콘텐츠 스크립트에서 로그를 작성할 경우 사이트 자체의 로그와 겹치지 않게 적절한 레이블을 출력해주면 된다. 이런 간단한 로거를 사용하자고 라이브러리를 추가해 사용하는 것은 낭비라는 생각이 뒤늦게 들었다. 직접 구현 그리고 나서 생각해 보니 구현에 시간이 그렇게 많이 들 것 같지 않았다. 예전이었다면 패키지를 찾기 전에 구현할 생각부터 했을 텐데 시간에 쫓기다 보니 패키지를 먼...

타입스크립트의 형변환

Typescript Type-Casting   타입스크립트는 타입이 존재하고, 이에 따라 당연히 타입 캐스팅 도 존재합니다. 타입 캐스팅을 한국어로 말하면 형변환 , 즉 형식을 변환하는 작업 입니다. Type Casting의 필요성   Javascript나 Lua 등, 형식을 명확히 지정하지 않아도 되는 언어를 사용하다가 Typescript나 C#, Java 등 형식을 명시해야 하는 언어를 사용하게 되면 언뜻 굳이 형변환이 필요한가? 라는 생각이 들 수도 있으나, 아주 조금만 코딩하다 보면 형변환의 필요성이 뼈저리게 느껴지게 될 겁니다.   가장 흔하고 좋은 예시는 데이터를 옮기는 상황 이라 할 수 있습니다.   이 포스트에서는 타입스크립트에 대해 말하고 있으므로 타입스크립트로 예를 들겠습니다. // 여러 형식이 담길 수 있는 변수 const variableData: string | string[] | null = "abc"; // string 데이터를 처리하는 메서드 function processString(str: string) { console.log(str); } // variableData에는 현재 string 타입의 데이터가 담겨 있으나 // processString에서는 이를 처리하지 못함. 왜? // processString은 string 형식의 인자를 가지지만 // variableData는 string | string[] | null 타입이기 때문 processString(variableData); // 컴파일 에러   바로 위와 같은 상황에서 타입 캐스팅을 사용할 수 있습니다. Typescript의 두 가지 형변환 방법   타입스크립트에는 두 가지 형변환 방법이 있습니다. 마치 C#의 Direct Casting 과 as, is operator  처럼요.   그러나 각각의 캐스팅 방식이 로직에 영향을 주는 C#과는 다르게 Typescript의 두 가지 형변환은 로직에...

Typescript Enum의 Key 반환받기, 모든 키/값 리스트 반환받기

Typescript의 enum 키워드 Typescript의 enum 키워드 여타 다른 언어와 같이, 타입스크립트의 enum 키워드 역시 열거형을 나타내기 위해 사용됩니다. 그리고 마찬가지로, 다른 언어와 같이 멤버의 값은 정수형으로 변환되게 됩니다. 예를 들어 다음과 같은 코드가 있을 때, enum TestEnum { A, B, C, D, E, } 각각의 값은 다음과 같이 나타납니다. > TestEnum.A 0 > TestEnum.B 1 > TestEnum.C 2 > TestEnum.D 3 > TestEnum.E 4 즉, 열거형의 첫 번째 멤버부터 0으로 시작해 순차적으로 증가하는 방식입니다. 물론, 값을 지정할 수도 있습니다. 다음과 같이요. enum TestEnum { A = 3 , B, C, D, E, } 혹은, 플래그 형식으로 사용하기 위해 다음과 같이 지정할 수도 있습니다. enum FlagEnum { NOTHING = 0 , FRIENDLY = 1 << 0 , HOSTILE = 1 << 1 , NEUTRAL = 1 << 2 , SPECIAL = 1 << 3 , ALL = ~(~ 0 << 4 ), } 열거형 필드는 number를 반환. 그렇다면 열거형의 이름을 반환하려면? 좋습니다. 열거형의 필드를 참조하면 열거형의 값, 즉 number 값이 반환되는 것은 알겠습니다. 하지만 열거형의 이름, 즉 A, B, C, D, E 각각을 반환받기 위해서는 어떻게 해야할까요? 공식...