개발하는 리트리버

0. 서론

프로젝트 받고 가장 먼저 npm install, yarn 등을 통해 필요한 패키지들을 node_modules파일에 모은다.

보통 문제없이 잘 작동하기 때문에 node_modules파일 안에 있는 내용은 수정할 일이 별로 없다.

근데 만약에 node_modules 내부 코드에 문제가 있으면 어떻게 해야할까?

내가 사용하는 특정 버전에서 다른 모듈과의 호환성 문제가 되거나 하는 상황이 펼쳐진다면 어떻게 해야할까?

버전 사용 이전에 그러한 부분들을 미리 체크하고, 필요하다면 버전을 업그레이드 하는게 제일 최선의 방법일 것이다. 하지만 모든 상황에서 버전 업그레이드가 쉽지는 않다. 내가 접한 것은 react-native와 Xcode 버전간의 문제였다.

react-native의 버전을 최신으로 올려서 문제를 해결해라고들 하지만, 그러기에 react-native 버전이 기존에 너무 낮았기에, 이를 최신버전으로 업그레이드 하는건 배보다 배꼽이 더 커지는? 일이 되어버리는 것이다. 그러다가 찾은 하나의 빛이, node_modules에 있는 react-native에서 특정 파일을 수정하라는 해결책이었다. 특정파일을 수정하고나니 정상적인 빌드가 가능했다.

그런데.. 이를 git에 어찌 반영해야하는가..? node_modules을 앞으로 계속 다 올려...야 하나?? (말도안되는) 이럴때 우리에게 한줄기 빛이 되어주는 것이 바로 patch-package되시겠다.

patch-package는 node_modules 속 커스텀한 상황을 배포상태에서 반영할 수 있게 해준다. 

1. 설치

//package.json

"script" : {
	"postinstall": "patch-package"
},

위에 라인을 추가해주고 $ yarn i patch-package 를 통해서 다운로드 해준다. 그럼 사용할 세팅 준비는 끝이난다.

2. 사용

이제 node_modules  내에서 수정하고 싶은 파일을 수정해준다.

나의 경우 node_modules에 있는 react-native 폴더 안에 있는 특정 코드를 수정했다.

그리고 나서 아래 명령어를 추가해준다. 

$ yarn patch-package react-native(내가 수정한 라이브러리 이름) 

그러고 나면 루트 폴더에 patches라는 폴더가 새로 생기고 해당 폴더 안에 수정한 패키지에 대한 정보가 들어간다!!

이제 yarn 인스톨 시점에 자동으로 node_modules를 덮어쓰게 된다!! 이제 이 폴더를 git에 올려주면 모두가 같은 수정사항을 공유할 수 있게 된다. 올리기 전에 node_modules를 지우고 yarn혹은 npm install을 통해 반영이 잘되는지 한번 더 체크해주는 센스!

4. 결론

패키지 의존 문제가 생기면 해결되기까지 기다리거나 버전 자체를 바꾸는 등의 방법 외에도, 

의존성을 유지하면서 이렇게 직접 수정해서 사용할 수 있다. 좀 더 손쉽게 문제를 타파하는 대안이 될 수 있지 않나 싶다!

역시 Xcode랑 react-native는 친해지기 어렵다!

ld: symbol(s) not found for architecture arm64

clang: error: linker command failed with exit code 1 

행복한 일상을 괴롭혔던 iOS빌드 이야기...

해당 에러가 발생하면서 Archieve Failed가 발생했다.

검색해보니 상당히 많은 경우의 수와

또 그에 따른 많은 해결책들이 난무했다.

진짜 한 10개 넘는 방식의 해결책들을 시도했는데.. (이하생략)

여러 원인과 해결책들이 있는걸로 보아,

여러 상황에서 저 에러가 나오는 것같다..

(고로 에러 전에 무슨 단계였는지를 체크해서 해결 방법을 찾아나서는게..!)

나의 경우 Linking 관련된 명령어 실행 중에

해당 에러가 발생해서 Linking 관련된 해결책들을 찾다가,

Xcode - Build Settings - Linking에서 

'Mach-O Type'을 Static Library로 수정하고 나니

빌드 성공..?!

근데 Mach-O가 뭐지?

Mach-O (Mach Object file format)

Mach-O는 파일 포맷으로

macOS, iOS 운영체제에서 실행 파일, 오브젝트 코드, 공유 라이브러리, 코어 덤프 등을 위한 형식이라고 한다.

줄이면 apple관련 OS에서 동작하는 프로그램을 위한 파일 포맷이라 할 수 있겠다!

오브젝트 파일(.o), 동적파일(.dylib), 정적파일(.a), 번들(.bundle)등이 다 Mach-O인것!!

여기서 Mach-O Type 설정은 타겟에 대해 생성할 바이너리의 유형을 지정한다고 한다.

설정 내용은 아래와 같다. 

• Executable: 운영 체제가 실행할 수 있는 독립 실행형 바이너리.
• Dynamic Library: 런타임에 로드될 수 있는 공유 라이브러리.
• Static Library: 컴파일 시점에 최종 실행 파일에 직접 포함되는 라이브러리.
• Bundle: 다른 실행 파일이나 라이브러리에 의해 런타임에 로드되는 특수한 유형의 동적 라이브러리

나의 경우 Static Library 설정하고 나서

경로 문제로 받아오지 못하는 CoreAudioTypes을 패스하고

빌드시점에 포함된 라이브러리만 가져왔 때문에

빌드 에러가 없어졌던것이다..!

고로.. 근원적인 해결책은 못한거라고 봐야겠나ㅠ

하지만 검색해보니 해당 라이브러리(플랫폼이라고 표현하는)는 이제 기본이라 따로

import 할 필요 없다고도 하는데.. 좀 더 확인해 봐야겠다.

맥북 마이그레이션 이후에

일반 터미널에서는 문제가 없었는데,

visual studio code에서만 유독 위와 같은 문제가 발생했다.

compinit:480: compdump: function definition file not found

.zshrc:188: add-zsh-hook: function definition file not found

zsh brew로 재설치후

zshrc 파일에 compinit과 bashcompinit 부분을 추가해주고나니

해결완료!

export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="robbyrussell"

source $ZSH/oh-my-zsh.sh

autoload -Uz compinit
compinit

autoload -U bashcompinit
bashcompinit

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

CRUD 정의

CRUD 는 약자로 아래의 함수(기능)을 의미한다.

Create

Read

Update

Delete

너무나도 쉬운 영단어로 되어있다.

이러한 기원은 데이터베이스에 있다고 한다.

이는 SQL에서는

Create = INSERT

Read  = SELECT

Update = UPDATE

Delete = DELETE

로 생각하면 된다. 

어떤 item에 대해서 CRUD개발, 이라고 한다면

해당 아이템을 만들고, 수정하고 지우기까지 하는 작업들을 의미한다고 보면 된다.

REST 정의

REST는 네트워크 애플리케이션 설계를 위한 아키텍처 스타일이며

HTTP 프로토콜이 사용된다. 

우리가 익숙한 GET, POST, PUT, DELETE가 여기에 포함된다.

둘의 차이점?

그럼 REST와는 차이 점이 있을까?

범위

CRUD는 4개의 기능(함수)을 이야기한다.

REST는 네트워크 리소스를 설계하고 상호 작용하는 방법을 정의하는 더 넓은 아키텍처 스타일이다.

작용범위

CRUD는 데이터 베이스와 작동한다.

REST는 HTTP 메서드를 사용하여 CRUD와 유사한 작업을 수행하지만, 네트워크 리소스의 맥락 내에서 이루어진다.

설계

CRUD는 데이터 작업에 중점을 두는 반면REST는 HTTP를 통해 클라이언트가 서비스와 상호 작용하는 방식을 설계하는 데 중점을 둔다.

둘의 비교 글이 좀 있기는 한데,

역할이나 범위, 정의를 생각해보면

 비교 대상이 아닌것 같다는 생각도든다.

참고 : https://www.logicmonitor.com/blog/rest-vs-crud

m1에서 node-sass 사용시 나는 에러이다.

제 세팅에서는 node 버전 16까지는 문제 없었는데,

18 위로 업데이트 후 부터 발생했다..

정확한 원인은 맥북의 arm환경 빌드에 대한 릴리즈가 없기때문이라고 한다.

해결법은 많이들 나와있는데,

node-sass제거하고 sass를 사용하는것이다.

$ npm uninstall node-sass 
$ npm install sass

그러고나면 정상적으로~

근데 node-sass, sass는 뭐하는 친구들일까??

styles.module.sass 같은 형식의 파일을 본적이 있는가?!

css모듈 사용시 만드는 파일 형식이다.

node-sass는 이 파일을 css코드로 변환해주는 역할을 한다!

(이렇게 야무진 일을 하는 친구였다..하지만 이제 보내주자)

저번에 올렸던 페이지에서 한번 보아하니

 node-sass 만나서 즐거웠어~!

프로젝트별로의 설정을 해 둘 필요가 있다.

각자의 vscode 설정이 코드에 영향을 주어 

코드 일관성을 해칠 수 있기 때문이다.

vscode를 따로 설정하는 방법은 2가지 이다.

1. .vscode  직접 폴더 만들기

루트 폴더에 .vscode 폴더를 만들고

setting.json 파일을만들어준다.

그리고 { ... } 내부에 원하는 설정을 추가해두면 끝!

 2. 좀 더 쉽게 자동으로 .vscode 폴더 만들기

1번의 방법은 설정 하나하나를 찾아봐야하는 귀찮음이 좀 있다.

[command + shif + p]를 통해서

Open Settings (UI)에 접속한다.

그리고 User가 아닌 Workspace탭을 클릭해준다.

그러고 나면? 이제 하나하나 설정을 UI에서 변경해줄 때 마다 

루트 .vscode/setting/json 파일에 변경이 반영된다.,.!!

auto save 설정을 바꾸니 json파일에 자동으로 추가가 싸악~

이제 우리들의 프로젝트의 일관성 유지를 위해

설정을 하나씩 추가해주자!  이전 글에 있던 import 자동 정리가

하나의 예가 되겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit"
	},

물론 이렇게만 적어두면 다른 사람이 뭔지 파악하기 힘들고 

설정한 사람도 시간이 지나서 무슨 내용인지 까먹을 수 있으니

아래 처럼 주석으로 옆에 표시하거나

settings-desc.json 파일을 별도로 만들어서 관리하는 방법도 있겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit" // 저장 시 미사용 import 정리
	},

쓰지 않는 코드는 삭제하기!

이 얼마나 간단한 말인가 싶지만

정신없이 코드작업을 하고나면 사용하지 않는 코드들이 조금씩 남는다.

특히나 import 부분은 가장 상단에 있어서 자주 보는 부분도 아니라

사용했다가 지운, import들이 희미한 글자로만

남아있는 케이스가 종종있다.

이럴때를 대비해서 저장시마다 사용하지 않는 import를 제거해주는 방법이 있다! 🥺

1. 미사용 import 지우기 직접 실행하기

프로젝트 페이지로 이동해서 오른쪽 클릭하면 중간정도에 Source Action 이 나온다.

이를 클릭,

클릭하면 위 같이 새로운 창이 나온다. 

여기서 'Organize Imports' 를 클릭해주면

선언되어 있지만, 미사용 import를 깔-끔하게 제거해준다!

2. save 할때마다 import 관리하기

언제 매번 이렇게 지우겠나? 저장할때마다 지우기를 원한다면!

Settings 탭을 열고 오른쪽 상단에 아이콘중

파일에 화살표가 감싸고 있는 아이콘을 클릭해준다. (open setting JSON)

그러면 설정 json 파일로 넘어간다.

그리고 json파일에

"editor.codeActionsOnSave": {
               "source.organizeImports": true
},

이 부분을 추가해준다.

그러면~ 저장하는 모든 순간에 import 부분을 정리해준다. 

끝! 이제 import를 신경쓰지 않고 코딩에 집중할 수 있다!

2번이 그럼 무조건 좋겠지? 싶지만 서도

생각보다 적응이 안될 수 있다.

잠깐 컴포넌트를 지우고 위치를 옮기거나 하는 모든 순간에

import가 정리되서 다시 import를 선언해 주어야 한다..

그래서 신나게 적용시켰다가 

뭔지 모를 이질감에 살짝 당황했다는 후문이 ... 

참고 : https://medium.com/@sebastiantolomeo/how-to-automatically-organize-imports-in-visual-studio-code-e80d87b4f263

https://www.npmtrends.com/

npm 페이지에 들어가보면 이번주 다운로드 수라든지 

절대적인 수치들이 표시되어있다.

하지만,

절대적인 값 보다는 우리가 고민하는

또 다른 모듈과의 비교가 더욱 궁금하다. 

그래야 뭘 쓸지 흔들리는 우리의 마음을 다 잡을 수 있으니까.

그럴땐? 위의 페이지에서 찾을 수 있다. 

페이지 접속시 상단에 아래와 같이 되어있다. 

상단 이 부분에 찾고자 하는 npm package를 검색하면 된다.

뭐 react, recoil 등~

그러면 아래와 같이 다운로드수와 해당 패키지의 정보가 나온다.

여기에 미쵸버리는 뽀인트, 검색을 추가적으로 해서 바로 값을 비교할 수 있다.

또 다른 상태관리 패키지 zustand를 검색해보자.

크.. 한눈에 두 패키지를 비교할 수 있게끔 배치해준다.

뭐.. 거의 4배 차이가 나는군..

물론 많이 쓴다고 무조건 좋은 패키지가 아니라는 것은 언제나 명심!

자기에게 맞는 것을 골라서 사용하기!

그 아래에는 많이들 검색한 비교에 대해서도 몇개 뽑아주고 있다!

https://www.npmtrends.com/

프런트 회사 공고를 보면 (24년기준)

많은 회사들이 리덕스를 아직 사용중이다.

개인적으로.. 너무 싫다. 뭐 하나 만들려고 하면 아주 난리다. 

처음에 코드를 볼때도 무슨 기능인지 

타고타고타고타고~  아...**

벌써 아찔하군

요즘  상태를관리하는 여러 방법이 나왔다.

한번씩 다들 써보면서 "나 이거써봄~" 할 수 있는 멋쟁이가 되어보쟈.

그 중에 Recoil에 대해서 살포시 알아보도록 하쟈!

(그리고 이지피지한 사용법 뒤에 가려진 어두운면까지..)

Recoil에서는 하나의 상태를 [atom]이라고 부른다.

그리고 그 atom을 호출해서

atom의 값을 쓰거나 값을 수정해준다.

사용 방식은 아래와 같다.

      <RecoilRoot>
        <BrowserRouter>
          <App />
        </BrowserRouter>
      </RecoilRoot>

App.tsx에서 

일단 <App />컴포넌트를 <RecoilRoot>로 감싸준다.

( yarn을 통해서 recoil을 받아주는것 잊지 마시구)

export const totalPrice = atom<number>({ 
  key: 'totalPrice' , 
  default: 14 , 
});

그리고는 따로 파일을 만들어서

사용하고자하는 atom을 만들어준다.

(atom폴더를 따로 관리하는 것도 좋을것 같다 - 사견)

key는 해당 atom을 분간하기 위해서 사용하고,

default에 디폴트 값을 넣어준다.

string, number, array, object 타입이 뭐든 상관없다.

해당 타입은 atom옆에 <>로 넣어주면 된다.

const [price, setPrice] = useRecoilState<number>(totalPrice);

 그리고 원하는 페이지에서 useRecoilState관련 선언을 해준다.

순간 뭐랑 비슷? 맞다

useState과 상당히 유사하다. 

앞에 price는 상태값

setPrice는 상태 변경함수,

그리고 totalPrice는 atom파일에서 선언한 값을 가지고 오면 된다.

useState를 사용해서 상태 값을 관리해줄때는

컴포넌트를 통해서 값과 set함수 둘다 넘겨주는 노고를 했어야했다.

특히나.. 저 멀리 부모 컴포넌트에서 사용하는걸..

여러단계 아래에 있는 자식컴포넌트가 사용한다면?

...수많은 props에 태워줘야한다. (+ set함수 타입 검색까지 ..)

반면 Recoil을 사용한다면 사용하는 컴포넌트에서

위 한줄만 딱 선언해주면

언제 어디서든 값에 도달하고 수정할 수 있다! 홀리몰리

이제 앞으로 Recoil로만 개발하면 되겠다 ^오^

으림없는 소리!!

이 표보터 보자,

https://npmtrends.com/jotai-vs-recoil-vs-zustand 해당 페이지에서 얻은 정보다

이 페이지는 패키지들의 다운로드 횟수를 수치화해서 보여준다.

요즘 트랜디(?)한 상태관리 친구들 3개를 비교해보면

이제 고개를 조오~금 들고는 있지만

저 위에 zustand라는 친구가 굳건이마냥
압도적인 다운로드 횟수를 보여준다.

물론 많이 사용한다고 좋은 라이브러리라고 확정지을 수는 없지만

업데이트 주기까지 보면..녜에 ^^

또한 개인적으로는 SSR이 많이들 주목받고 있는 현 시점에

 Recoil은 클라이언트 사이드에 최적화 되어있기에

엄청나게 많은 사랑을 받지 못하는게 아닌가 싶다.

하지만 개인 프로젝트나 작은 프로젝트에서 사용하기는

간단한 사용법을 필두로 좋은 역할을 할수있지 않을까 하는 생각은 변함없다.

저 같은 경우 해당 현상은

SSR인 Nextjs에서 emtion을 사용하여 styled 컴포넌트 작성시에

:first-child 를 사용했기 때문이였습니다.

서버사이드 렌더링에서 이런 Emotion이나 styled-components 같은

CSS-in-JS 라이브러리를 사용할때,  위와 같은 문제가 발생할 수 있습니다.

해결 : first-child를 first-of-type으로 변경해준다.

근데.. sass나 css파일에서

first-child는 아무 문제 없었던 것 같은데..?!

그건 해당 파일이 처리되는 시점이 달라서 입니다.

sass나 css파일은 빌드타임시에 처리됩니다.

때문에 서버와 클라이언트에서 같은 스타일을 적용시킵니다!

반면 CSS-in-JS는 런타임에 동적으로 생성하기 때문에 

서버와 클라이언트 HTML구조가 다르면 다르게 작동할수 있어서

위와 같은 에러가 나오는것이라고 합니다.

참고 : GPT와의 딥토크 + https://inpa.tistory.com/entry/%F0%9F%8C%9F-first-child-first-of-type