vue webpack 포장 최적화 조작 기법

설 이 다가 오자 회사 의 많은 동료 들 이 미리 집 으로 돌아 가 설 을 쇠 고 나머지 인원 들 은 선도 에 따라 bug 를 수정 합 니 다.bug 수정 이 끝 난 후에 우 리 는 다시 포장 하여 운영 하고 테스트 복 에 올 라 테스트 동료 에 게 테스트 를 해 야 합 니 다.그러나 프로젝트 의 본체 가 비교적 크기 때문에 포장 시간 이 너무 깁 니 다(25 분 이상:sob:).그래서 포장 을 최적화 하 겠 다 는 생각 이 들 었 습 니 다.
웹 팩 은 react 프로젝트 에 표 시 된 포장 도구 로 NPM 과 조합 하여 관리 모듈 을 사용 하 는 것 이 매우 편리 합 니 다.
  webapck 은 모든 정적 자원 을 하나의 module 로 보고 webpack 을 통 해 이 module 들 을 하나의 bundle 에 구성 하여 현재 페이지 에 bundle.js 를 도입 하여 모든 정적 자원 의 로드 를 실현 합 니 다.
말 이 많 지 않 으 니 바로 본문 을 시작 합 시다
먼저 프로젝트 의 디 렉 터 리 구 조 를 보 여 드 리 겠 습 니 다.
 
바로 정상 적 인 프로젝트 구조 입 니 다.간단하게 말씀 드 리 겠 습 니 다.

build 폴 더 는 패키지 설정 을 포함 하고 있 습 니 다

config 폴 더 는 프로젝트 의 기본 설정

dist 는 포 장 된 파일

node_modules 는 프로젝트 의존 패키지

src 폴 더 안 은 프로젝트 의 원본 코드

static 폴 더 에 일부 항목 이 사용 하 는 정적 자원

이 들 어 있 습 니 다.

index.html 는 프로젝트 의 첫 페이지

package.json 파일 은 프로젝트 의 설정 json

yarn.lock 은 yarn 잠 금 항목 을 사용 하 는 의존 입 니 다.

사고의 방향 을 최적화 하 다.
프로젝트 포장 시간 이 긴 이 유 는 프로젝트 전체 가 비교적 크 고 복잡 하 며 구성 요소 에 의존 하기 전에 분리 하 는 것 이 합 리 적 이지 않 기 때문이다.
이 세 가지 문제 에 대해 우 리 는 아래 의 이 몇 가지 측면 에 대해 처리 할 수 있다.

프로젝트 를 차단 하고 자신 이 포장 해 야 할 부분 만 포장 합 니 다.개발 과정 에서 많은 일 을 절약 하 였 으 나,지금 은 똑 같이 갚아 야 한다!!!)

의존 관계 가 복잡 하 다.여기 서 말 하 는 것 은 프로젝트 의 의존 모듈 이 비교적 많다 는 것 이다.현재 우리 프로젝트 처럼 가방 에 의존 하 는 것 만으로 도 40+가 있 고 다른 중요 한 원인 은 구성 요소 간 에 똑 같은 인용 의존 이 존재 한 다 는 것 이다.해결 방향 은 프로젝트 에서 중용 되 는 의존 을 분리 하여 단독 포장 하 는 것 이다.

구성 요 소 는 작성 하 는 과정 에서 이 구성 요소 의 사용 방향 과 실현 기능 을 잘 고려 해 야 하 며 혼동 해 서 는 안 된다.

실제 조작
전체적인 사고 가 생 겼 습 니 다.그러면 시작 하면 됩 니 다.웹 팩 문서 에 가서 DllPlugin 이 있 습 니 다.이 플러그 인 은 바로 우리 가 문 제 를 해결 하 는 관건 입 니 다.다음은 제 웹 팩.dll.config 의 코드 입 니 다.

var path = require("path");
var webpack = require("webpack");
function resolve (dir) {
 return path.join(__dirname, '..', dir)
}
module.exports = {
 //            
 entry: {
 vendor: ['vue', 'lodash', 'vuex', 'axios', 'vue-router', 'iview', 'element-ui',
  'echarts','xlsx','jquery','vue-fullcalendar','vue-cookie','handsontable']
 },
 output: {
 path: path.join(__dirname, '../dist/vendor-dll-js'), //           
 filename: '[name].dll.js',
 library: '[name]_library'
 // vendor.dll.js          。
 //     DllPlugin  name  ，
 //       webpack.DllPlugin  `name: '[name]_library',`    。
 },
 resolve: {
 extensions: ['.js', '.vue', '.json'],
 alias: {
  'vue$': 'vue/dist/vue.esm.js',
  '@': resolve('src'),
 }
 },
 plugins: [
 new webpack.DllPlugin({
  path: path.join(__dirname, '.', '[name]-manifest.json'),
  name: '[name]_library',
  context: __dirname
 }),
 //        ，        
 new webpack.optimize.UglifyJsPlugin({
  compress: {
  warnings: false
  }
 })
 ]
};

프로젝트 에서 재 활용 성 이 있 는 패 키 지 를 추출 하여 vendor 배열 에 넣 은 다음 에 아래 output 에서 압축 출력 된 파일 경 로 를 정의 한 다음 resolve 에 분석 파 라 메 터 를 설정 하고 마지막 으로 사용 하 는 DllPlugin 플러그 인 을 정의 해 야 합 니 다.UglifyJSPlugin 은 js 를 압축 하 는 플러그 인 입 니 다.
Dllplugin 에 있 는 path 는 하 나 를 출력 합 니 다vendor-manifest.json.이것 은 관련 id 를 만 드 는 것 입 니 다.포장 할 때 포장 되 지 않 기 때문에 static 에 넣 지 않 고 실행 할 필요 가 없습니다 webpack -p --progress --config build/webpack.dll.conf.js성공 하면 static 에 dll.vendor.js 가 있 습 니 다.루트 디 렉 터 리 에vendor.manifest.json 각각 열 어 보면 라 이브 러 리 에 의존 하 는 소스 코드 와 일치 하 는 id 를 볼 수 있 습 니 다.
ok,여기까지.의존 라 이브 러 리 에서 벗 어 나 는 일이 완성 되 었 습 니 다.그러면 다음 문 제 는 어떻게 인용 하 느 냐 하 는 것 입 니 다.어떻게 dev 와 build 에서 뛰 느 냐 하 는 것 입 니 다.
여기 서 dll 과commonsChunk개념 상의 차 이 를 보완 했다.comons Chunk 가 느 리 고 큰 이 유 는 run 할 때마다 포장 을 한 번 하기 때문이다.실제로 우 리 는 우리 가 인용 한 의존 라 이브 러 리 를 계속 업데이트 하지 않 기 때문에 dll 의 방법 은 의존 라 이브 러 리 를 미리 포장 한 다음 에 매번 수정 하 는 js 에 만 포장 하 는 것 과 같다.
위의 절 차 를 계속 진행 하려 면 생 성 된 json 파일 에 따라 webpack.base.config 파일 을 수정 해 야 합 니 다.

const manifest = require('../vendor-manifest.json')
......
plugins: [
 new webpack.DllReferencePlugin({
  manifest
 })
 ]

그리고 index.html 를 열 고 밑 에<script src="./static/dll.vendor.js"></script>를 추가 합 니 다.
실행 해 보 세 요npm run build .같이 정상 이면 당신 의 조작 이 정확 하 다 는 것 을 의미 합 니 다.
업그레이드 처리
이로써 최 적 화 된 문 제 는 기본적으로 해결 되 었 지만 처리 과정 에서 복사 붙 여 넣 기 를 해 야 하고 index.html 파일 을 조작 해 야 합 니 다.프로젝트 에 익숙 하지 않 은 사람 이 개발 프로젝트 를 진행 하면 작은 문제 가 발생 하기 때문에 저 는 계속 연구 하기 로 결 정 했 습 니 다.
사고방식 은 위의 사고방식 이다.우리 가 다음 에 해 야 할 조작 은 바로 이전의 처리 와 최적화 하고 파일 설정 과 명령 을 통 해 우리 가 원 하 는 효 과 를 실현 하 는 것 이다.
우선 위 웹 팩.dll.config 파일 에 있 는 entry 설정 항목 을 꺼 내 config 폴 더 아래 dll.js 를 새로 만 듭 니 다.

module.exports = {
 entry: {
 //           ：        ，        （             ）
 ui: ['iview', 'element-ui'],
 tool: ['lodash', 'jquery', 'axios', 'vue-fullcalendar'],
 vue: ['vue', 'vuex', 'vue-router', 'vue-cookie'],
 xlsx: ['xlsx'],
 echarts: ['echarts'],
 other: ['handsontable'],
 },
 outFile: '../static/dll'
};

이 안 은 사실 우리 가 처음에 쓴 entry 의 설정 항목 입 니 다.이 js 에 따라 포장 한 파일 은 순서 가 있 습 니 다.바로 제 가 정리 한 것 입 니 다.
여기 서 의존 순 서 는 대상 이 위 에서 아래로 의존 하고 배열 은 오른쪽 에서 왼쪽으로 의존 해 야 합 니 다.(서로 의존 하지 않 으 면 순 서 를 무시 할 수 있 습 니 다)
이 순서대로 쓰 지 않 으 면 오류 에 의존 하 는 문제 가 생 길 수 있 습 니 다!!!
그리고 output 에서 설정 을 다시 진행 합 니 다:

output: {
 path: path.join(__dirname, dllConfig.outFile), //           
 filename: '[name].dll.[chunkhash].js',
 library: '[name]_library'
 //     DllPlugin  name  ，
 //       webpack.DllPlugin  `name: '[name]_library',`    。
 },

이렇게 하면webpack -p --progress --config build/webpack.dll.conf.js 명령 을 실행 할 때 다음 과 같이 생 성 됩 니 다.
 
파일 뒤에 있 는 hash 를 보고 어리둥절 한 표정 을 짓 는 거 아니 야?어 떡 해?복사 붙 여 넣 을 방법 이 없어!!우리 의 목적 은 복사 붙 여 넣 기 를 하지 않 는 것 이 아 닙 니까?진지 한 얼굴- -)
명령 을 실행 한 후 복사 붙 여 넣 기 동작 을 하지 않 으 려 면 웹 팩 의 HtmlWebpackPlugin 플러그 인 을 사용 해 야 합 니 다.
plugins 에 Html WebpackPlugin 을 설정 합 니 다.

new HtmlWebpackPlugin({
 filename: path.join(__dirname, '../', config.dev.index),
 template: 'index.ejs',
 inject: false
}),

그리고 루트 디 렉 터 리 에 index.ejs 모드ejsGitHub 주소를 추가 합 니 다.index.ejs 의 코드 는 다음 과 같 습 니 다.

<body>
 <div id="app"></div>
 <!-- dll files will be auto injected -->
 <% for (var chunk in htmlWebpackPlugin.files.chunks) { %><script type="text/javascript" src="/<%= htmlWebpackPlugin.files.chunks[chunk].entry %>"></script>
 <% } %>
 <!-- built files will be auto injected -->
</body>

마지막 으로 config 폴 더 에 있 는 index.js 를 수정 해 야 합 니 다.dev 에 추가:index: 'index.html',
프로젝트 는 dev 명령 이나 build 명령 을 실행 하기 전에 먼저 실행 해 야 합 니 다.webpack -p --progress --config build/webpack.dll.conf.js dll 명령 이 끝 난 후에 다른 작업 을 수행 하면 완벽 하 게 놀 수 있 습 니 다:blush:
총결산
이로써 코드 포장 최적화 의 전체 과정 은 기본적으로 끝 났 습 니 다.테스트 를 해 보면 15 분 정도 에 포장 을 완성 할 수 있 습 니 다.이전 포장 보다 10 분 가까이 빨 라 졌 습 니 다.매우 성공 적 인 시도 라 고 할 수 있 습 니 다!!