>  기사  >  웹 프론트엔드  >  Webpack 서버측 코드 패키징

Webpack 서버측 코드 패키징

巴扎黑
巴扎黑원래의
2017-09-20 09:32:111668검색

이 글은 주로 Webpack 서버사이드 코드 패키징의 샘플 코드를 소개하고 있습니다. 편집자께서 꽤 괜찮다고 생각하셔서 지금부터 공유하고 참고용으로 올려드리겠습니다. 에디터를 따라가서 살펴볼까요

환경 변수

예전에는 프로젝트에서 process.env.NODE_ENV를 자주 사용했는데, 이 변수는 웹팩 패키징에 영향을 미치고, 프로덕션 과정에서 최적화됩니다.

그러므로 다른 환경 변수를 사용하여 다음을 구별하겠습니다.


new webpack.DefinePlugin({
 'process.env.NODE_ENV': '"production"',
 'process.env.API_ENV': `"${process.env.API_ENV || 'development'}"`
})

이렇게 NODE_ENV는 항상 프로덕션용입니다.

그리고 실제 개발/프로덕션 환경에서는 process.env.API_ENV 변수를 사용하여 ( 이 프로젝트는 Koa 인터페이스 서비스 프로젝트이므로 이렇게 이름을 지정하고 원하는 대로 변경할 수 있습니다.)

동적 구성 패키징

Note

저희는 node.js를 사용했습니다. js 백엔드 프로젝트에서 동적 구성 로딩은 일반적으로 다음과 같이 작성됩니다.


const ENV = process.env.NODE_ENV || 'development';
// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${ENV}`);

module.exports = options;

ENV의 가독성을 높이고 재사용 가능성을 높이기 위해 변수를 별도로 정의합니다.

웹팩 패키지 프로젝트에서 직접 수행하는 경우 , 예를 들어 지금 여러 구성이 있습니다.

  • _Develpment.js

  • _test.js

  • _production.js

  • _staging.js

환경은 개발 환경이며 모든 구성 파일은 여전히 ​​패키징되지만 실행되지는 않습니다. 이 경우 민감한 정보가 유출될 위험이 있습니다.

올바른 자세는 다음과 같아야 합니다:

config /index .js


// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${process.env.API_ENV || 'development'}`);

module.exports = options;

모듈식 패키징

예를 들어 프로젝트에 모듈이 많거나 로드 밸런싱이 필요하거나 고객 맞춤형 모듈 제품의 경우 다른 모듈을 방지하기 위해 모듈 내 패키지가 필요합니다. (절대 실행되지 않음) 서버에 로드할 때 다음과 같습니다.


// config/_development.js
exports.enabledModules = ['user', 'demo']; 
// 可能 src 目录下 还有其他模块目录, 如 'manage' 等

그런 다음 ContextReplacementPlugin이 필요합니다. 플러그인이 이를 지원합니다.

코드는 다음과 같습니다. 다음:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))

고급 사용


예를 들어, src 디렉토리에 있는 각 모듈의 디렉토리 외에도 lib 및 Hook과 같은 몇 가지 일반적인 메소드 클래스 및 후크 디렉토리가 있습니다. 플러그인 정규식: 코드는 다음과 같습니다:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${enabledModules.join('|')})/. * $`))

코드를 압축하고 소스 맵 지원을 추가하세요


Uglifyjs 또는 Uglify-es는 실제로 서버측 코드 패키징에 적합하지 않으며 babel-minify-webpack-을 사용하세요. 교체할 플러그인 플러그인소스 코드 문제 위치를 지원하려면 source-map-support 플러그인을 사용하세요.

샘플 프로젝트 소스 코드: https://github.com/AirDwing/webpack-server-bundle

이 글은 여기까지입니다. 내용, 모든 분들의 학습에 도움이 되길 바라며, 또한 모두가 Script Home을 응원해 주시길 바랍니다.

위 내용은 Webpack 서버측 코드 패키징의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.