angular 공유 의존 솔루션 공유

webpack-ng-dll-plugin

ng 버전에서 사용할 수 있는 dll 플러그인, 방법이 비교적 야만적입니다.

용도

포장 속도를 높인다

코드 재사용(미세프런트엔드 의존 공유)

활용단어참조

우선 개인의 익숙도에 따라 @angular-devkit/build-webpack, @angular-builders/custom-webpack,ngx-build-plus

첫 번째는 공식적이고 두 번째는 제3자입니다. 하지만 연습을 한 적이 있는지 확인하기 전에 공식적인 것을 선택하지 마세요...
저자가 테스트를 할 때 선택한 것은 @angular-builders/custom-webpack입니다.

먼저 dll을 구축하고 빈 프로젝트로 dll을 만드는 것을 권장합니다. 현재 개발에서 복잡한 논리의 실현과 관련 제3자 패키지의 의존 관계 보존(full 모델은 실현할 수 있어야 한다는 이론)을 고려하지 않았기 때문입니다

그리고 구축할 때 인용

인용은 웹 팩의 정상적인 인용 플러그인이면 ok입니다.
맛보다
다음 함수는 index를 필터했습니다.html,styles,polyfills,License 출력,runtimeChunk 사용 안 함

 setNgDllPlugin(
 config,
 {
  //webpack  out 
  output: {
  filename: 'dll.js',
  },
  ngDllPluginOptions: {
   // dll 
  path: path.join(__dirname, 'dist', 'manifest.json'),
  name: 'TLIB',
  format: true,
  filter: {
   //  ,full ,auto ,manual  ( map)
   mode: 'auto',
  },
  },
 },
 options
 );

사용자 정의
관련 설정은 참고가 필요합니다. (잠시 문서를 쓰지 않았습니다. 원본 코드를 보셔야 합니다.)

 config.plugins.push(new NgDllPlugin(option.ngDllPluginOptions));

인용하다

//  context ( ) ( dll.js, , dll.js , ), , 
 config.plugins.push(
 new webpack.DllReferencePlugin({
  context: path.resolve(__dirname),
  manifest: require('./dist/manifest.json'),
 })
 );

프레젠테이션 주소
https://github.com/wszgrcy/ng-cli-plugin-demo
잠금 해제 가능한 기술

분체식 루트 로드

정상적인 상황에서 동적 불러오는 루트라도 프로젝트와 함께 포장하는 것은 단지 두 개의 파일로 포장하는 것에 불과하다
주체 프로젝트는 먼저 포장한 후에 단독으로 게으른 로드 루트 모듈을 개발한다

웹-component의 사용률 상승

ng는 이미 이것을 실현했지만 매번 큰 가방을 싸면 단독 프로젝트를 한 셈이다. 매우 방대하다. dll을 사용하면 무서운 수준으로 줄어들고 부작용은 0에 가깝다
현재 존재하는 문제

자원 명세서가 출력하는 것은 전량의 인용이지만, 실제로는 모드:'full'때만 등가이다

수정하지 않은 것 중 하나는 주로 영향이 크지 않은 데다가 디버깅 수요도 있다

dll을 생성하는 프로젝트에 동적 로드 모듈이 있으면 알 수 없는 영향이 있을 수 있습니다.

dll은 디자인할 때 동적 모듈 같은 것을 전혀 고려하지 않았다. 완전히 큰 가방만 싸는 것이다
가능한 한 빈 항목으로 dll 생성

auto는 현재 생성된 프로젝트가 완전한 인용에 도달할 수 있음을 나타낸다. 프로젝트를 수정하면 프로젝트를 다시 구축해야 한다(액. 폐기물로 보이는 모델)

사실 프로젝트 코드가 충분하면(각종 종류) 코드 수정은 영향을 주지 않지만, 예를 들어 일부 도입이 처음 사용되거나 html 템플릿에서 새로운 것을 사용했기 때문에 다시 구축해야 한다
개선을 기다리다
영원히 사용할 수 없는 일부 내보내기를 자발적으로 배제하다
왜 dll이 직접 포장보다 커요?

dll포장은 현재 ng의 aot, 나무 흔들기 등 관련 최적화 기술을 사용하고 있지만 치명적인 문제가 있다. 바로 유명해지는 것이다. 기본적으로 포장할 때 모든 이름이 최적화(혼동)되고 dll포장은 반드시 이 이름을 노출해야 한다. 완전히 노출되면 부피가 증가한다.

현재 빈 프로젝트로 생성된 dll(rxjs,router,common,core 포함), 전량 폭력은 440k(즉 다른 가방을 사용할 때 이 파일들은 dll에서 찾을 수 있음), 선택적 내보내기는 216k 작용을 최소화하고 최종적으로 평균 300k 정도로 추정된다

현재 사용 중인 기술은 1.전체 내보내기, 2.사용 가능한 내보내기를 선택하면 부작용이 있습니다. 전체 내보내기 시.사용하지 않는 의존이 도출되었을 뿐만 아니라, 내부 인용도 있었다. (예를 들어ɵangular_packages_core_core_h)도 강제로 내보내져 가방 크기를 증가시켰다

후기에는 사실상 영원히 내보내지 않는 목록을 정리하여 배제함으로써 부피를 줄일 수 있다

전통적인 포장은 여러 모듈이 한 모듈을 포장하는데 중간에 많은 의존이 내부 의존에 속하기 때문에 많은 코드를 간소화했다. dll의 이런 포장은 여러 모듈에 속하기 때문에 각 모듈은 출구가 있고 인용도 사용하는 모듈 간의 인용이기 때문에 dll을 최소화해도 포장한 것보다 40k 정도가 많다

총결산
이쯤에서angular 공유 의존 솔루션에 관한 글을 소개합니다. 더 많은 angular 공유 의존 해결 내용은 저희 이전의 글을 검색하거나 아래의 관련 글을 계속 훑어보십시오. 앞으로 많은 응원 부탁드립니다!