자바스크립트 빌드시스템 인터롭

여러분이 자바스크립트 개발자라면, 이미 작업중인 프로젝트에 빌드 시스템이 있을 것 입니다. 리스크립트를 도입하려는 경우 빌드 파이프라인에서 rescript 가 할 수 있는 역할을 소개합니다.

제발 지금 여러분이 사용중인 증분 빌드 프레임워크에 rescript 를 래핑하지마세요. 리스크립트를 제대로 컴파일하는 것은 매우 어렵고, 최상위에 여러분이 만든 고유한 메타 레이어를 만든다면 필연적으로 부실하거나 성능이 떨어지는 빌드를 하게 됩니다. (우리가 추구하는 제안의 상당 부분이 지워집니다.)

인기있는 자바스크립트 빌드 시스템

자바스크립트 생태계는 몇가지 빌드 시스템을 사용합니다. browserify, rollup, webpack 그리고 기타 다른 빌드 시스템이 있습니다. 아마 2019년 기준으로 웹팩이 가장 인기 있을 것 입니다. 이들 빌드 시스템은 컴파일과 링킹을 모두 합니다. (아시다시피, 많은 파일들을 한개 또는 적은 파일로 번들링합니다.)

rescript 는 컴파일 단계만 처리합니다. 하나의 .res/.resi 파일을 하나의 자바스크립트로 만듭니다. 따라서 이론적으로 우리는 빌드 시스템의 통합이 필요하지 않습니다. 예를 들어 웹팩의 감시자의 입장에서 리스크립트가 만든 자바스크립트 파일은 손으로 직접 작성한 자바스크립트와 거의 동일합니다. 우리는 리스크립트가 만든 자바스크립트로부터 시작 하는 것을 추천합니다.

이말은,

기존 인프라를 건드리지 않고 코드베이스에 조용히 리스크립트를 적용할 수 있습니다.
res 파일을 업데이트 하고 자바스크립트 아티팩트가 변경될 때 자바스크립트 파일의 성능과 정확성에 대한 시각적인 차이를 가질 수 있습니다.
여러분의 팀원이 리스크립트를 배우기를 시작하지 않더라도 긴급 상황에서 자바스크립트 파일을 긴급 수정할 수 있습니다.
코드베이스에서 리스크립트를 완전히 삭제해도 (회사가 어떤 이유로든 사용을 멈춘다고 하더라도) 여전히 동작할 것 입니다.

더 나아지기 위해 빌드 파이프라인에서 rescript를 자동화 단계로 전환할 수 있습니다. 예를 들면 웹팩 로더를 사용할 수도 있습니다. 그러나 이러한 방식은 오류가 발생하기 쉬우므로 권장하지 않습니다.

팁 & 트릭

bsconfig.json 의 in-source + bs 접미사 설정을 이용해 리스크립트 자바스크립트 파일을 더욱 익숙하게 보이도록 만들 수 있습니다.

{
  "package-specs": {
    "module": "commonjs", // or whatever module system your project uses
    "in-source": true
  },
  "suffix": ".bs.js"
}

이를 통해:

리스크립트 소스 파일로부터 자바스크립트 파일을 만듭니다.
파일 확장자 .bs.js를 사용하면 로더 없이 require('./MyFile.bs') 를 이용하여 파일을 가져올 수 있습니다.

리스크립트에서 로더 사용하기

"리스크립트에서 내 빌드 시스템의 CSS/png/혹은 다른 로더를 사용하고 싶으면 어떻게 하나요?"

로더는 문제를 많이 일으킵니다. 여러분의 파일의 상단에 %raw("require('./myStyles.css')") 를 사용하세요. raw 만 사용하면 스니펫을 실제 자바스크립트 require 를 이용해 컴파일합니다.

프로젝트의 의존성 가져오기

rescript는 MyFile 하나마다 MyFile.d 파일을 만듭니다. lib/bs 에서 확인하실 수 있습니다. 이는 사람이 읽을 수 있고 기계 친화적인 MyFile 의 의존성 목록입니다. 필요한 목적이 있으면 읽을 수 있습니다. (IO 오버헤드에 유의하세요). 고유한 의존성 그래프를 만드는 대신 파일을 사용하세요. 우리는 가능한 최선을 다하여 의존성을 추적하기 위해 노력했습니다. (내부 모듈, open 그리고 모듈 이름 중복 포함 등)

빌드된 파일마다 스크립트 실행

js-post-build 을 살펴보세요. 이 방법은 주의해서 사용하세요. 각 파일이 빌드 된 다음에 node.js 스크립트를 연결하면 각 파일당 시작 노드 시간이 걸립니다!

고정 의존성

성능