工程化

Swift 的类型推导、泛型约束求解、WMO / CMO 是编译性能的核心影响因素。理解它们能让源码层面的小改动带来显著的编译加速。本文聚焦"代码写法 + 编译开关"两方面的优化。 Swift 编译流程速览 相比 C/OC，Swift 编译多出大量工作： flowchart LR A[Parse] --> B[Sema类型检查] B --> C[SILGen生成 SIL] C --> D[SIL Optimization] D --> E[IRGenLLVM IR] E --> F[LLVM Optimization] F --> G[CodeGen] 其中 Sema（语义分析） 阶段负责类型推导，是 Swift 特有的性能热点。-debug-time-compilation 看到的 “Type checking” 时间基本都集中在这里。 类型推导与 “Too Complex” 错误 约束求解 Swift 的类型系统比大多数语言复杂： 函数重载 + 运算符重载 隐式字面量类型（Int、Double、Float80…） 泛型 + 协议 + 关联类型 闭包参数类型推导 SwiftUI 风格的 ViewBuilder / Result Builders 遇到表达式 let x = a + b * c - d，编译器需要给 + * - 每个运算符枚举所有可能的重载，在多个候选里做约束传播。当候选组合爆炸时，Sema 会放弃并抛出： ...

在 iOS 生态中，CocoaPods 依然是大多数中大型工程的依赖管理工具。当 Pod 数量达到几百个子组件上千个时，pod install 的耗时会变成研发流程里的硬性卡点。抖音在其 seer-optimize 项目中系统化地优化了 CocoaPods 的整个生命周期，全量 Pod Install 耗时减少 50%、增量减少 65%。本文系统介绍这些优化背后的原理。 关于 CocoaPods 整体架构的深度介绍可以参考 CocoaPods源码导读-架构总览。 Pod Install 耗时构成 Installer#install! 的六个阶段： flowchart LR A[prepare] --> B[resolve_dependencies] B --> C[download_dependencies] C --> D[validate_targets] D --> E[generate_pods_project] E --> F[integrate_user_project] 抖音公开的典型耗时分布： 阶段 典型耗时 说明 prepare < 0.01s 初始化 resolve_dependencies 数秒到数分钟 依赖决议，瓶颈 download_dependencies 数秒到数分钟 依赖下载，IO 密集 validate_targets 0.1s 校验 generate_pods_project 数秒到数十秒 生成 xcodeproj integrate_user_project 0.01s 集成主工程 resolve_dependencies 优化 Source 仓库更新 默认 CocoaPods 在 pod install --repo-update 时会更新所有 source 仓库。抖音改造为： ...

当 iOS 工程的规模突破 CocoaPods / Xcode 原生构建体系的舒适区，Bazel 就成为下一代构建系统的首选。字节跳动的头条、抖音、Airbnb、Uber、Lyft、Pinterest、Square、Bilibili 等都已把 iOS 工程迁到 Bazel。本文介绍 Bazel 的核心原理、在 iOS 上的生态（rules_apple / rules_swift / rules_xcodeproj）以及大厂落地实践。 为什么是 Bazel CocoaPods + Xcode 在超大工程上的固有瓶颈： 粗粒度依赖：以 Pod / Target 为单位，增量编译颗粒粗 隐式依赖：Build Phases 隐含顺序，难以沙箱化 难以远程缓存：编译环境非 hermetic，hash 易变 难以远程执行：Xcode Build System 绑定本地 macOS Bazel 针对这些问题从设计之初就提供了： 能力 Bazel Xcode/CocoaPods 依赖粒度 文件级 Target 级 依赖显式化 必须声明 部分隐式 Sandbox 默认开启 无 远程缓存 原生 需第三方（ccache/Rugby） 远程执行 原生 不支持 跨语言 一流（Swift/OC/C++/Go/Rust/JS） 主要 Apple 平台 多平台 天生 iOS/macOS 为主 Bazel 核心概念 Workspace 与 Package WORKSPACE # 仓库根，声明外部依赖 foo/ ├── BUILD.bazel # package，本目录的构建声明 ├── main.swift └── util/ └── BUILD.bazel # 子 package Workspace：整个 Bazel 仓库，一个 WORKSPACE 文件一个仓 Package：任何包含 BUILD.bazel 的目录 Target：BUILD 文件里的一个 rule 调用，比如 swift_library(name = "foo") Label：Target 的全局 ID，形如 //foo/util:util Rule Rule 是构建函数，输入 sources + deps，输出 artifacts： ...

状态管理是一个前端界老生常谈的话题了，所有前端框架的发展历程中都离不开状态管理的迭代与更替，对于react来说呢，整个状态管理的发展也随着react架构的变更和新特性的加入而不停的做调整，作为一个一起伴随react成长了快5年的开发者，经历过reflux、redux、mobx，以及其他redux衍生方案dva、mirror、rematch等等后，我觉得它们都不是我想要的状态管理的终极形态，所以为了打造一个和react结合得最优雅、使用起来最简单、运行起来最高效的状态管理方案，踏上了追梦旅途。 为何需要状态管理 为何需要在前端引用里引入状态管理，基本上大家都达成了共识，在此我总结为3点： 随着应用的规模越来越大，功能越来越复杂，组件的抽象粒度会越来越细，在视图中组合起来后层级也会越来越深，能够方便的跨组件共享状态成为迫切的需求。 状态也需要按模块切分，状态的变更逻辑背后其实就是我们的业务逻辑，将其抽离出来能够彻底解耦ui和业务，有利于逻辑复用，以及持续的维护和迭代。 状态如果能够被集中的管理起来，并合理的派发有利于组件按需更新，缩小渲染范围，从而提高渲染性能 已有状态管理方案现状 redux 遵循react不可变思路的状态管理方案，无论从git的star排名还是社区的繁荣度，首推的一定是redux这个react界状态管理一哥，约束使用唯一路径reducer纯函数去修改store的数据，从而达到整个应用的状态流转清晰、可追溯。 image.png mbox 遵循响应式的后期之秀mbox，提出了computed、reaction的概念，其官方的口号就是任何可以从应用程序状态派生的内容都应该派生出来，通过将原始的普通json对象转变为可观察对象，我们可以直接修改状态，mbox会自动驱动ui渲染更新，因其响应式的理念和vue很相近，在react里搭配mobx-react使用后，很多人戏称mobx是一个将react变成了类vue开发体验的状态管理方案。 image.png 当然因为mbox操作数据很方便，不满足大型应用里对状态流转路径清晰可追溯的诉求，为了约束用户的更新行为，配套出了一个mobx-state-tree，总而言之，mobx成为了响应式的代表。 其他 剩下的状态管理方案，主要有3类。 一类是不满足redux代码冗余啰嗦，接口不够友好等缺点，进而在redux之上做2次封装，典型的代表国外的有如rematch，国内有如dva、mirror等，我将它们称为redux衍生的家族作品，或者是解读了redux源码，整合自己的思路重新设计一个库，如final-state、retalk、hydux等，我将它们称为类redux作品。 一类是走响应式道路的方案，和mobx一样，劫持普通状态对象转变为可观察对象，如dob，我将它们称为类mobx作品。 剩下的就是利用react context api或者最新的hook特性，主打轻量，上手简单，概念少的方案，如unstated-next，reactn、smox、react-model等。 我心中的理想方案 上述相关的各种方案，都各自在一定程度上能满足我们的需求，但是对于追求完美的水瓶座程序猿，我觉得它们终究都不是我理想的方案，它们或小而美、或大而全，但还是不够强，不够友好，所以决定开始自研状态管理方案。 我知道小和 美、全、强本身是相冲突的，我能接受一定量的大，gzip后10kb到20kb都是我接受的范围，在此基础上，去逐步地实现美、全、强，以便达到以下目的，从而体现出和现有状态管理框架的差异性、优越性。 让新手使用的时候，无需了解新的特性api，无感知状态管理的存在，使其遁于无形之中，仅按照react的思路组织代码，就能享受到状态管理带来的福利。 让老手可以结合对状态管理的已有认知来使用新提供的特性api，还原各种社区公认的最佳实践，同时还能向上继续探索和提炼，挖掘状态管理带来的更多收益。 在react有了hook特性之后，让class组件和function组件都能够享有一致的思路、一致的api接入状态管理，不产生割裂感。 在保持以上3点的基础上，让用户能够使用更精简且更符合思维直觉的组织方式书写代码，同时还能够获得巨大的性能提升收益。 为了达成以上目标，立项concent，将其定义为一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，期待能把他打磨成为一个真真实实让用户用起来感觉到美丽、全面、强大的框架。 说人话就是：理解起来够简单、代码写起来够优雅、工程架构起来够健壮、性能用起来够卓越…… ^_^ concent.png 可预测 react是一个基于pull based来做变化侦测的ui框架，对于用户来说，需要显式的调用setState来让react感知到状态变化，所以concent遵循react经典的不可变原则来体现可预测，不使用劫持对象将转变为可观察对象的方式来感知状态变化（要不然又成为了一个类mobx……）, 也不使用时全局pub&sub的模式来驱动相关视图更新，同时还要配置各种reselect、redux-saga等中间件来解决计算缓存、异步action等等问题（如果这样，岂不是又迈向了一个redux全家桶轮子的不归路….. ） 吐槽一下：redux粗放的订阅粒度在组件越来越多，状态越来越复杂的时候，经常因为组件订阅了不需要的数据而造成冗余更新，而且各种手写mapXXXToYYY很烦啊有木有啊有木有，伤不起啊伤不起…… 零入侵 上面提到了期望新手仅按照react的思路组织代码，就能够享受到状态管理带来的福利，所以必然只能在setState之上做文章，其实我们可以把setState当做一个下达渲染指令重要入口（除此之外，还有forceUpdate）。 setState，下达更新指令 仔细看看上图，有没有发现有什么描述不太准确的地方，我们看看官方的setState函数签名描述: 代码语言：txt AI代码解释 setState<K extends keyof S>( state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null), callback?: () => void ): void; 通过签名描述，我们可以看出传递给setState的是一个部分状态(片段状态)，实际上我们在调用setState也是经常这么做的，修改了谁就传递对应的stateKey和值。 ...

传统的多页面应用构建方式： 纯服务端渲染，前后端不分离，使用jsp,jade,’ejs’,’tempalte’等技术在后台先拼接成对应的HTML结构，然后转换成字符串，在每个对应的路由返回对应的数据（文件）即可 Jade模版服务端渲染，代码实现： const express= require('express') const app =express() const jade = require('jade') const result = *** const url path = *** const html = jade.renderFile(url, { data: result, urlPath })//传入数据给模板引擎 app.get('/',(req,res)=>{ res.send(html)//直接吐渲染好的`html`文件拼接成字符串返回给客户端 }) //RestFul接口 app.listen(3000,err=>{ //do something }) 使用jQuery等传统库绘制的前端页面 传统前后端不分离，服务端渲染的优缺点： 优点： SEO友好，因为返回给前端的是渲染好的HTML结构，里面的内容都可以被爬虫抓取到。 对于一些应用性能等要求不高的项目，比如某个公司的静态网页，内容很少的情况下，直接一把梭就好，不用再搭建工程化的环境等 对于后端程序员（全干工程师）来说，不用去特意学习前端框架，公司也不用特意去招聘前端 兼容性好，传统服务端渲染多页面应用吐出来的都是字符串，HTML结构 缺点： 如果项目很大，不利于维护，据我所知，目前很多云计算公司，还有不少都是使用非单页面应用，例如一个几十万行的项目是用jQuery写的，如果注释和文档不是非常齐全，那么真的会无从下手 性能和用户体验，不能跟单页面应用相比 后期迭代，升级空间不大，目前大部分写得比较好的库，都建立vue,react等框架基础上，他们都有一套自己的运行机制，有自己的生命周期，并且不像传统的应用，还加上了一层虚拟DOM以及diff算法 现在类似Ant-Design-pro这样的开箱即用的库已经很多，单页面应用的学习和开发成本已经很低很低，如果还在使用传统的技术去开发新的应用，对于开发人员多内心来说也是一种折磨。 这里并不是说多页面应用不好，只能说各有各自的好，单页面应用如果通过大量的极致优化手段，是可以从不少方面跟原生一拼。 目前的单页面应用： 只有一张Web页面的应用，是一种从Web服务器加载的富客户端，单页面跳转仅刷新局部资源 ，公共资源(js、css等)仅需加载一次，常用于PC端官网、购物等网站 其实只有一个空的DIV标签，其他都是js动态生态的内容 单页面应用实现步骤： 代码实现： 首先是一个静态模板文件 index.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>Document</title> </head> <body> <div id="root"></div> </body> <script> </script> </html> 在vue react框架的入口文件中指定对应的渲染元素： import React from 'react; import ReactDOM from 'react-dom'; ReactDOM.render( <App/>, document.querySelector("#root") ) 引入react-router或者 react-router-dom，dva等路由跳转的库 配置路由跳转 <HashRouter>//这里使用HashRouter <ErrorBoundary>//React错误边界 <Switch> <Route path="/login" component={Login} /> <Route path="/home" component={Home} /> <Route path="/" component={NotFound} />//404路由或者重定向都可以 </Switch> </ErrorBoundary> </HashRouter> 单页面应用所谓路由跳转，其实最终结果就是： 浏览器的url地址发生变化，但是其实并没有发送请求，也没有刷新整个页面 根据我们配置的路由信息，每次点击切换路由，会切换到不同的组件显示，类似于选项卡功能的实现,但是同时url地址栏会变化 分为HashRouter和BrowserRouter两种模式 自己实现一个粗略的路由跳转： 自己实现传统的Hash模式跳转： hash 就是指 url 后的 # 号以及后面的字符。例如www.baidu.com/#segmentfault,那么#segmentfault就是hash值 ...

背景 不知道你有没有遇到过以下场景: 页面逻辑越来越多,代码越来越庞大,写到后面难以 hold 住所有逻辑,很容易牵一发而动全身. 你负责的页面好好的突然出现问题,查到最后是别人代码影响. 同样的逻辑在多个地方重复书写,每次一改要改一批文件 随着前端项目复杂度的急剧增加, 上面列出的几种场景就是传统开发中会出现的问题. 也是前端组件化出现的原因. 项目复杂度增加, 一个页面一个文件需要处理的内容过多. 重复性劳动多, 效率低 质量差, 不可控 组件化初探 正是由于出现了这样的问题, 为了在越来越复杂的前端项目中提高开发效率和保证开发质量, 各路大神们开始通过各种方式来尝试解决问题. 曾经非常火的 jQuery 就基于自己建立了 jQuery 插件机制. 你可以将一些常用逻辑进行封装变成 jQuery 插件, 还可以将插件开源进行共享. 比如纯手写会吐血的日期时间选择器,轮播, 多级菜单等等. 你可以在这里浏览更多jQuery插件. jQuery 插件的用法通常是: $(".select").pluginName(config) 除了 jQuery 插件模式, 还有一种常见模式是对象模式. 这种模式现在仍然有很多优秀的库在被我们直接或者间接使用. 比如: swiper 对象模式的写法: <!-- Slider main container --> <div class="swiper-container"> <!-- Additional required wrapper --> <div class="swiper-wrapper"> <!-- Slides --> <div class="swiper-slide">Slide 1</div> <div class="swiper-slide">Slide 2</div> <div class="swiper-slide">Slide 3</div> ... </div> </div> <script src="path/to/swiper.min.js"></script> <script> var mySwiper = new Swiper ('.swiper-container', { direction: 'vertical', loop: true, }) </script> 对象模式通过配置创建对象, 通常创建对象的参数中有一项是元素/元素选择器, 通过js代码将逻辑与这个元素紧密绑定. ...

大纲 我们会从以下三个方向来讲解埋点与监控的知识： 什么是埋点？什么是监控？ JS 中实现监控的核心方案 写一个“相对”完整的监控实例 一、什么是埋点？什么是监控？ 在日常沟通中，我们经常会把【埋点】和【监控】放到一起说，但是它们在本质上是有一定的区别的： 1. 埋点 埋点主要用于收集用户行为数据。在日常开发中，我们会通过 在前端代码中插入代码或脚本的方式 来实现埋点功能。 埋点的主要作用就是：捕获特定用户行为（如点击、浏览、提交表单、页面跳转等）以及关键业务数据（如下单金额、商品类别等） 在日常开发中，埋点的实现方案大致可以分为以下三大类： 手动埋点：在代码中手动加入记录代码来捕获特定事件。 自动埋点：利用 DOM 事件代理等技术来捕获页面上所有事件，从而减少手动配置。 可视化埋点：通过工具界面标记需要采集的元素和事件，可以不用手写代码。 2. 监控 而监控则主要关注 系统的性能和稳定性。在日常开发中，我们会通过 采集页面加载时间、资源请求、错误日志等数据 的方式来实现前端监控。 监控的主要作用就是：及时发现并定位页面性能瓶颈或代码异常，目的是为了保障系统不出 bug 在日常开发中，监控一般需要完成以下三大部分： 性能监控：如：首屏加载时间、页面交互耗时、资源加载耗时等。 错误监控：捕获 JavaScript 错误、网络请求失败、资源加载异常等。 用户体验监控：收集白屏、卡顿等影响用户体验的问题等。 区别总结 维度 前端埋点 前端监控 目标 捕获用户行为数据 监控系统性能、错误、稳定性 数据类型 用户点击、表单提交、页面跳转等 页面加载时间、错误日志、卡顿情况等 实现方式 手动埋点、自动埋点、可视化埋点 错误捕获、性能指标采集 核心关注点 用户行为、业务数据 系统Bug、性能优化 二、JS 中实现监控的核心方案 根据上面所说，我们知道埋点和监控的目的存在不同，但是它们的思路确是有很多一致性的，其核心都是：获取关键的数据，发送（上报）给服务端，依据数据来解决其不同的目的。 所以，无论是埋点也好，还是监控也罢，我们都需要 获取关键位置数据。 1. 跟踪用户事件（点击、滚动等） 定义通用跟踪函数（后续事件会通过该函数完成上报）：trackEvent 函数接收事件类型和事件详情，并上报到服务端。 // 用于记录或发送跟踪数据到服务器的函数 function trackEvent(eventType, details) { console.log(`Event: ${eventType}`, details); // 在控制台打印事件类型和详情 // 上报到服务端。 fetch('/测试接口地址', { method: 'POST', body: JSON.stringify({ eventType, details }) }); } 捕获按钮点击事件：获取 id 为 myButton 的按钮，并在其 click 事件上添加监听器。在按钮被点击时调用 trackEvent 函数，记录点击事件的类型（button_click）、按钮 ID 和时间戳。 ...

什么是 Bundle Splitting？ Bundle Splitting（代码分割）是一种将前端资源拆分成更小、独立的模块的技术。传统上，前端资源（如 JavaScript、CSS 和图片等）被打包成单个文件，通常称为“bundle”。这种方式存在一个问题，即无论用户需要哪些功能，都必须下载整个 bundle。而 Bundle Splitting 技术通过将代码拆分为更小的模块，按需加载，可以有效解决这个问题。 Bundle Splitting 的优点 减少初始加载时间 通过将代码拆分为多个小块，可以减少初始加载时间。当用户首次访问网页时，只需下载当前页面所需的资源，而无需等待整个应用程序的加载完成。这可以极大地提高页面的响应速度，并减少用户的等待时间。 提升用户体验 通过将代码分割成模块，可以使应用程序更具响应性。当用户与应用进行交互时，只需加载所需的代码块，而不是整个应用。这将减少不必要的资源消耗，并使用户感觉应用更加流畅和快速。 优化缓存策略 拆分代码还能优化缓存策略。当应用程序发生更改时，只需重新加载发生变化的模块，而不必重新下载整个应用。这减少了不必要的网络请求，提高了应用的更新效率，并减轻了服务器的负载。 并行加载资源 通过将代码拆分为多个模块，可以实现并行加载资源。浏览器能够同时下载多个文件，从而减少整体加载时间。这对于大型应用程序和复杂的前端框架特别有益，能够更好地利用浏览器的并行下载能力，提高资源的加载效率。 代码复用和维护 通过将代码分割成模块，可以更好地实现代码的复用和维护。不同的模块可以根据需求进行加载和升级，使得代码结构更加清晰、模块化。这也有助于团队合作，不同开发者可以并行工作在不同的模块上，提高开发效率和代码质量。 Bundle Splitting 的缺点 增加了网络请求 拆分代码会增加应用程序的网络请求次数。每个模块都需要进行一次独立的网络请求，这可能会导致一些额外的延迟和性能损失。在网络条件较差的情况下，这可能会对用户体验产生一定影响。 增加了开发复杂性 使用 Bundle Splitting 技术需要对应用程序的依赖关系进行深入分析和管理。开发人员需要仔细考虑代码的拆分点，以及如何在运行时动态加载模块。这增加了开发复杂性，并要求开发人员具备较高的技术水平和经验。 潜在的代码冗余 当模块之间存在共享的代码片段时，可能会出现潜在的代码冗余问题。如果不合理地进行代码拆分，可能会导致多个模块中存在相同的代码，增加了资源的下载和维护成本。因此，在进行代码拆分时，需要仔细考虑代码复用和代码冗余的问题。 需要额外的工具和配置 Bundle Splitting 需要使用额外的工具和配置来实现代码的拆分和动态加载。这可能需要对构建工具进行配置，如 Webpack、Rollup 等，以及对模块加载器进行调整。这增加了一些学习成本和开发成本，尤其是对于新手来说。 Bundle Splitting 的适用场景 Bundle Splitting 技术适用于大型的 Web 应用程序，特别是那些具有复杂功能和大量依赖的应用。以下是一些适合使用 Bundle Splitting 的场景： 大型单页应用：对于由多个模块组成的单页应用，使用 Bundle Splitting 可以提高初始加载速度，提升用户体验。 按需加载：对于需要动态加载不同功能模块的应用，Bundle Splitting 可以根据用户的需求按需加载模块，减少不必要的资源消耗。 公共库和框架：对于使用公共库或框架的应用，可以将这些库和框架拆分成单独的模块，以便在多个页面中共享和复用。 国际化支持：对于需要支持多种语言的应用，可以将不同语言的资源文件拆分成独立的模块，根据用户的语言偏好进行加载。 代码分支管理：对于大型团队开发的项目，使用 Bundle Splitting 可以更好地实现代码的分支管理和并行开发，提高开发效率。 Bundle Splitting 在知名项目中的应用 示例 1：React.lazy 和 Suspense React.js 是一个广泛使用的 JavaScript 库，用于构建用户界面。React 提供了 React.lazy 和 Suspense API 来实现 Bundle Splitting。 ...

传统应用发布模式 开发人员：在开发环境完成代码编写，单元测试，测试通过后提交到代码仓库 运维人员：把项目部署到测试环境，供QA团队测试，测试通过后，部署生成环境 测试人员：进行测试，测试完成后通知运维部署生产环境 缺点 项目在早期就存在错误，但到最后集成的时候才发现 需要手动操作，易错率高 开发与运维需要及时沟通 有了以上缺点，那么就有了CI/CD CI/CD 持续集成(CI): 合并开发人员正在编写的所有代码 一天内进行多次合并和提交代码 从存储库或生产环境中进行构建和自动化测试，确保没有集成问题并及早发现任何问题 持续交付(CD): 可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中 持续部署，并自动将更改推送到生产中 GitLab内置CI/CD 运行流水线任务 Job 在文件中可以定义一个或多个作业，每个作业具有唯一的名称，每个作业是独立执行的，每个作业至少包含一个script stages： 用于定义作业可以使用的阶段，并且是全局定义，同一个阶段的作业并行运行，不同阶段按顺序运行 only： 用分支策略来限制jobs构建 script: 项目中package中的脚本 environment： 定义此作业完成部署的环境名称 下面是每个jobs的详细变量名 Keyword Required Description script yes Runner执行的命令或脚本 image no 所使用的docker镜像，查阅使用docker镜像 services no 所使用的docker服务，查阅使用docker镜像 stage no 定义job stage（默认：test） type no stage的别名（已弃用） variables no 定义job级别的变量 only no 定义一列git分支，并为其创建job except no 定义一列git分支，不创建job tags no 定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags） allow_failure no 允许job失败。失败的job不影响commit状态 when no 定义何时开始job。可以是on_success，on_failure，always或者manual dependencies no 定义job依赖关系，这样他们就可以互相传递artifacts cache no 定义应在后续运行之间缓存的文件列表 before_script no 重写一组在作业前执行的命令 after_script no 重写一组在作业后执行的命令 environment no 定义此作业完成部署的环境名称 coverage no 定义给定作业的代码覆盖率设置 配置.gitlab-ci.yml stages: - deploy_dev - deploy_test - deploy_production deploy_dev: stage: deploy_dev environment: name: dev only: - dev script: - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH} - npm run build:dev - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=/opt/devroot/" deploy_test: stage: deploy_test environment: name: test only: - master script: - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH} - npm run build:stage - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=${WEB_ROOT_PATH}" deploy_production: stage: deploy_production only: - production when: manual script: - npm install - npm run build:prod - ansible-playbook ansible-deploy.yml --extra-vars "hosts=dvs-front-prod projectDir=${PROJECT_PATH} projectName=xianglin-cloud-ui/${PROJECT_NAME} webRootPath=/opt/" 上面这个.yml文件,我们首先定义了三个阶段，deploy_dev部署到dev环境，并且拉去的是dev分支代码; deploy_test部署到test环境，拉去的是master分支代码，deploy_production拉取production分支代码，执行完后需要手动操作 ...

现如今，前端开发的同学已经离不开 npm 这个包管理工具，其优秀的包版本管理机制承载了整个繁荣发展的NodeJS社区，理解其内部机制非常有利于加深我们对模块开发的理解、各项前端工程化的配置以加快我们排查问题（相信不少同学收到过各种依赖问题的困扰）的速度。 本文从三个角度：package.json、版本管理、依赖安装结合具体实例对 npm 的包管理机制进行了详细分析。 一、剖析 package.json 在 Node.js 中，模块是一个库或框架，也是一个 Node.js 项目。Node.js 项目遵循模块化的架构，当我们创建了一个 Node.js 项目，意味着创建了一个模块，这个模块必须有一个描述文件，即 package.json。它是我们最常见的配置文件，但是它里面的配置你真的有详细了解过吗？配置一个合理的 package.json 文件直接决定着我们项目的质量，所以首先带大家分析下 package.json 的各项详细配置。 1.1 必备属性 package.json 中有非常多的属性，其中必须填写的只有两个：name 和 version ，这两个属性组成一个 npm 模块的唯一标识。 npm包命名规则 name 即模块名称，其命名时需要遵循官方的一些规范和建议： 包名会成为模块url、命令行中的一个参数或者一个文件夹名称，任何非url安全的字符在包名中都不能使用，可以使用 validate-npm-package-name 包来检测包名是否合法。 语义化包名，可以帮助开发者更快的找到需要的包，并且避免意外获取错误的包。 若包名称中存在一些符号，将符号去除后不得与现有包名重复 例如：由于react-native已经存在，react.native、reactnative都不可以再创建。 如果你的包名与现有的包名太相近导致你不能发布这个包，那么推荐将这个包发布到你的作用域下。 例如：用户名 conard，那么作用域为 @conard，发布的包可以是@conard/react。 查看包是否被占用 name 是一个包的唯一标识，不得和其他包名重复，我们可以执行 npm view packageName 查看包是否被占用，并可以查看它的一些基本信息： 若包名称从未被使用过，则会抛出 404 错误： 另外，你还可以去 https://www.npmjs.com/ 查询更多更详细的包信息。 1.2描述信息 基本描述 { "description": "An enterprise-class UI design language and React components implementation", "keywords": [ "ant", "component", "components", "design", "framework", "frontend", "react", "react-component", "ui" ] } description用于添加模块的的描述信息，方便别人了解你的模块。 ...