Webpack 서버측 코드 패키징

이 글은 주로 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이 필요합니다. 플러그인이 이를 지원합니다.

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

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

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

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

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