hmk run dev

무분별한 lint 정렬로 인한 헤맴... lint 오류 무시...(lint에러 좀 해결하자 ^^ 구글링하면 다 나온다) 편견에 덮인 오류 찾기 애초에부터 개발자 도구로 번들링 된 파일에 CSS가 script가 빠져있다는 것을 확인하지 않은 것에 대해 자괴감이 들었다...! 그것도 모르고 노드 버전이니 npm 캐시 문제니 getSiteControl 문제이니... 앞으로 문제가 생기면 문제가 생긴 지점부터 그 아래 구동원리를 파악 하자..! 해결방법을 지엽적으로 생각하지 말자 빠르게 하지 말고 그 밑에 돌아가고 있는 구조부터 파악하자..! 그리고 모르는 것은 물어봐도 된다. 사냥개 같이 집요하게 문제를 자발적으로 해결하려는 것도 중요하지만 조직 전체로 봤을 때 리소스 낭비이다. 그러니 오늘 깨달은 점을 실천..

개발 작업은 개발자의 컴퓨터에서 코딩하고 테스트 후에 문제가 없으면 서버에 배포한다. 서버에서 프로그램을 구동시키기 위해선 개발자의 컴퓨터 환경과 호환이 되는 실행환경(버전)이 세팅이 되어있어야 한다. ex) 노드, 파이썬, mysql 등의 버전 이러한 호환을 맞추기 위해 여러 공수가 들어갈 수가 있다..! 이를 해결하기 위한 방법은 여러 가지 방법이 있지만 현재 가장 보편적으로 많이 쓰이는 것이 바로 도커이다! 도커의 컨테이너는 개발자가 코딩을 하고 서버에 배포할 때 코드와 설계도를 같이 서버에 보내면 서버는 그 설계대로 컨테이너들을 설치해 서비스를 실행할 수 있게 해 준다. 1. 매번 환경을 세팅할 공수를 해결해준다. 2. 도커 허브에선 세팅해 놓은 환경을 가져올 수 있다! 3. 이렇게 세팅해놓은 환..

ESM(ES Modules)가 등장하기 전까진 Javascript 모듈화를 네이티브 레벨에서 진행할 수 가 없었습니다. 따라서 개발자들은 번들링(bundling)이라는 우회적인 방법을 사용할 수 밖에 없었습니다. (번들링: 모듈화된 소스 코드를 브라우저에서 실행할 수 있는 파일로 한데 묶어 연결해주는 작업) 이 같은 상황에서 webpack, rollip 같은 도구로 번들링 작업을 하며 프론트엔드 개발자의 생산성을 향상 시켰습니다. 하지만, 1000개가 넘는 JavaScript 모듈이 있는 거대한 프로젝트라면 어떨까요? 실제로 이러한 상황을 어렵지 않게 마주할 수 있으며, 이 경우 Webpack과 같은 JavaScript 기반의 도구는 병목 현상이 발생하곤 합니다. (개발 서버를 실행하는 데 있어 비합리적..

웹팩 이전의 script 태그를 가져오는 방식 아래 방식의 단점 1. 변수 이름 충돌의 가능성 script 태그의 module 타입 사용하기 아래처럼 script 태그의 type의 module을 사용하면 변수 충돌 가능성을 배제시킬 수 있다. 각각의 word 변수는 각각 모듈 안에서만 유용하다 아래 방식의 단점 1. 오래된 웹브라우저에서 호환성이 낮다. 2. 자바스크립트 파일을 모두 다운로드 받아야 하므로 리소스 가 많이 든다. hello.js var word = "Hello"; export default word; world.js var word = "World"; export default word; 웹에서도 모듈의 개념을 사용하고, 여러개의 파일을 하나로 묶어 제공하고 싶다는 생각이 반영된 것이 바..