Webpack의 자동화된 빌드 정보(자세한 튜토리얼)

이 글은 주로 Webpack 자동화 구축 실습 가이드를 소개하는 내용인데, 편집자가 보기에 꽤 괜찮다고 생각해서 공유하고 참고하겠습니다. 에디터 따라가서 살펴볼까요

현재 블로그는 워드프레스로 구축하다보니 몇몇 코드를 수정해야 하는 경우가 많은데, 타사 소스 코드를 수정하는 건 정말 고통스러워서 React + Node.js를 사용하기로 했습니다/ Python 개발 새로운 블로그 프로젝트는 향후 블로그 유지 관리 및 업데이트를 용이하게 하기 위해 최종적으로 현재 블로그 코드를 대체할 예정이며, 동시에 자체 개발 기술, 아키텍처 설계 및 문제 해결 기능도 향상시킬 수 있습니다. 독자들과 함께 처리하고, 요약하고, 공유하세요. 이번 글에서는 Webpack과 Babel, Eslint, document.js 등을 활용하여 프로젝트 개발 환경과 프로덕션 환경을 구축하는 방법을 소개하고 있으며, 다음 호에서는 프로젝트의 아키텍처 디자인을 소개할 예정입니다. 및 기술 스택 선택.

npm VS Yarn

이 프로젝트에서는 Yarn을 사용하여 프로젝트의 3자 종속성을 관리하지만 걱정하지 마세요. Yarn과 NPM은 충돌하지 않으며 NPM을 대체하기 위한 것도 아닙니다. 마찬가지입니다. 다음 사항을 간단히 이해하면 됩니다.

타사 라이브러리 버전 관리

npm과 Yarn은 모두 package.json을 사용하여 프로젝트 종속성을 추적합니다. npm의 업데이트 범위를 다르게 정의할 수 있기 때문에 버전 번호가 항상 정확하지는 않습니다. 동일한 패키지. .json 파일이 다른 버전의 패키지가 있는 시스템에 설치되어 예외 및 충돌이 발생할 수 있습니다.

npm에 솔루션이 있나요? npm에서는 npm Shrinkwrap을 사용하여 버전 잠금 파일 npm-shrinkwrap.json을 생성할 수 있습니다. npm 설치 시 package.json을 읽기 전에 이 파일을 읽습니다. 그러나 패키지 버전이 업데이트되면 버전 잠금 파일이 생성되지 않습니다. 자동으로 업데이트하려면 npm Shrinkwrap 명령을 다시 수동으로 실행해야 합니다.

그렇다면 Yarn의 장점은 무엇일까요? 설치 라이브러리 패키지가 추가되거나 업데이트될 때마다 Yarn은 Yarn.lock 파일을 생성(또는 업데이트)합니다. 이를 통해 모든 컴퓨터가 동일한 버전 패키지를 설치하고 package.json에 정의된 허용 버전 범위를 지원합니다. npm은 Yarn Yarn.lock이 항상 자동으로 업데이트되는 반면 npm은 수동으로 업데이트되어야 한다는 것입니다.

동시 설치

npm은 일반적으로 종속성을 하나씩 순서대로 설치하는 반면 Yarn은 여러 타사 라이브러리 패키지의 병렬 로드 및 설치를 지원하므로 모두 더 빠르고 효율적입니다.

오프라인 캐싱

Yarn을 사용하여 패키지를 관리하는 경우 타사 라이브러리 패키지가 로컬 디스크에 저장되며, 다음 설치 시 로컬 파일을 다시 다운로드하는 대신 직접 사용하므로 설치 속도도 빨라집니다. npm보다

요컨대 Yarn과 npm은 거의 동일한 방식으로 사용되지만 버전 관리가 더 편리하고 설치 속도가 더 빠르며 더 많은 장점이 있습니다. 그러나 실제로 모든 타사 라이브러리 패키지 로딩 주소는 다음과 같습니다. npm과 통합되었습니다.

Webpack

우리는 Webpack 패키징 도구를 프로젝트의 자동화된 구성 도구로 사용합니다. 우리는 통합 관리를 위해 JavaScript, CSS, 이미지 및 기타 리소스를 JavaScript 모듈(Webpack 로더를 사용하여 변환 처리)로 처리합니다. Webpack 블로거들은 이전에 두 개의 기사를 요약했습니다.

1. Webpack은 SPA 애플리케이션 개발 환경을 구축합니다.

2. Webpack은 CSS 및 이미지와 같은 리소스를 모듈식으로 관리합니다.

이전 기사를 복선하면 이 내용은 다음과 같습니다. 이 기사에서는 Webpack의 작동 원리와 구체적인 구성을 소개하지는 않을 것이며 프로젝트 실제 개발 및 테스트, 패키징 수준에서 Webpack을 더 잘 구성하는 방법과 Webpack을 사용하여 프로젝트 개발 및 패키징 효율성을 향상시키는 방법에 대해 생각할 계획입니다.

Webpack 구성 파일

먼저 루트 디렉터리에 webpack.config.js 구성 파일을 만듭니다.

module.exports = function () {
 let env
 let _DEV_ = true // 开发环境
 let _PROD_ = false // 生产环境

 switch (process.env.NODE_ENV) {
 case 'dev':
 env = 'dev'
 _DEV_ = true
 _PROD_ = false
 break
 case 'production':
 env = 'prod'
 _DEV_ = false
 _PROD_ = true
 break
 default:
 env = 'dev'
 _DEV_ = true
 _PROD_ = false
 }
 // 根据环境参数动态决定引入对应配置文件
 return require(`./webpack/${env}.conf.js`)({
 ROOTPATH: __dirname,
 _DEV_,
 _PROD_
 })
}

process.env.NODE_ENV 환경 매개변수를 기반으로 해당 구성 파일을 동적으로 로드하도록 결정합니다.

1. dev: 로드 webpack/env.conf .js 구성 파일

2. prod: webpack/prod.conf.js 구성 파일을 로드합니다.

프로젝트 루트 디렉토리에 webpack 디렉토리를 생성하고 그 안에 3개의 구성 파일을 생성했습니다. :

1. base.conf.js: 기본 구성 파일, 개발 및 프로덕션 환경 모두에 필요한 구성

2. dev.conf.js: 개발 환경 구성 파일

3. prod.conf.js: 프로덕션 환경 패키징 구성 파일 ;

개발 환경 구성

개발 환경 구성 파일은 개발을 위한 일부 빌드 구성을 정의한 다음 기본 구성 파일을 소개하고, webpack-merge 타사 라이브러리를 사용하고, 개발 환경 구성을 병합합니다. 기본 구성 개체에 넣은 다음 개발 환경 패키징 및 빌드 구성 개체를 Webpack 패키징 및 빌드의 매개 변수로 반환합니다.

const webpackMerge = require('webpack-merge')
const PUBLICPATH = '/assets/'
const PORT = '9090'
let options = { /* ... */ }
module.exports = function (args) {
 options.ROOTPATH = args.ROOTPATH
 options.env = args.env
 return webpackMerge(require('./base.conf')(options), {
 devtool: 'source-map',
 devServer: {
 contentBase: path.join(args.ROOTPATH, './src'),
 historyApiFallback: true,
 inline: true,
 hot: true,
 port: PORT,
 proxy: {
 '*': `http://localhost:${PORT}/${PUBLICPATH}/`
 }
 },
 plugins: []
 })
}

Production Environment Configuration

프로덕션 환경 구성 파일은 프로덕션 환경에서 사용되는 빌드 구성을 정의합니다. 그런 다음 webpack을 사용하여 기본 구성 파일을 소개합니다. 타사 라이브러리를 병합하고 프로덕션 환경 구성을 기본 구성에 병합한 다음 Webpack 패키징 및 빌드를 위한 매개변수로 구성 객체를 반환합니다.

let options = { /* ... */}
module.exports = function (args) {
 options.ROOTPATH = args.ROOTPATH
 options.env = args.env
 return webpackMerge(require('./base.conf')(options), {
 plugins: [
 new webpack.DefinePlugin({
 'process.env': 'production'
 }),
 // 生成独立css文件
 new ExtractTextPlugin({
 filename: 'css/[name].css'
 }),
 new webpack.optimize.UglifyJsPlugin({
 compress: {
 warnings: false
 }
 })
 ]
 })
}

지침

그런 다음 다양한 환경에 맞게 실행 가능한 지침을 구성하고 npm 스크립트를 사용하여 package.json 파일에서 실행 지침을 구성합니다.

{
 "scripts": {
 "start": "cross-env NODE_ENV=dev webpack-dev-server",
 "build": "cross-env NODE_ENV=production webpack"
 }
}

start：开发环境运行指令，使用cross-env三方库设置process.env.NODE_ENV为dev，并在本地开启webpack开放服务器，方便开放；

build：生产环境运行指令，使用cross-env三方库设置process.env.NODE_ENV为production，将打包输出代码和资源文件；

最后分别执行yarn start和yarn build指令即可分别执行开发和生产构建打包了。

Babel

可自定义配置型的通用编译器，需要明确指定期望babel做什么，通过安装插件（plugins）或预设（presets，也就是一组插件）来指示 Babel 去做什么事情。

配置文件

首先需要创建一个配置文件，即在项目的根路径下创建 .babelrc 文件。然后输入以下内容作为开始：

{
 "presets": [],
 "plugins": []
}

之后就可以拓展这个配置文件以指定此项目中 Babel 的功能。

babel-preset-es2015

我们期望在项目中能使用更新潮的ES6版本语法，但由于目前还有许多JavaScript环境不能很好兼容ES6，所以需要Babel将ES6代码编译成ES5语法代码，保证应用的使用范围。

执行如下命令，安装 “es2015” Babel 预设：

yarn add --dev babel-preset-es2015

修改.babelrc配置文件：

{
 "presets": [
 "es2015"
 ],
 "plugins": []
}

babel-preset-stage-num

另外，JavaScript还有一些提案，正在推进，不久的将来也可能成为标准的一部分，所以目前将这些草案提出，内容更新直至最终成为标准，添加进标准库的过程划分为 5（0－4）个阶段。 根据提案的状态和内容，将其在各个阶段更新（阶段0至阶段3），最终在阶段 4表明该提案被标准正式采纳，当然不被采纳的提案不会进入阶段4。

以下是4个不同阶段的打包预设：

1. babel-preset-stage-0

2. babel-preset-stage-1

3. babel-preset-stage-2

4. babel-preset-stage-3

注： stage-4 预设不存在，它其实就是上文介绍的 es2015 预设。

以上每种预设都包含紧随的后期阶段预设，同时还可能包含其他额外特性。例如，babel-preset-stage-0 包含 babel-preset-stage-1， babel-preset-stage-2，babel-preset-stage-3，而 babel-preset-stage-1则包含 babel-preset-stage-2，babel-preset-stage-3依次后推。

点此查看关于各阶段预设的详细特性内容文档

我们次选择支持特性最全面的预设：

yarn add --dev babel-preset-stage-0

在.babelrc 配置文件内添加：

{
 "presets": [
 "es2015",
 "stage-0"
 ],
 "plugins": []
}

babel-preset-react

我们的项目期望使用React开发，所以需要拓展支持React/JSX语法，安装预设：

yarn add --dev babel-preset-react

.babelrc 配置文件内添加：

{
 "presets": [
 "es2015",
 "stage-0",
 "react"
 ],
 "plugins": []
}

babel-polyfill

至此，使用Babel，我们的·项目几乎可以支持所有的ES6及ES7语法，但是对于新增的JavaScript API是无能为力的，如Symbol这种新API，并不是通过语法转换能实现的，所以我们需要另外的方式解决。

业内提出了Polyfill(填充)，以添加额外代码的方式使得当前运行环境支持不存在的原生Api ，拓展了尚处在推进阶段的API的使用范围。

yarn add babel-polyfill

此处不需要添加--dev参数。

然后在文件入口引入即可：

import "babel-polyfill";

babel-runtime

前面提到的Babel通过转换语法以支持我们以ES6等更新的语法方式开发代码，这时Babel会在每一个处理的文件头部注入辅助代码，会产生很多冗余，重复性的内容，导致代码量暴增，所以我们需要将这些辅助代码抽取至一个统一环境，Babel提供的就是运行时（runtime）环境。

要实现Babel运行时环境，需要安装 babel-plugin-transform-runtime 和 babel-runtime：

yarn add --dev babel-plugin-transform-runtime babel-runtime

然后更新 .babelrc：

{
 "plugins": [
 "transform-runtime",
 ]
}

按需加载（babel-plugin-import）

很多时候，我们开发业务并不需要自制UI，会选择一些开源组件库以快速开发实现产品，如antd，weui，material-ui等，我们可以选择直接提前加载三方库所有模块，但是很多时候我们希望能实现按需加载，减少初始代码包的体积，这时，我们可以在babel配置文件中声明按需加载该第三方库，当然首先得安装插件babel-plugin-import：

yarn add --dev babel-plugin-import

然后在配置文件.babelrc中添加配置：

{
 "plugins": [
 "import",
 {
 "style": "../styles", // 加载样式解析方式，（值为true时，可能是less／Sass），此处值设为相对libraryName具体模块请求路径值
 "libraryDirectory": "", // 加载包的目录，(默认是lib，即node_modules/lib/)
 "libraryName": "material-ui" // 加载三方组件库名，当然另外需要安装该三方库
 }
 ]
}

此时，webapck loader处理css时不能添加exclude: /node_modules/。

其他插件

我们还可以根据项目实际需求和爱好自定义安装插件，更多信息查看官方插件文档。

在这里推荐一款babel-pliugin-transform-s2015-classes插件拓展以实现JavaScript内置class对象的extends继承特性，参考文档ES2015 classes transform。

yarn add --dev babel-plugin-transform-es2015-classes

在.babelrc文件内添加plugins内容：

{
 "plugins": [
 "transform-runtime",
 "transform-es2015-classes",
 [
 "import",
 {
 "style": "css",
 "libraryDirectory": "",
 "libraryName": "material-ui"
 }
 ]
 ]
}

语法检测（Eslint）

为了保证代码质量，统一代码风格是很重要的，而只靠团队口头约定明显是不能尽如人意，所以通常需要在自动化构建层面进行代码语法检测，有很多语法检测工具如jslint，eslint，目前使用率最高的要数eslint了，所以我们的项目也引入eslint，首先安装依赖：

yarn add --dev eslint

更多细节参考配置文档，下文简要介绍主要。

配置文件

然后在项目根目录下建立eslint配置文件.eslintrc，内容是一个对象：

{}

解析器（parser）

另外，ESLint 默认使用Espree作为其解析器，你可以在配置文件中指定一个不同的解析器，如babel-eslint，esprima等，我们项目使用babel-eslint：

yarn add --dev babel-eslint

在配置文件内添加parser属性：

{
 "parser": "babel-eslint"
}

eslint-plugin-babel

eslint还支持可选安装插件，拓展eslint，如eslint-plugin-babel，该插件与babel-eslint协作，使得eslint可以更好的与babel同时工作，更多请查看参考文档。

yarn add --dev eslint-plugin-babel

在配置文件添加声明：

{
 "plugins": [
 "babel"
 ],
}

aslant-plugin-react

eslint默认是检测JavaScript语言语法的，而对于React／JSX这类包含其自定义语法和语法糖的框架而言，需要另外拓展安装插件才能和eslint结合使用，所以使用eslint检测React特定语法需要安装eslint-plugin-react插件：

yarn add --dev eslint-plugin-react

添加配置文件：

{
 "plugins": [
 "babel",
 "react"
 ]
}

拓展（extends）

除了自定义语法检查规则外，我们可以使用Eslint提供的集成拓展包，使用共享的语法检测配置对象，如eslint-config-standard和eslint-config-standard-react：

yarn add --dev eslint-config-standard eslint-config-standard-react eslint-plugin-standard eslint-plugin-promise eslint-plugin-import eslint-plugin-node eslint-plugin-react

注：这里包含了上一小节提到的eslint-plugin-react是为了支持eslint-config-standard-react配置包。

然后在.eslintrc配置文件中添加拓展：

{
 "extends": [
 "standard",
 "standard-react"
 ]
}

若不想使用这类集成语法检测规则，可以移除配置文件中内容并移除依赖：

yarn remove eslint-config-standard eslint-config-standard-react eslint-plugin-standard eslint-plugin-promise eslint-plugin-import eslint-plugin-node eslint-plugin-react

语法规则（rules）

要添加语法规则，只需要声明在rules属性对象中，如：

{
 "rules": {
 "strict": 0,
 "semi": 2, // 强制语句末尾添加符号，否则报错
 "quotes": [
 1,
 "single"
 ],
 }
}

规则结构

当声明语法检测规则时，需要设置规则 ID为以下值之一：

1. "off" 或 0 – 关闭规则

2. "warn" 或 1 – 开启规则，使用警告级别的错误：warn (不会导致程序退出)

3. "error" 或 2 – 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)

{
 "rules": {
 eqeqeq: 0, // or "off"
 curly: 2 // or "error"
 }
}

某些规则还可能有额外的配置选项，可以使用数组指定，如：

{
 "rules": {
 "eqeqeq": "off",
 "curly": "error",
 "quotes": ["warn", "single"] // 开启使用单引号，若使用双引号将发出警告
 }
}

指令

要执行语法检测，只需要执行./node_modules/.bin/eslint src（项目本地安装eslint，而非全局安装，则需要指定执令脚本路径），将会遍历检查src目录下的所有源码文件语法并输出结果，当然我们最终需要将指令根据npm scripts规范插入package.json文件：

{
 "scripts": {
 "lint": "eslint --cache --fix src"
 }
}

使用npm scripts执行指令时，无论项目本地安装还是全局安装，都可以省略指令脚本路径，因为npm将自动匹配可用路径。

文档

一个优秀的项目当然少不了文档，文档可以帮助其他开发者快速了解整个项目内容及进度，也有助于bug修复时查找内容，追踪溯源，所以文档是有必要的，于是通过调研发现了JSdoc和documentation.js帮助自动化产出API文档。

documentation

和JSdoc一样，documentation也是根据代码注释自动构建出项目文档，前提是我们的代码注释必须按照其规范指南，详情参考JSdoc文档。

我们首先安装documentation.js:

yarn add --dev documentation

指令

然后可以执行指令：

./node_modules/.bin/documentation build src/app.js -f md > API.md

会发现在根目录输出了API.md文件。

我们在package.json文件中配置npm scripts执行脚本：

"scripts": {
 "doc": "./node_modules/.bin/documentation build src/app.js -f md > API.md"
}

项目本地安装documentation时，直接在命令行终端执行指令时需要指定./node_modules/.bin/documentation路径，若全局安装则只可直接使用documentation指令。而执行package.json中的脚步，可以直接简写，npm将为我们自动匹配。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

在JavaScript中如何实现弹性效果

使用axios如何实现ajax请求（详细教程）

利用vue.js如何实现$refs和$emit 父子组件交互

在Vue中extend 、component有哪些区别？

위 내용은 Webpack의 자동화된 빌드 정보(자세한 튜토리얼)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!