‼️ 참고

해당이슈는, 멋쟁이사자처럼 프론트엔드 스쿨 4기의 React Final Project를 작업하던 중 발생한 이슈입니다.
제가 왜 set-url로 origin의 url을 다시 설정하려고 했는지에 대한 상황파악을 하기 위해서는, 저희팀이 어떤 git branch전략을 사용했는지에 대한 이해가 필요합니다. 다음 내용을 참고해주세요.

저희팀은 git branch 전략으로, git flow 방식을 선택했습니다.

main : 기준이 되는 branch로 제품을 배포하는 브랜치 입니다.
develop : 개발 branch로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
feature : 단위 기능을 개발하는 branch로 기능 개발이 완료되면 develop branch에 합(Merge)칩니다.

📢 feature branch 컨벤션

단위 기능을 개발하는 branch인 feature branch의 경우, 다음과 같은 형식으로 네이밍합니다.

feat/#이슈번호

🤔 기존에 사용하던 local 저장소를 왜 버려야만 했었을까?

팀의 레포지토리(upstream, https://github.com/LikeLion-FE-React-Project04/project-repo)
fork뜬 개인 원격저장소(origin, https://github.com/SeoMiYoung/project-repo)

저는 로컬에서 feat/#212라는 feature branch를 생성하여 코드를 작업중이었습니다.
어느순간 제가 컨벤션을 잘 지키지 않아, 끝없는 에러가 발생하기 시작했습니다.

저희팀은 컴포넌트 이름을 Pascal Case(파스칼 케이스)로 짓기로 했습니다.
그러나 저는 메인모달 컴포넌트명을 처음에 MainModal이 아닌, Mainmodal이라고 지었고,
추후에 이를 발견하고 다시 Mainmodal을 MainModal로 수정하려고 하는 과정에서 오류가 발생했습니다.

그 이유는, Git은 대소문자를 구분하지 못하기 때문입니다.
그래서 Mainmodal에서 MainModal로 수정해도, Git은 변경된 사항을 제대로 감지하지 못합니다.

이로인한 오류를 해결하려고 많은 시도를 했지만, 결국 더 꼬이게 되었고, 더이상 이 로컬을 쓸 수 없을 것 같아서, 이 로컬저장소를 버리기로 하고, 다시 git clone을 받아서 새로운 로컬에서 작업을 진행하기로 했습니다.

👩‍💻 새로운 로컬 저장소 만들기

[STEP1] 컴퓨터에 새로운 폴더 생성

저는 OneDrive/ReactProjectFolder 를 생성하고 해당 폴더로 들어갔습니다.
폴더명을 한글로 짓지 않는 걸 명심해주세요.(한글로 지으면 예상치 못한 오류가 발생할 수 있습니다)

[STEP2] git clone [레포지토리 주소]

처음에는, 레포지토리 주소를 upstream꺼를 가져와야하나, origin꺼를 가져와야하나 고민을 했습니다.
결국은 upstream꺼를 가져왔습니다.
그 이유는, 현재 저희는 upstream의 develop 브랜치를, 팀원들의 전체 코드를 모으는 곳으로 관리를 하고 있었고,
origin에도 develop브랜치가 있긴 하지만, origin의 develop에는 사실상 코드가 거의 초기세팅 상태입니다.
그 이유는, 사실상 origin의 경우는 feature branch를 저장하는 용도로 쓰이기 때문에 develop branch는 건들일이 없습니다.

그래서 저는 git clone [팀의 organization 주소(upstream)] 이렇게 명령어를 입력했습니다.
처음에 .git이 있는 폴더 안에다가 git clone을 받아야 되지 않을까? 라고 생각했지만(ReactProjectFolder폴더안에는 .git이 없음),
저희 팀원께서 말씀하시길, .git이 설정된 걸(upstream) 가져오니, git clone하면 자동으로 .git을 가져오게 되는거라고 말씀하셨습니다.

위의 명령어를 친 후, 저는 code .으로 VSCode를 열었고,
main => develop 브랜치로 바꿔보니 현재까지의 팀원들의 작업 내용들이 잘 들어가 있었습니다.

[STEP3] set-url 명령어로, origin의 url 다시 설정하기

그런데, 지금 상태에서 git clone한 주소는 자동으로 origin으로 설정됩니다(origin연결은 git clone시, 자동으로 해줌).
그러나, 저는 팀의 organization주소(upstream)를 origin으로 설정하고 싶진 않습니다.
그래서, 개인 fork원격저장소를 origin으로 설정해주기 위해 다음 명령어를 사용했습니다.

set-url을 통해서, origin을 개인 fork 원격저장소로 재설정해줬습니다.

그리고 upstream연결이 되어있지 않으므로(upstream연결은 자동으로 안해주고 직접 해줘야 함),
git remote add upstream [공용 레포지토리 주소] 명령어를 입력해서
공용 organiztion을 upstream으로 연결해주었습니다.

따라서 다음과 같이 옳바르게 연결된 모습을 확인할 수 있습니다.

이 세가지 용어는 함수에서 사용되는 용어들입니다.
익숙하면서도 매번 헷갈립니다.
간단히 정리해보도록 하겠습니다.

✍️ 용어 정리

로컬저장소에서 커밋 내역을 push한다면, 원격저장소에 커밋내역이 남게된다.
그런데, 원격저장소에서 커밋내역을 돌리고 싶다면 어떻게 해야할까?

☑️ 상황 설명

만약에 이미 커밋1~커밋4까지 깃헙에 올라와있는 상태에서 커밋3와 커밋4가 깃헙에 올라와서는 안되는(보안 정보가 들어있다던지..) 코드라서, 깃허브에 커밋3와 4내역을 지우고 싶다면?

즉, 우리는 깃헙에 커밋2까지만 올려놓은 상태로 바꿔야한다!

☑️ 해결 방법

✔️ 순서대로 커밋 삭제

지금 위의 예제에서는 커밋3와 커밋4, 즉 두개의 커밋을 삭제해야한다.

git reset --hard HEAD~2

✔️ 로컬에서 변경된 내용을 PUSH

명령어가 적용되는 저장소는 모두 로컬이기 때문에 원격지에서 커밋을 삭제하려면 git push 명령어를 사용하여 로컬에서 변경된 것을 푸시하면 된다.

git push origin HEAD --force

위의 과정을 거치면, 다음과 같은 상황이 된다.

🤔 왜 master에서 main으로 바꾸려고 하는걸까요?

최근에 흑인 인권이 문제가 되면서 master, slave와 같이 계급과 관련된 표현들이 문제되고 있습니다. 그래서 그런 인종차별적인 표현을 지양하고자 main, sub와 같은 표현을 쓰려고 하고 있습니다.

❓ fork를 한 원격저장소가 아닌 경우, master에서 main으로 변경 방법

✅ Git으로 관리되고 있는, 현재 디렉터리에서만 변경하는 방법

명령어 입력: git branch -m main

이 방법은 현재 디렉터리에서만 적용됩니다. 즉, 일회성이죠.
또 다른 폴더를 만들고 git init을 만드는 순간 또 다시 Git의 기본 브랜치가 master로 설정됩니다.

✅ .git을 생성하면서 동시에 main으로 기본 브랜치명을 설정하는 방법

명령어 입력: git branch -b main

마찬가지로 일회성입니다.

✅ 아예 로컬 환경에서 Git의 기본 브랜치가 항상 main이 되도록 설정하는 방법(추천)

명령어 입력: git config --global init.defaultBranch main

이렇게 설정하면, 이제 Git의 기본 브랜치는 항상 master가 아닌, main이 됩니다.

❓ fork를 한 원격저장소의 경우, master에서 main으로 변경 방법

위에서 소개한 방식들에서 쓰인 명령어들은, 맨 처음에 초기화 된 Git 저장소에만 영향을 줍니다. 즉, fork를 한 원격저장소에는 영향을 주지 않습니다. 따라서 fork를 한 원격저장소에서 master를 main으로 변경하려면 다른 방식을 써야합니다.
(이 방법은 개인적으로 선택한 방법이므로, 더 좋은 방법이 있을 수 있습니다)

ex) 만약에 어떤 사람의 레포지토리 A(master로 설정된)를 fork해온 A'가 있다고 합시다.
당연히 A를 fork해 온 것이므로, A'역시 Git의 기본 branch가 master로 설정되어있습니다.
이때, fork해온 branch를 master가 아닌 main으로 설정하고 싶다면, 다음과 같은 과정을 거치면 됩니다.

1. A'의 로컬저장소에서 터미널을 연다

2. git branch -m master main 명령어를 실행하여 로컬의 master 브랜치를 main으로 변경한다
   2-1. 이러면 master를 복사한 main이 생김(사실..내 생각으로는 main이 새로 생기는게 아니라, 기존의 master가 main으로 변경되어야될 것 같았는데...생각보다 다른 방향으로 흘러가서 쫌 당황했긴 함)

3. git push -u origin main 명령어를 실행하여 변경된 main 브랜치를 원격 저장소로 푸시한다
   3-1. -u를 넣어줘야할까?
   보통 git push origin main이라는 명령어를 사용할겁니다. 한 번 -u 옵션과 함께 git push origin main 명령어를 실행하면, 로컬 브랜치와 원격 브랜치 간의 추적이 설정되고 연결이 맺어집니다. 초기에 이미 추적 설정을 완료하였다면, 그 이후부터는 git push 명령어 사용시, -u를 빼고 입력하면 됩니다.

4. github의 fork한 원격저장소에 들어가서 UI방법으로 main을 default branch로 변경시킨다
   

5. 기존의 master branch를 삭제한다
   
   
   기존의 master branch가 삭제되고 main만 남게 된 걸 확인할 수 있습니다.

🥲 미해결 궁금증

git branch -m master main 명령어를 실행했을때,
기존의 master 브랜치가 main으로 이름변경되는게 아니라,
기존의 master 브랜치는 그대로 두고, 새로운 main 브랜치가 생겼는지 궁금합니다.

😊 Github에서 알려준, 로컬의 master를 main으로 변경하는 방법

깃헙에서 GUI방식으로 default branch를 master에서 main으로 변경했더니, 다음 창이 떴다.

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

😥 문제 상황

웹팩(Webpack)으로 번들링 작업을 하려고 했는데, 다음 에러가 발생했습니다.

입력 명령어: node_modules/.bin/webpack --mode development --entry ./src/app.js --output ./dist/main.js

// --mode development : 개발 모드다
// --entry ./src/app.js : 시작점 경로를 지정
// --output ./dist/main.js : 번들링 결과물을 저장 할 경로 지정

👀 문제 발생 이유

해당 에러는 OpenSSL 라이브러리에서 발생하는 문제로 보입니다. Node.js는 내부적으로 OpenSSL을 사용하여 암호화 관련 작업을 처리합니다. 에러 메시지에서 "unsupported"와 관련된 부분이 보이는데, 이는 OpenSSL에서 지원하지 않는 암호화 알고리즘 또는 기능을 사용하려고 시도하여 발생한 것입니다.

위의 OpenSSL unsupported 문제는 노드 17버전에서부터 발생합니다.
노드 16버전으로 하거나 노드17 이상일때는 실행 시 추가 옵션을 붙여주어야 합니다.

🫠 해결 방법

터미널에 다음 명령어를 입력한 뒤, 번들링을 시도합니다.

export NODE_OPTIONS=--openssl-legacy-provider

위의 사진처럼 문제없이 번들링이 되었고, dist폴더가 생성된 걸 확인할 수 있습니다.

🔊 출처

• https://stackoverflow.com/questions/69394632/webpack-build-failing-with-err-ossl-evp-unsupported
• https://levelup.gitconnected.com/how-to-fix-the-err-ossl-evp-unsupported-error-in-node-js-197082f42185

👀 왜 궁금해졌을까?

프로젝트를 새로 생성하면서, 해당 명령어를 칠 일이 생겼는데,
그동안 해당 명령어에 대해서 잘 알지도 못하면서 치기만 했어서, 한번 자세히 정리해보기로 했습니다.

✏️ Node.js에서 제공하는 CLI

npm은 자바스크립트 프로그래밍 언어를 위한 패키지 관리자입니다.
npm은 Node.js에 포함되어 있어 Node.js 설치 시 자동 설치됩니다.
npm i와 npm init -y는 Node.js에서 제공하는 Command Line Interface (CLI) 중 하나인 npm (Node Package Manager)의 명령어입니다.

💻 npm init -y

package.json은 프로젝트 정보와 의존성(dependencies)을 관리하는 문서입니다.
이미 작성된 package.json 문서는 어느 곳에서도 동일한 개발 환경을 구축할 수 있게 해줍니다.
npm init 명령어를 통해 package.json을 생성할 수 있습니다.
만약에 그냥 npm init이라고 입력한다면, 프로젝트 정보에 대한 여러가지 옵션을 선택할 수 있지만,
npm init -y라고 입력한다면, 프로젝트 정보를 default로 설정할 수 있습니다.

💻 npm install

NPM을 사용하는 가장 큰 이유는 NPM에 등록되어 있는 무궁무진한 외부 패키지를 설치하기 위해서 일 것입니다. npm install 또는 npm i 커맨드를 사용하면 원하시는 패키지를 설치할 수 있습니다.

🔊 참고

https://www.daleseo.com/js-npm-cli/

👀 문제 상황

매번 npm과 npx에 대해 헷갈렸던 저는, 이번 기회에 짚고 넘어가야겠다고 생각했습니다.

👩‍💻 업데이트가 잦은 모듈의 경우, 왜 npm보다는 npx를 사용해야될까?

1. 기본적으로 실행되어야할 패키지가 경로에 있는지 먼저 확인합니다.(예: 우리의 프로젝트)
2. 경로에 제대로 있다면, 그대로 실행합니다.
3. 그렇지 않다면 패키지는 설치되어 있지 않다는 걸 의미하고, npx가 최신 버전의 패키지를 설치를 한 후에 실행합니다.

리액트 프로젝트 생성 도구인 create-react-app 같은 모듈의 경우, 변경사항이 꽤나 잦은 모듈입니다. 그렇기 때문에 매 설치 전마다 npm으로 재 설치를 하지 않는 경우에는 이전 버전을 사용할 여지가 꽤 있습니다. 이런 프로젝트 생성 모듈은 매 업데이트마다 새로운 기능과 다양한 버그들이 고쳐집니다. 그리고 이런 보일러플레이트(반복적으로 비슷한 형태를 재사용하는 코드) 같은 경우에는, 항상 최신 버전을 유지해 주는 것이 좋은데, 매번 설치하는 것이 꽤나 귀찮은 일입니다.

✍️ 로컬에 해당 패캐지를 설치(다운로드)하지 않고, 오직 실행만 하는 npx

사실 이 말이 무슨소리인지 처음에 이해가 잘 안가서 힘들었습니다. 예시를 들어 설명하겠습니다.

어떤 프로젝트에서 CRA(Create-React-App) 2버전을 사용했다고 합니다.
CRA의 가장 최신 버전은 4라고 합시다.

✏️ if) 프로젝트를 사용하려는 사용자가 npm install로 CRA를 설치해서 사용하려고 한다면?

npm i 명령어를 사용하여 패키지를 설치하면 해당 패키지의 지정된 버전(일반적으로 package.json 파일에 명시된 버전 또는 최신 버전)이 로컬에 설치됩니다. 따라서 create-react-app 패키지가 버전 2로 명시되어 있다면, npm i 명령을 실행하면 버전 2가 로컬에 설치됩니다.

✏️ if) 프로젝트를 사용하려는 사용자가 npx로 CRA를 실행시켜서 사용하려고 한다면?

npx를 사용하여 패키지를 실행하면, npm 레포지토리에서 항상 최신 버전의 패키지를 다운로드하여 일시적으로 실행합니다. npx create-react-app을 실행하면 최신 버전인 버전4가 임시로 다운로드되어 파일과 구조를 생성하지만, 이는 로컬에 영구적으로 설치되는 것이 아니기 때문에 package.json 파일에는 여전히 버전 2로 기록되어 있을 것입니다.

일시적으로 패키지를 실행하는 방식은 프로젝트의 종속성을 줄이고, 프로젝트 디렉터터리를 깔끔하게 유지할 수 있는 장점이 있습니다. 필요한 패키지를 필요한 시점에만 다운로드하여 사용하므로, 프로젝트의 관리나 배포 시에도 불필요한 종속성의 버전 충돌 등을 최소화할 수 있습니다.

💻 개발단계가 아닌, 운영단계에서는 npx가 위험할 수 있다!

운영 단계에서는 일시적으로 패키지를 실행하는 npx를 사용하는 것보다 해당 패키지를 로컬에 영구적으로 설치하는 것이 안전합니다. 일시적으로 패키지를 실행하는 경우에는 매번 실행할 때마다 해당 패키지를 다운로드하므로 속도가 느릴 수 있습니다. 또한, 패키지를 다운로드하는 네트워크 환경이 제한적인 경우에는 문제가 발생할 수 있습니다.

따라서, 운영 환경에서는 일반적으로 패키지를 로컬에 영구적으로 설치하여 사용하는 것이 권장됩니다. 이는 성능 면에서 이점을 가져오며, 패키지의 안정성과 호환성을 보장할 수 있습니다. 로컬에 패키지를 설치하는 방법은 npm install 또는 yarn add와 같은 명령을 사용하여 종속성을 추가하는 것입니다. 이렇게 설치된 패키지는 프로젝트 디렉터리에 저장되어 계속 사용할 수 있습니다.

단, 개발 단계에서는 npx를 사용하여 일시적으로 패키지를 실행하고 테스트하는 것이 편리할 수 있습니다. 이는 개발자가 다양한 패키지와 버전을 테스트하고 실험할 수 있는 유연성을 제공합니다. 그러나 실제 운영 환경에서는 안정성과 신뢰성을 위해 로컬 설치가 권장됩니다.

🔊 출처

https://codinglevelup.tistory.com/116
https://soojae.tistory.com/40
https://joonfluence.tistory.com/659

🤔 궁금증이 생긴 이유?

npm install 명령어로 외부 패키지를 설치하려고 할 때, -D명령어를 붙혀서 dependencies 또는 devDependencies 둘중에 어떤 방식으로 패키지를 설치할건지 정할 수 있습니다. 둘의 차이를 정확히 몰랐던 나는 이번 기회에 찾아보게 되었습니다.

(참고로, package.json파일에 dependencies, devDependencies 둘중에 어떤 형태로 패키지를 설치했는지에 대한 정보가 기록되어있습니다.)

👩‍💻 그래서 차이가 뭔가요?

🤨 왜 굳이 구분해야되죠? 구분하면 좋은점이 있나요?

구분해주는 이유는 배포할 때, 해당 라이브러리를 포함 시킬거냐 안시킬거냐의 문제와 관련있기 때문입니다.

dependencies와 달리, devDependencies에 해당하는 라이브러리는 개발할때만 필요하기 때문에, 배포시 포함되지 않습니다.
이렇게 잘 구분을 해줘야, 빌드 시간도 줄이고, 배포할 때 불필요한 라이브러리가 들어가지 않게 할 수 있습니다.

👀 왜 궁금해졌을까?

궁금하게 만든 질문: https://inflearn.com/questions/134177

위의 질문을 보다가 ES 모듈과 CommonJS 모듈의 차이를 몰랐던 저는, 이번 기회에 정리해보기로 했습니다.
정말 정말 간단하게만 정리했으니, 자세한 정보를 얻고 싶다면, 하단에 첨부한 영상 링크를 확인해주세요.

👩‍💻 모듈 시스템의 종류

이 방법들 중에서, ES 모듈과 CommonJS 모듈의 차이에 대해 알아봅시다.
이 두개의 모듈 시스템은 현업에서 가장 많이 쓰는 모듈 시스템이므로 꼭 이해하셔야합니다!

👩‍💻 간단 필기

하단에 첨부한 자료를 보면, 자세한 예시를 확인할 수 있습니다.

🔊 출처

참고 영상: https://www.youtube.com/watch?v=5NXEXkIrkAk
영상 속 자료: https://www.gymcoding.co/e9085fcc1538486eb1451ab988199d06

👻 문제 상황(bug)

원래 // @ts-check를 넣어주면, 자바스크립트를 타입스크립트처럼 코딩하는 것 처럼, 옳바르지 않은 타입에 빨간색 밑줄이 그어져야 합니다. 그러나, 위의 상황에서 그러지 않는 걸 확인할 수 있습니다.

🤔 어떻게 해결했을까?

[STEP1] 명령어 실행창으로 settings.json파일 열기

명령어 실행창을 여는 방법은,

window: ctrl + shift + p
mac: cmd + shift + p

그리고, open settings (json)입력

그러면, settings.json파일이 열릴겁니다.
settings.json파일은, settings(ctrl/cmd+,)에서 UI로 보여지는것들이 코드로 변경되어있는 것이라고 보면 됩니다.

[STEP2] VSCode에서의 JavaScript코드의 유효성 검사를 활성화시키기

"javascript.validate.enable": false,

위의 설정은 Visual Studio Code에서 JavaScript 코드의 유효성 검사를 비활성화하는 설정입니다. 일반적으로 JavaScript 파일을 편집할 때 Visual Studio Code는 내장된 JavaScript 유효성 검사 도구를 사용하여 코드의 오류나 잠재적인 문제를 식별합니다. 그러나 이 설정을 false로 설정하면 유효성 검사가 비활성화되어 오류 및 경고 메시지가 표시되지 않습니다. 이 설정은 특정 프로젝트나 상황에서 유용할 수 있으며, 코드를 빠르게 작성하고 디버깅할 때 방해받지 않을 수 있습니다. 단, 코드의 실수를 감지하지 못할 수 있으므로 주의해서 사용해야 합니다.

바로, 저 설정이 false로 되어있던점이 문제였습니다.
따라서 다음과 같이 true로 바꿔줍니다.

"javascript.validate.enable": true,

🙌 해결 이미지

👀 왜 궁금해졌을까?

npx add-gitignore 명령어를, node_modules와 같은 필요없는 항목들을 github에 올리지 않기 위해 입력했습니다.
그랬더니 다음 사진처럼 package-lock.json 파일만 변경이력에 뜨게 되었습니다.

위의 상황에서 저는 package-lock.json도 git ignore 처리해야할지, 아니면 commit해야할 지 고민에 빠졌습니다.

🤨 package.json이 버전을 범위로 관리해서 발생할 수 있는 문제점

프로젝트에서 사용하는 모든 패키지들이 package.json 파일에 등록이 되어 있으면, 프로젝트 사용자들이 해당 프로젝트 코드를 clone하고, 패키지 매니저의 설치 명령어(npm install) 한번으로 종속된 모든 패키지들을 설치받을 수 있습니다. 설치가 끝나면 프로젝트에서 필요한 모든 패키지들이 node_modules 폴더안에 존재하는 것을 확인할 수 있습니다.

하지만 package.json 파일에 등록된 패키지 버전은, ^나 ~를 이용해서 범위로 지정된 경우가 많습니다. 버전은 각 명시된 방식에 따라서 패키지를 설치하게 되는데요, 그래서 설치 시점에 따라서 모두 다른 버전의 패키지로 설치될 수 있습니다.

예를 들면, react패키지가 "react": "^17.0.2"처럼 설정되어 있다면,

• package.json: ^17.0.2 (2021년 9월 1일)
• 개발자 A: 17.0.2 (프로젝트 첫 생성자)
• 개발자 B: 17.0.3 (2021년 9월 11일 합류)
• 개발자 C: 17.1.0 (2021년 9월 21일 합류)
• 개발/상용 서버: 17.1.3 (2021년 9월 30일 배포)

위와 같이 모두 다른 버전의 패키지로 설치될 수 있습니다. 이러면 버전 차이로 인해 버그가 발생할 수 있습니다.

😊 버전 잠금을 해주는 package-lock.json

package-lock.json은 해당 패키지에 현재 설치되어 있는 모든 모듈들의 버전들이 트리 구조로 명시되어 있습니다.
따라서 package-lock.json의 버전을 관리한다면, 모든 환경에서 같은 버전의 모듈 구성을 사용할 수 있습니다.

한마디로 말하자면, package-lock.json은 프로젝트에 특정 패키지를 최초로 추가하는 시점에 정확히 어떤 버전이 설치가 되었는지를 기록한다고 이해하면 됩니다.

따라서 package-lock.json은 패키지들의 버전 정보를 저장하고 협업할 때 같은 패키지 버전을 다운받을 수 있도록 도와주기 때문에, git ignore 시키지 말고, 꼭 commit을 해야합니다.

🔊 출처

https://webruden.tistory.com/919
https://www.morolog.dev/entry/%EC%9E%91%EC%84%B1%EC%98%88%EC%A0%95-package-lockjson%EC%9D%98-%EC%97%AD%ED%95%A0
https://velog.io/@memoyoon/%ED%98%91%EC%97%85%EC%9D%84-%ED%95%A0-%EB%95%8C%EB%8A%94-Package-lock.json-%ED%8C%8C%EC%9D%BC%EB%8F%84-%EC%BB%A4%EB%B0%8B%ED%95%B4%EC%A3%BC%EC%9E%90

👀 궁금증

웹팩에 관련된 온라인 강의를 듣던 중, webpack.config.js를 다음과 같이 구성하게 되었습니다.

const path = require('path'); 

module.exports = {
  mode: 'development',
  entry: { // entry가 여러개일수도 있다
    main: './src/app.js' // 상대경로
  },
  output: {
    path: path.resolve('./dist'), // path는 절대경로로
    filename: '[name].js'
  }
}

강사님께서 말씀하시길, entry와는 다르게, output은 웹팩에서 가이드하는 대로 절대 경로를 사용하고 있다고 합니다.
그런데 저는 여기서 궁금증이 생겼습니다.
'./dist'형태가 상대 경로인데, 왜 output을 절대 경로를 사용했다고 하는지 이해가 안갔습니다...

😖 내가 헷갈렸던 이유

알고보니, 제가 이해를 하지 못했던 이유는, path.resolve()의 역할을 잘 몰랐기 때문이었습니다.

👩‍💻 Node.js의 path 모듈로 경로 다루기

path 모듈은 폴더와 파일의 경로를 지정해주는 모듈입니다.
path 모듈은 Node.js에 내장되어 있기 때문에 별도의 라이브러리 설치없이 바로 불러와서 사용할 수 있습니다.

CommonJS 모듈 시스템을 사용하는 프로젝트에서는 require 키워드로 불러오고, ES 모듈 시스템을 사용하는 프로젝트에서는 import 키워드를 사용할 수 있습니다.

// CommonJS Modules
const path = require("path");
// ES Modules
import path from "path";

webpack.config.js는 웹팩이 동작할 때 참고하는 설정 파일입니다.
그리고 웹팩은 Node.js 위에서 동작하는 프로그램입니다.
Node.js가 사용하는 모듈시스템이 CommonJS이기 때문에 webpack.config.js파일에서는 path모듈을 require키워드로 불러왔습니다.

👩‍💻 path.resolve()

path.resolve() 메서드의 인자로는 절대 경로나 상대 경로를 모두 넣을 수 있습니다.

만약 인자로 상대 경로를 전달하면, 현재 작업 디렉토리를 기준으로 해당 경로를 절대 경로로 변환합니다.
예를 들어, path.resolve('./dir')는 현재 작업 디렉토리에서 dir 디렉토리의 절대 경로를 반환합니다.

또한, 인자로 절대 경로를 직접 전달할 수도 있습니다.
예를 들어, path.resolve('/abs/path/to/dir')와 같이 절대 경로를 전달하면 해당 경로의 절대 경로를 그대로 반환합니다.

따라서 path.resolve() 메서드는 경로를 상대적으로 지정할 수도 있고, 절대적으로 지정할 수도 있습니다. 사용하는 상황과 요구에 따라 유연하게 경로를 지정할 수 있습니다.

제가 수업시간에 사용한 webpack.config.js파일의 경우, './dist'라는 상대경로를 인자로 전달했습니다.
따라서, path.resolve('./dist')는 './dist'라는 상대경로를 절대경로로 바꿔서 반환해줍니다.

그렇기 때문에, 결국 output에는 상대경로가 아닌, 절대경로가 담기게 되는 것 입니다.

🤨 그냥 절대경로를 바로 넘겨주면 되지, 왜 Node.js의 path모듈을 사용했을까?

파일이나 디렉터리의 경로를 다루는 게 뭐가 어렵다고 굳이 별도의 모듈이 필요할까요?
바로, 운영체제별로 다르게 경로를 인식할 수 있기 때문입니다.

자바스크립트 코드를 작성할 때 간과하기 쉬운 부분이 바로 우리가 작성한 코드는 어느 운영체제에서 실행될지 알 수 없다는 것입니다. path 모듈을 잘 활용해서 파일이나 디렉터리의 경로를 안전하게 처리하실 수 있으셨으면 좋겠습니다.

🔊 출처

https://velog.io/@thyoondev/Path.join%EC%99%80-Path.resolve-%EC%B0%A8%EC%9D%B4
https://www.daleseo.com/js-node-path/

타입스크립트 공부를 하던 중, Delete `␍` eslint (prettier/prettier)에러를 발견하게 되었습니다.

해당 오류가 발생한 이유는 endOfLine옵션과 관련이 있는데요, endOfLine 옵션은 줄넘김과 관련된 옵션입니다.
왜 에러가 발생했는지에 대해 알고 싶다면, 'LF'와 'CRLF'방식의 차이에 대해 이해할 필요가 있습니다.

🤔 'LF'와 'CRLF'가 뭔데?

LF: Line Feed
CRLF: Carriage Return Line Feed

이때, Line Feed는 줄 넘김을 의미하고, Carriage Return은 타자기를 사용하던 시절에 종이를 왼쪽으로 끌어오는 걸 의미합니다.
즉, CRLF는 과거 타자기에서 온 디지털 잔해(digital remnant)일 뿐입니다. 윈도우에서 CRLF를 많이 쓰는 이유는 과거에 있던 장치들과 호환하기 위해서라고 합니다.

타자기에서 왜 Carriage Return이 필요했는지 알고 싶다면 다음 글을 참고하세요.
https://velog.io/@jakeseo_me/LF%EC%99%80-CRLF%EC%9D%98-%EC%B0%A8%EC%9D%B4-Feat.-Prettier

📝 운영체제마다 다른 endOfLine 기본옵션

출처: https://technote.kr/300

운영체제마다 다른 기본옵션을 사용하고 있는데요,

Microsoft사의 Windows는 CRLF
Unix/Linux에서는 LF 
Mac의 초기버전인, 9버전 이하는 CR을 사용

❓ 에러가 발생한 이유

일단 해당 오류는 ESLint(prettier)에서 발생시키는 오류입니다.
prettier 2.0이상 부터 endOfLine옵션이 default가 'auto(운영체제 기본값)'에서 'LF'로 변경되어서 발생한 오류입니다.

저는 윈도우를 사용하고 있기 때문에, endOfLine 기본 옵션이 CRLF로 설정되어있는데요,
윈도우는 CRLF지만, Prettier에서는 LF로 설정되어있으므로 발생한 오류입니다.
컴퓨터상에서는 LF와 CRLF는 다른 바이트코드로 인식이 되기 때문에, 줄넘김을 LF로 하는 것과 CRLF로 하는 것을 git에서는 다른 코드로 인식하기 때문입니다.

🙌 에러 해결 방법

따라서, eslintrc.js파일에서 프리티어와 관련된 부분에서의 endOfLine값을 auto로 설정해주시면 됩니다.
(endOfLine을 설정하는 코드가 없으면 추가하시고, 기존에 있다면 값을 수정하세요)

"rules": {
    "prettier/prettier": [
        "error",
        {
            "endOfLine": "auto"
        }
]
}