npm 배포의 두려움 (Zustand 라이브러리)

우리가 지속적으로 zustand와 서버 상태관리를 위한 미들웨어를 만드는걸 목표로 진행했는데, 미들웨어를 만들어서 등록하는 방식도 잘 모를뿐더러 기존의 존재하는 미들웨어들의 구현 코드를 만들기 어렵다고 생각해서 라이브러리를 구현하는 것으로 결정했다.

이후 만들어진 코드를 npm build를 통해 다른 프로젝트에서 사용되는지 알아보고자 했는데 config 파일들의 의존성에 오류가 생기면서 동작자체를 확인할 수 없었다.

처음에는 zustand나 vite같은 라이브러리들의 의존성이 존재하면 안된다고 생각했는데 해당 라이브러리를 통해 동작하는 코드이기에 무조건적으로 필요한 것이였다.

덕분에 npm 배포에 관한 지식이 하나 더 생겼다.

또 오늘 우리 팀이 이뤄나갈 Todos를 정리했다.

1. 타입을 확장하는 방향 => 감이 아직 안 잡힘
2. useQuery? 아니 우린 Zquery
3. zustandQuery를 담고 있는 store에 접근 제한 여부 >> 현재로써는 고려할 사항이 너무 많음 추후 발전 예정
4. 정체성? Provider 없음, 서버상태를 추가적인 store 리소스의 할애 없이 전역 상태와 같이 관리 가능, 같이 관리하기 때문에 전역 상태와 서버 상태의 동기화가 가능합니다. 라이브러리 두 개로 나누어져 있기 때문에 고도화 된 기술은 커스텀이 필요합니다. 이는 어려워요 사실. 그래서 그것도 지원을 해줘버린다면 쓸 이유가 더 생기지 않을까?
5. 의존성? 어떤 의존성인지는 잘 모르겠습니다. 다시 한 번 말씀해 주세요...
6. fetch 함수의 batch 시스템 >> batch형태는 queue의 형태로 (먼저 들어온 함수를 실행하고 key값에 따른 유효성 검사)
7. 현재 인터페이스를 유지하는 형태로
8. 왜 Zustand를 사용하냐? 굳이 zustand인 이유가 있나? zustand에서 복잡한 비동기 작업을 처리 해 줄 수 없으니 확장을 통해 비동기 처리를 서버 상태의 형태로 zustand에서 같이 관리를 할 수 있게 해둔 확장 미들웨어입니다.
9. 어떤 고민을 담았는지는 어떤 구현 소통을 하였는지 >> 이슈나 PR에서 코멘트로 소통
10. 리서칭 과정, 개인 알고리즘 제작 등 혼자서 하는 과정 >> 개인 블로그로 기록
11. 마무리 후 정리 과정에서는 프로젝트 소개를 하여야 하니 Github Readme Docs 활용