>웹 프론트엔드 >JS 튜토리얼 >Webpack 서버측 코드 패키징 예시에 대한 자세한 설명

Webpack 서버측 코드 패키징 예시에 대한 자세한 설명

小云云
小云云원래의
2018-02-08 11:22:071783검색

환경 변수

이전에는 프로젝트에서 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 백엔드 프로젝트 구성 로딩은 일반적으로 다음과 같이 작성됩니다:


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

module.exports = options;

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

웹팩 패키지 프로젝트에서 직접 수행하는 경우 , 문제가 발생합니다. 예를 들어, 이제 여러 구성이 있습니다. 내가 전달한 환경에서는 모든 구성 파일이 계속 패키징되지만 실행되지는 않습니다. 이 경우 민감한 정보가 유출될 위험이 있습니다.

    올바른 자세는 다음과 같아야 합니다:
  • 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' 等

서버에 로드할 때 다음과 같습니다.

// src/server.js
// 动态加载启用的模块
enabledModules.forEach((mod) => {
 /* eslint-disable global-require,import/no-dynamic-require */
 const routes = require(`./${mod}/route`);
 routes.middleware() |> app.use;
});

그런 다음 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-plugin 플러그인을 사용하세요.

source-map-과 협력하세요. 소스 코드 문제 위치를 지원하는 플러그인 지원

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

관련 권장 사항:

PHP 단순 시스템 쿼리 모듈 코드 패키지 download_PHP 튜토리얼


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

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