node.js_node.js의 감시 메커니즘에 대한 자세한 설명

거의 모든 빌드 시스템은 개발 과정에서 빌드 후 파일이 반복적으로 생성되는 문제를 해결하기 위해 감시 메커니즘을 사용하도록 선택합니다. 그러나 감시 메커니즘에서는 저장 후 오랜 시간 동안 코드 수정을 견뎌야 합니다. 코드, 상쾌하기 전에 차를 마셔야 합니다. 효과를 보세요. 여기서 우리는 시계가 만능이 아닌 이유를 탐구하고 이 문제에 대한 더 나은 해결책을 찾으려고 노력합니다.

시계의 기반이 되는 사실

파일이 수정되면 수정으로 인해 발생할 수 있는 파일 수정 사항을 알 수 있으며 해당 파일을 다시 빌드할 수 있습니다.

일반적으로 파일 A가 파일 B로 구성되는 시나리오의 경우 이러한 대응은 매우 확실합니다. 그러나 실제 시나리오에서는 건설 과정이 그렇게 간단하지 않은 경우가 많습니다. 예:

파일 A + 파일 B(파일 A에서 참조) -> 이 시나리오에서는 파일 B가 수정되면 파일 B를 참조하는 파일이 많을 수 있으므로 빌드 작업을 다시 실행해야 하는 파일을 찾는 것이 어려울 수 있습니다.

종속성 트리를 구축하고 파일이 업데이트될 때마다 종속성 트리를 업데이트하고 새 종속성 트리를 기반으로 파일 빌드를 트리거하지 않는 한. 그러나 각 플러그인은 이 메커니즘을 자체적으로 구현해야 하며 오류가 발생하기 쉽습니다. 따라서 실제로 감시 메커니즘은 전체 작업을 다시 실행합니다. 따라서 프로젝트가 점점 더 커지면 감시 메커니즘은 점점 더 느려질 것입니다(캐싱을 통해 전체 프로세스에 필요한 시간이 줄어들더라도 전체 프로세스를 다시 실행해야 하는 파일이 점점 더 많아지기 때문입니다).

솔루션

src를 직접 사용 가능

대표적인 대표자로는 LESS, React 등이 있습니다. 하지만 몇 가지 문제도 있습니다.

브라우저 측에서는 우아한 구성 방법을 구현하기 어렵고, 개발 비용을 더욱 절감할 수 있는 강력한 기능을 제공하기가 어렵습니다. 대부분은 스크립트입니다.

개발 모드의 실행 순서는 반드시 실제 시나리오와 동일하지 않아 눈에 보이지 않는 버그가 발생할 수 있습니다. 예를 들어 HTML 인라인을 구현할 때 개발 모드에서는 인라인이 비동기인 반면 릴리스 모드의 인라인은 동기이므로 설명할 수 없는 결과가 발생합니다. 버그.

예를 들어, js 버전의 sass 컴파일 속도는 거의 견딜 수 없을 정도입니다.
온라인과 오프라인 건설 시스템 두 세트를 유지해야 하므로 도구 개발 비용이 증가합니다.
로컬 서버 동적 빌드

한 가지 사실은 합리적인 사양이 지원되면 파일 구성 과정에서 브라우저가 요청한 파일을 항목 파일로 역추적할 수 있다는 것입니다. 이렇게 하면 빌드 프로세스를 동적으로 트리거할 수 있습니다.

서버를 로컬로 설정하면 서버가 요청을 캡처하고 서버에서 동적으로 구축할 수 있습니다. 항목 파일을 추적하는 한, gulp 플러그인으로 구성된 파이프라인에 항목 파일을 넣을 수 있으며 출력은 브라우저에 필요한 파일이 됩니다.

이렇게 하면 위의 모든 문제를 해결할 수 있습니다.