배경
문법 수준에서 모듈을 지원하기 시작한 것은 ES2015부터이다. import/export 구문이 없었던 모듈 이전 상황을 살펴보는 것이 웹팩 등장 배경을 설명하는데 수월할 것이다.
ex)
math.js
function sum(a, b) { return a + b; } //전역 공간에 sum이 노출
app.js
sum(1, 2);
위 코드는 모두 하나의 HTML 파일 안에서 로딩해야만 실행된다. math.js가 로딩되면 app.js는 이를 공간에서 sum을 찾은 뒤 이 함수를 실행한다. 문제는 sum이 전역 공간에 노출된다는 것. 다른 파일에서도 sum이란 이름을 사용한다면 충돌한다.
IIFE 방식의 모듈
IIFE(Immediately Invoked Function Expression, 즉시 실행 함수 표현)
이러한 전역 스코프 오염 문제를 해결하기 위해 스코프를 사용한다. 함수 스코프를 만들어 외부에서 안으로 접근하지 못하도록 공간을 격리하는 것. 스코프 안에서는 자신만의 이름 공간이 존재하므로 스코프 외부와 이름 충돌을 막을 수 있다.
다양한 모듈 스펙
자바스크립트 모듈을 구현하는 대표적인 명세가 AMD와 CommonJS다.
CommonJS는 자바스크립트를 사용하는 모든 환경에서 모듈을 하는 것이 목표. exports 키워드로 모듈을 만들고 require() 함수로 불러 들이는 방식. 대표적으로 서버 사이드 플랫폼인 Nodejs에서 이를 사용한다.
AMD(Asynchronus Module Definition)는 비동기로 로딩되는 환경에서 모듈을 사용하는 것이 목표. 주로 브라우저 환경
UMD(Universal Module Definition)는 AMD기반으로 CommonJS방식까지 지원하는 통합 형태.
ES2015에서 표준 모듈 시스템을 만들었다. 지금은 바벨과 웹팩을 이용해 모듈 시스템을 사용하는 것이 일반적이다.
ex ES2015 표준 모듈 시스템)
// math.js
export function sum(a, b) {
return a + b;
}
// app.js
import * as math from '/math.js'
console.log(math.sum(1, 2));
하지만 모든 브라우저에서 모듈을 지원하는 것은 아니다.
엔트리/아웃풋
웹팩: 모듈로 정의된 js파일을 하나로 번들링 하는 역할
엔트리: 자바스크립트의 의존관계의 시작점을 나타냄
아웃풋: 번들링된 결과를 저장하는 경로
ex)
webpack.confing.js
const path = require('path');
module.exports = {
mode: 'development',
entry: {
main: './src/app.js',
},
output: {
filename: '[name].js',
path: path.resolve('./dist'),
},
}
npm run build
index.html
<html>
...
<script src="./dist/main.js"></script>
...
</html>
'FRONT-END > 개발환경' 카테고리의 다른 글
| webpack asset modules(file-loader) v5 (0) | 2022.06.06 |
|---|---|
| webpack (file-loader) v5 이전 (0) | 2022.06.06 |
| webpack (loader) - css, style (0) | 2022.06.03 |
| npm (0) | 2022.06.03 |