한줄 요약
vite
번들러는global
객체를 기본적으로 참조하지 않기에 전역 객체를 사용하고자 하는 라이브러리는 에러가 발생할 수 있으며,vite
의 설정 파일에서 전역 객체에 대한 명시로 해결할 수 있다.
해결을 위한 코드.!
// vite.config.js
define: {
global: 'window',
}
WebSocket
통신을 위한 라이브러리!
우선, 웹소켓 연결을 위한 라이브러리로 크게 두 가지가 있다.
Sock.io
Node
기반 서버와의 웹소켓 연결 시 사용Sock.js
Spring
기반 Java 서버와의 웹소켓 연결 시 사용이 중 프로젝트 당시에는 Sock.js
사용했고, 이와 관련해 발생한 충돌 문제와 해결한 경험에 대해 공유하겠다.
vue
개발팀에서 개발한 Go언어 기반이ESBuild
를 사용해 기존 번들러보다 10~100배 빠른 개발 서버 구동시간을 보여주는 경량화에 집중한 번들러!
-> 참고 글 Vite, 바이트? 비트!
웹소켓 연결을 위해 Sock.js
라이브러리를 활용해 웹소켓 객체를 만들어 통신 연결을 시도하였을 때, 아무런 에러 로그가 출력되지 않은 채 연결이 되지 않는 상황이 발생하였다.
연결 및 에러에 관련한 로그가 찍히게 설정해두었기에 내부적으로 충돌이 일어났음을 직감!
우선 비슷한 상황에 대한 레퍼런스가 있는지 열심히 찾아보았다.
하지만 Sock.js
라이브러리가 아무런 로그도 찍히지 않은 채 연결이 되지 않는 비슷한 현상은 찾을 수 없었고, 흔하디 흔한 라이브러리의 버전 충돌 및 호환성을 의심해보며 문제가 되는 Sock.js
라이브러리와 다른 라이브러리 간의 호환성에 대해 찾아보고 혹시 모를 충돌을 발견하기 위한 시도를 해보았다.
많은 라이브러리들을 삭제했다 설치하는 세상에서 가장 싫은 경험.
첫 번째 시도는 아무런 소득을 얻지 못한 채 종료되었다,
이후 차분하게 다시 시도해보기 위해 간단하게 웹소켓 연결만을 위한 프로젝트를 생성했고, 해당 프로젝트는 Webpack
번들러를 사용해(CRA로 빠르게 만드렀다.) 후딱 만들어서 연결해보았다.
결과는 물흐르듯 자연스러운 연결!!?
이 결과를 토대로 번들러에 문제가 있지 않을까 하는 합리적인 의심을 하게 되었다.
이제 다시 문제 해결을 위한 시도를 해볼 차례다.
vite
번들러와 Sock.js
라이브러리 간에 대해 포커스를 맞추어 관련 레퍼런스를 찾아보기 시작했다.
vite
번들러는 만들어진지 비교적 최근이기에 생태계가 얕다는 단점이 있는데, 이를 몸소 체험해버렸다.
관련한 검색 결과는 전무했다! 찾기 위해서 모든 글을 찾아보고, 양측의 공식 문서들도 문제가 생길만한 부분을 정독해보고 디스코드의 vite
개발자 채널에 들어가 질문도 남겨보았지만 해결되지 않았다.
온갖 깃허브 이슈도 찾아보았지만,,,
하지만 주저 앉을 수 없지!
공식 문서를 열심히 다시 꼼꼼히 읽어보았다. 그 결과 vite
의 공식 문서에서 "global
" 객체를 참조하지 않는다.! 라는 정보를 알게 되었고,
여기서 한 가지 생각이 들게 되었다.
Sock.js
에서 전역 객체를 사용하는 로직이 있다면, 번들링을 거쳐 빌드되었을 때,undefined
를 마주쳐 연결이 안되는 것이 아닐까?
vite 번들러의 설정 파일에서 전역 객체에 대한 참조 설정을 해주니 언제 그랬냐는듯 원활한 웹소켓 통신 연결이 이루어졌다.
허!!!
define: {
global: ‘window’
}
브라우저의 환경에서 동작할 프로젝트이기에 전역 객체는 window
로 정의해두었다.
여기서 궁금한 점은 왜 웹팩은 전역 객체를 참조해 두었고, 비트는 전역 객체를 참조하지 않은채 개발자에게 선택권을 넘겼나.
vite
번들러는 최신 표준을 준수하고 경량화를 중시하며, 주로 브라우저 환경에서의 개발을 목표로 하고 있기 때문인 것 같다.
최신 자바스크립트 표준에서는 전역 객체 대신 모듈 시스템을 권장하고, 빠른 빌드 속도와 경량화를 위해 불필요한 객체 정의를 줄인 것으로 생각된다.
Webpack
에서는 기존 노드 모듈과의 호환성, 브라우저 및 노드까지 포함한 개발 환경 등 전역 객체를 사용할 일이 있기에 미리 정의해둔 것으로 생각된다.