2020 년 6 월, Angular 10 은 다양한 새로운 기능과 수정 사항과 함께 출시되었습니다. 구현 된 새로운 기능 중 하나는 CommonJS 모듈을 사용하여 패키징된 종속성이있는 애플리케이션을 빌드할 때 표시되는 경고입니다.

이 경고의 이유는 CommonJS 모듈을 사용하면, 프로덕션 빌드를 수행할 때 번들 크기가 커질 수 있기 때문입니다. 번들 크기 증가는 CommonJS가 디자인된 방식으로 인한 것이지만, 해당 내용에 대해서는 나중에 더 자세히 다뤄보겠습니다. 응용 프로그램의 성능에 관심이 있고 CommonJS 모듈을 사용하는 경우 ES 모듈 (EcmaScript 모듈)이라는 다른 옵션이 있습니다.

이 포스팅에서는 선택한 모듈 포맷팅 시스템이 번들링 크기에 미치는 영향, CommonJS 문제, ES 모듈이 문제를 해결하는 방법, Wijmo를 사용할 때 ES 모듈을 구현할 수있는 방법을 검토합니다.

모듈 및 번들 크기

모듈은 개발자가 모듈 범위를 통해 변수와 함수를 더 잘 구성할 수 있는 방법입니다. 모듈 범위는 전역 범위와 같이 생각할 수 있습니다. 모듈 범위에서 사용할 수 있는 변수와 함수는 모듈 범위에 대한 액세스 권한이 있는 다른 모듈에서도 액세스할 수 있습니다.

다른 모듈에서 사용할 수 있도록 하는 것을 "export"라고합니다. export를 만든 후에는 다른 모듈이 해당 클래스를 가져올 수 있으며 해당 변수, 클래스 또는 함수에 종속됨을 명시적으로 나타냅니다.

애플리케이션이 모듈 간에 변수와 함수를 가져오고 내보낼 수 있게 되면, 해당 기능을 위해 가져온 작은 덩어리로 분리하여 응용 프로그램을 보다 쉽게 구성할 수 있습니다.

이제 여러 파일에 걸쳐 변수와 기능이 분리되므로, 이제 애플리케이션은 프로덕션 빌드를 수행할 때 모든 것을 함께 묶어야 할 것입니다. 모듈 시스템이 가져오기 및 내보내기 기능을 처리하는 방식과, 가져오기에 필요한 모듈 시스템의 결정에 따라 번들의 크기가 달라지게됩니다.

모듈은 매우 유용하기 때문에 모듈/모듈 기능을 JavaScript로 가져오려는 시도가 여러번 있었습니다. 가장 널리 사용되는 두 가지 모듈 시스템은 CommonJS 및 ES 모듈입니다.

CommonJS 및 ES 모듈

CommonJS는 2009 년에 출시 된 JavaScript 용으로 만들어진 모듈 형식화 시스템입니다. 그 이후로 JavaScript 코드를 구조화하고 구성하는 표준이되었습니다. 원래 서버 측 애플리케이션 용으로 설계된이 표준은 NodeJS가 모듈 관리를 구성하는 방법에 큰 영향을 미쳤습니다.

CommonJS를 사용하면 모듈을 정의하고 모듈에서 기능을 내보내고, require 함수를 사용하여 다른 모듈로 가져올 수 있습니다.

예를 들어, 모듈에서 내보낼 수 있는 사용자 입력을 확인하는 함수가있는 경우 require 함수를 사용하여 다른 모듈에 대한 액세스 권한을 부여할 수 있습니다.

// verify.js
exports.verifyInput = (userInput) => /* code implementation */

// index.js
const { verifyInput } = require(‘./verify.js’);
…
const validData = verifyInput(userInput);

verifyInput 함수가 export로 제공되었으므로, 이제 index.js 파일 내에서 require 메소드를 사용하여 해당 기능을 가져와서 사용할 수 있습니다. 

CommonJS는 처음에 서버 측 애플리케이션에서 사용하기 위해 만들어 졌기 때문에, 클라이언트 측 애플리케이션에서 실행하면 서버 측 애플리케이션에서 중요하지 않은 성능 비용이 발생했습니다. 그러나 CommonJS가 만들어 졌을 때, 브라우저에서 사용할 수 있는 다른 표준화 된 모듈 시스템이 없었기 때문에 JavaScript 클라이언트 측 라이브러리에서 널리 사용되는 모듈 형식 시스템이되었습니다.

클라이언트 측 애플리케이션에 대한 이러한 성능 및 최적화 문제로 인해 브라우저를 염두에두고 ES 모듈이 작성되었습니다.  가져오기(import) 및 내보내기(export) 기능은 CommonJS의 기능과 매우 유사합니다. 변수와 함수를 가져 오는 데 require 를 사용 하는 대신 import 문을 사용합니다 .

// verify.js
exports.verifyInput => /* code implementation */

// index.js
import verifyInput from ‘./verify.js’;
…
const validData = verifyInput(userInput);

ES 모듈과 CommonJS의 가장 큰 차이점은 모듈이로드되는 방식입니다. CommonJS는 더 동적이고 ES 모듈은 더 정적입니다.

예를 들어, 다른 모듈에서 기능을 가져올 때 CommonJS를 사용하면 변수를 경로에 전달할 수 있지만 ES 모듈에서는 문자열 리터럴이어야합니다.

// CommonJS
const { verifyinput } = require(‘./${path}/verify.js’);

// ES Modules
import verifyInput from (‘./${path}/verify.js’); // Will not work
import verifyInput from (‘./login/verify.js);   // Will work

CommonJS는 종속성이 로드되는 방식 때문에 이러한 동적 접근 방식을 취할 수 있습니다. CommonJS가 모듈을 로드해야하는 경우, 런타임에 수행됩니다. 모듈은 한 번에 로드, 인스턴스화 및 평가됩니다. 이것이 파일 경로에 변수를 전달하는 것과 같은 작업을 수행 할 수있게 해주는 것입니다. 이 작업은 런타임에 수행되기 때문에 응용 프로그램에서 트리 쉐이킹을 수행하기가 더 어려워집니다.

트리 쉐이킹(Tree-Shaking)은 애플리케이션이 파일에서 사용하지 않는 기능을 제거하여 애플리케이션을 더 작게 만들 수 있는 경우입니다. 사용하지 않는 기능, 주석 및 중복 공백을 제거하는 것과 같은 것입니다.

CommonJS는 런타임시 모두 로드, 인스턴스화 및 평가하기 때문에 트리 쉐이킹이 발생하기 어렵고 효율성이 떨어집니다. 트리 쉐이킹이 발생할 수 있는 이유는 웹팩(webpack )이 우리가 무엇을 가져오고(import) 무엇을 내보낼지(export) 정적으로 (빌드 시에) 이해할 수 있는 능력 때문이었습니다.

ES 모듈에는 이와 같은 문제가 없습니다. ES 모듈은 CommonJS보다 정적이기 때문에 더 정적으로 분석 할 수 있습니다. 발생하는 로드, 인스턴스화 및 평가는 CommonJS와 같이 함께 사용하는 대신 개별적으로 수행 할 수있는 세 가지 다른 단계로 나뉩니다. 이를 통해보다 효율적인 트리 쉐이킹이 가능합니다.

Wijmo와 함께 ES 모듈 사용

Wijmo 2020v2의 출시와 함께 ES 모듈 사용을 지원합니다. ES 모듈 사용은 기본적으로 활성화되어 있으므로 ES 모듈을 사용하기 위해 어떤 조치도 취할 필요가 없습니다.

테스트 결과 Wijmo 구성 요소를 포함한 번들 크기가 약 30% 감소할 것으로 예상할 수 있었습니다.

아래에서 Wijmo와 함께 CommonJS와 ES 모듈을 사용할 때 번들 크기 감소에 대한 분석을 볼 수 있습니다.

참고 : 

Wijmo와 함께 CommonJS 모듈을 계속 사용하려면 다음 명령을 실행하면됩니다.

npm run wijmo-esm -- -disable

wijmo-esm 사용에 문제가있는 경우, 다음 명령을 실행하여 자세한 정보를 확인할 수도 있습니다.

npm run wijmo-esm -- -help

프로덕션 모드에서 애플리케이션을 빌드하려면 package.json 파일의 "scripts"섹션에 다음 명령을 추가해야합니다.

“prod": “ng build --prod",

그런 다음 npm run –prod 를 실행하여 애플리케이션을 빌드할 수 있으며 생성 된 dist 폴더 내에서 번들 파일을 볼 수 있습니다 .