标签: frontend-engineering
带有该标签的全部文章 "frontend-engineering".
什么是前端工程化
发布于更新于随着 npm 及 webpack 的问世,前端的开发方式发生了天翻地覆的变化,生产力大幅提高。而生产力得以提高的一切措施都可称之为前端工程化。 随着工程化的发展,前端开发的以下界限渐渐明晰起来,我把它总结为四个方面。相互促进,相互发展。 1. 构建 1. 开发 1. 测试 1. 部署 由于涉及到方方面面,这里总结一个大纲。 + 编译原理
html-webpack-plugin 原理解析
发布于更新于在现代前端开发中,如何把打包后的 JS 资源自动注入到 html 中? 如果最终打包生成的 main.js 既没有做 code spliting,也没有做 hash 化路径。大可以通过在 index.html 中手动控制 JS 资源。 但往往事与愿违: 1. main.js 即我们最终生成的文件带有 hash 值,如 main.8a9b3
网站的缓存控制策略最佳实践
发布于更新于对于一个网站来讲,性能关乎用户体验,你在更短的时间内打开网站,你将会留住更多的用户。如果你的页面十秒才能打开,那再好的用户交互也是徒然。
index.html 与 http 缓存控制
发布于更新于假设在此之前你已对 http 缓存非常了解,很显然,当我们对静态资源设置 Cache-Control: max-age=7200 时,浏览器在两个小时之内将通过缓存读取静态资源,而并不会再次发送请求。 假设我们网站的目录如下,在 index.html 中会引用 main.js 和 main.css ,拥有网站 js,css,html 经典
如何为前端本地环境配置 https 证书
发布于更新于使用某些 html API 时,https 是前置必须项,这要求我们在本地开发环境也能够配置 https。否则你要每次部署到测试环境才能预览效果,这对开发的敏捷度造成了极大的干扰。
package-lock.json 的意义何在
发布于更新于packagelock.json / yarn.lock 用以锁定版本号,保证开发环境与生产环境的一致性,避免出现不兼容 API 导致生产环境报错 在这个问题之前,需要了解下什么是 semver : $1。 当我们在 npm i 某个依赖时,默认的版本号是最新版本号 ^1.2.3 ,以 ^ 开头可最大限度地使用新特性,但是某些库不遵循该依
monorepo 的发展
发布于更新于monorepo 即一个 repo,多个 package。 + lerna + npm v7 + yarn + pnpm + react + vue + babel + eslint 当 node
生产环境中使用 npm ci 代替 npm i
发布于更新于乍一眼看 npm ci ,CI,恩,看这名字就很适合放在持续集成中。事实也是如此,它更快,更严格,也更适合于放在 CI 中,至于为什么这么说,将会在以下分别做介绍。 npm ci 基于一个独立的库 $1 安装依赖,而它拥有和 npm install 兼容的 API。当它安装依赖时,默认是缓存优先的,它会充分利用缓存,从而加速装包。 直接从
在生产环境中优化你的 npm i 速度
发布于更新于对于一个前端应用,或者说是一个 Node 应用,在 CICD pipeline 中,无论是构建,测试,部署,其中必不可少的环节就是依赖安装: npm i
如何对 npm 包进行升级
发布于更新于npm 的版本号为 semver 规范,由 [major, minor, patch] 三部分组成,其中 + major: 当你发了一个含有 Breaking Change 的 API + minor: 当你新增了一个向后兼容的功能时 + patch: 当你修复了一个向后兼容的 Bug 时 假设 react 当前版本号为 17.0.1 ,
如何对 npm package 进行发包
发布于更新于在发布公共 package 之前,需要在 $1进行注册一个账号。 随后,在本地(需要发包的地方)执行命令 npm login ,进行交互式操作并且登录。 发布一个 npm 包之前,填写 package.json 中以下三项最重要的字段。假设此时包的名称为 @shanyue/just-demo 之后执行 npm publish 发包即可。
如何临时修复 node_modules 某个库的紧急问题?
发布于更新于假设 lodash 有一个 Bug,影响线上开发,应该怎么办? 答: 三步走。 1. 在 Github 提交 Pull Request,修复 Bug,等待合并 1. 合并 PR 后,等待新版本发包 1. 升级项目中的 lodash 依赖 很合理很规范的一个流程,但是它一个最大的问题就是,太慢了,三步走完黄花菜都凉了。 此时可直接上手修改
如何找到一个合适的 npm 库
发布于更新于由于业务需求,我需要一个 React 的弹框组件,我应如何快速选择一个合适的 npm 库? 在错误的网址进行搜索,事倍功半: 1. ~~某度~~ 在正确的网址进行搜索,事半功倍: 1. $1: 官方网站,权威网站 2. $1 3. $1 不要使用错误冗长的关键词搜索: ~~我需要一个 React 的弹框组件~~。 请使用正确的关键词进行搜
前端工程化实践
发布于更新于1. $1 1. $1 1. $1 1. $1 1. $1 1. $1 1. $1 1. $1 1. $1 以下 TODO 1. 如何部署 SSR 应用 1. 图片处理与工程化 1. $1 1. CDN 下 index.html 应如何安放 1. $1 1. 使用 CICD 构造你的前端质量保障体系 1.
style
发布于更新于在打包器,比如 webpack 中,需要借用 loader 将非 JS 资源转化成可识别为 Javascript 的 module。 在 webpack 中,处理 css 稍微比较费劲,需要借用两个 loader 来做成这件事情: 1. $1: 处理 CSS 中的 url 与 @import ,并将其作为模块引入 1. $1: 将样式注入
Tree Shaking
发布于更新于class 是否可以 Tree Shaking + CONCATENATED MODULE Tree Shaking 指基于 ES Module 进行静态分析,通过 AST 将用不到的函数进行移除,从而减小打包体积。 有例为证: > 以下示例可在 $1 中进行在线演示 最终打包过程中, sub 没有被引用到,将不会对它进行打包。以下为打包
javascript 代码是如何被压缩的
发布于更新于在前端中但凡谈到打包,肯定要提及到 webpack,毕竟它现在已经是最为流行的打包工具。但 webpack 更多地是表现在 术 上,于是我决定写这篇文章,更多地讲解一些关于 道 的。 对于一个前端而言,生产环境的静态资源优化,它既是面试中的高频问题,同时也最容易成为平时工作中的 OKR/KPI。
如何提升 webpack 的构建速度
发布于更新于使用 $1 可评估每个 loader/plugin 的执行耗时。 webpack5 内置了关于缓存的插件,可通过以下配置开启。它将 Module 、 Chunk 、 ModuleChunk 等信息序列化到磁盘中,二次构建避免重复编译计算,编译速度得到很大提升。 如对一个 JS 文件配置了 eslint 、 typescript 、 bab
AST 的生成
发布于AST 是 Abstract Syntax Tree 的简称,是前端工程化绕不过的一个名词。它涉及到工程化诸多环节的应用,比如: 1. 如何将 Typescript 转化为 Javascript (typescript) 1. 如何将 SASS/LESS 转化为 CSS (sass/less) 1. 如何将 ES6+ 转化为 ES5 (b
dev 与 devDep 的区别
发布于当 require('package-hello') 时,假设 package-hello 是一个 npm 库,我们是如何找到该 package 的? 1. 寻找当前目录的 node_modules/package-hello 目录 1. 如果未找到,寻找上一级的 ../node_modules/package-hello 目录,以此递归