프로젝트 세팅
패키지 관리자 설치
어제 패키지 매니저에 관한 글을 올렸는데,
옛날 프로젝트라 그런지, 패키지를 설치하자마자 초창부터 무수한 에러가 발생했다.
(밑에 사진은 경고 메시지긴 하지만..)
그래서 package.json을 보니까 nodejs 14 버전을 사용하고 있었다.
아주 패키지 매니저의 중요성을 바로 체감하게 해줌
해당 프로젝트에서만 가상으로 14버전을 사용하는 방법은 없나, 하고 찾아봤는데.
nvm(nodejs version manager)을 활용하면
nodejs 버전을 여러 개 관리해서 프로젝트별로 nodejs를 사용할 수 있다고 한다.
nvm 레포로 가서 setup.exe 파일을 받아준 후nvm install 14로 nodejs 14버전을 받아줬다.
하지만 그렇게 호락호락 하지 않져?
계속 이런 zip: The system cannot find the file specified.
오류가 발생해서 검색해보니,
이 글에 따르면 과거 버전으로 설치해서 다시 해보랜다.
그래서 지우고 다시 v1.1.12으로 설치했다.
Downloading node.js version 14.21.3 (64-bit)...
Complete
Creating C:\Users\dd\AppData\Roaming\nvm\temp
Downloading npm version 6.14.18... Complete
Installing npm v6.14.18...
Installation complete. If you want to use this version, type
nvm use 14.21.3음 ~ 이제야 제대로 깔렸다.
그럼 nvm ls 명령어로 어떤 버전의 nodejs가 깔려있는지 확인해보자.
원래 있던 22버전과 지금 새로 깐 14버전 모두 잘 들어와는걸 볼 수 있다.
그럼 이제 14 버전을 사용할 일만 남았으니~nvm use 14 로 해당 프로젝트에서 14버전을 사용한다고 얘기해주자.
마지막으로 nvm current 로 현재 사용하는 버전이 몇인지 다시 확인해주면?
이렇게 아까 use로 명시한 버전(v14.21.3)이 뜬다.
그러고 이제 평소에 사용하듯npm install 로 패키지 설치하고, npm run dev로 로컬에서 돌려보고..
사용하면 된다.
지금 실시간으로 패키지 설치하면서 글을 적고 있는 중인데,
진짜 느리다. 덜덜
옛날엔 진짜 이렇게 차이가 컸구나.......
API 설정
원본 레포의 readme를 읽어보면
For convenience, we have a live API server running at https://conduit.productionready.io/api for the application to make requests against. You can view the API spec here which contains all routes & responses for the server.
The source code for the backend server (available for Node, Rails and Django) can be found in the main RealWorld repo.
If you want to change the API URL to a local server, simply edit lib/utils/constant.js and change SERVER_BASE_URL to the local server's URL (i.e. localhost:3000/api)
이 곳에서 api를 제공해주기에 자동으로 백엔드를 사용할 수 있다고 적혀있다.
하지만 몇 년 사이에 뭔가 바뀐건지, 사이트에 들어가면 1016 에러가 발생한다.
그래서 이슈를 보는데 어떤 분께서 api 주소를 수정한 PR을 올려주셨길래lib/utils/constant에서 해당 주소로 다시 설정해줬다.
근데 이 주소로 들어가도 1016 에러만 뜰 뿐, 아무것도 안 뜬다.
왜 그런지 이슈를 찾아봤는데
https://github.com/gothinkster/realworld/issues/1611
으아닛..... 이제는 다 삭제됐다고 한다..................
그래서 로컬에서 백엔드 서버를 동시에 돌려주기로 결심하고
Docker를 활용했다.
Docker에서 해당 명령어 docker run -d -p 8000:8000 --name realworld-backend realworldio/django-drf 를 입력하면
알아서 django로 로컬 서버가 돌아간다.
django 프로젝트가 docker 허브에 올라가져 있기 때문에
저 명령어 하나만으로 내가 바로 백엔드 서버를 실행할 수 있는거구.. 그렇다.
근데 그렇게 또 호락호락하게 바로 되지 않죠?
서버를 실행했는데 프론트딴에서 CORS 오류가 났다.
보니까 settings 파일에 localhost를 4000번만 허용해 놓아서 오류가 발생한 것 같았다.
그래서 3000번을 추가했는데,
그래도 안돼서.CORS_ALLOW_ALL_ORIGINS = True 로 모든 접근을 허용시켰다.
그래도 또 안돼서 ^^^^
그냥 프론트 로컬 주소를 4000번으로 바꿨다.
드디어 CORS 오류가 안 뜬다.
하...................................
대체 왜 안된거지.. docker에서 변경한 사항이 제대로 반영이 안 된건가?
아무리 리스타트를 하고 컴을 껐다 켜도 안돼서 그냥 프론트 로컬 주소를 바꿨더니
1초만에 되는게 진짜 눈물남
docker를 오늘 처음 써봐서
아주 짤막하게 공부를 해봤는데,
도커는 마치 구워진 CD 같은 존재라고 한다.내가 CD를 직접 구운 세대는 아니지만.. 변명하는거 아님. 쨌든 아님
CD를 한 번 구우면 수정하기 어렵지 않는가?
도커도 마찬가지다.
그래서 내가 따로 수정한 사항을
컨테이너에 바로 반영되게 하고 싶다면
볼륨 옵션을 줘야한다.
볼륨 옵션이란
케이블처럼 내가 변경한 사항을 바로 바로 변경할 수 있도록 도와주는거라고 한다.
내일 좀 더 자세히 알아봐야지
하 쨌든 뭐든 일단 해결돼서 속이 후련하다 앗사
tsconfig 설정
tsconfig를 보면 "suppressImplicitAnyIndexErrors": true 설정이 있는데,
해당 라인에 빨간줄이 그어져있다.
뭔 설정이길래 지금은 지원하지 않는걸까?
TypeScript에서는 객체에 접근할 때
해당 키가 실제 타입 정의에 없으면 오류를 발생한다.
예를 들어 아래와 같은 코드가 있다고 하자.
const obj = { x: 10 };
console.log(obj["foo"]);이 때 "foo" 라는 키가 obj에 없는데,
로그로 이를 불러오고 있으니
typescript에선 아래와 같은 오류를 발생시킨다.
Element implicitly has an 'any' type because expression of type '"foo"' can't be used to index type '{ x: number; }'.근데 suppressImplicitAnyIndexErrors 값을 True로 설정하면,
객체에 존재하지 않는 키에 접근해도 타입 에러를 무시할 수 있다.
왜 옛날엔 이렇게 설정해도 됐었고,
지금은 이렇게 설정하면 안되는걸까?
js를 ts로 마이그레이션할 때 발생하는 불편함을
일시적으로 해소하기 위한 편의 기능이었지만,
TypeScript의 핵심 가치인 타입 안전성을 저해한다는 이유로
현재는 더 이상 지원되지 않는다고 한다.
지금은 index signature로 객체의 타입을 명시적으로 나타내주는게
ts의 권장 방식이다.
interface User {
name: string;
[key: string]: number; // index signature
}맺음말
비하인드
와 도커 설치하는데만 뭔 한시간 걸려서
노트북 껐다 켰는데 갑자기 무한 로딩 걸려서
옛날에 윈도우 지옥의 로딩이 생각났다
넘모 무서워요......
그리고 CORS 오류 날 때 프론트딴에서 config 설정해보고
다하는데 해당 프로젝트 next 버전이 9여서 뭘 할 수가 없어서
그냥 눈물만 흘리다 해결되니까 속이 뻥 뚫렸다