前端工程化实践视频教程

一、前端工程化实现的技术栈有很多，我们采用ES6+nodejs+npm+Vite+Vue3+router+pinia+axios+Element-plus组合来实现 ECMAScript6：Vue3中大量使用ES6语法（/s/1sFhRz4JX9AH37xdfMhBNtw 提取码：7dl5 ） Node.js：前端项目运行环境 npm：依赖下载工具 Vite：前端项目构建工具 Vue3：优秀的渐进式前端框架 router：通过路由实现页面切换 pinia：通过状态管理实现组件数据传递 axios：ajax异步请求封装技术实现前后端数据交互 Element-plus：可以提供丰富的快速构建网页的组件仓库 二、在做eslint和commitlint的时候，可以使用--no-verify 跳过，这种情况下该如何强制卡点【热度:233】 跳过 eslint 和 commitlint 的钩⼦，使⽤ --no-verify （对于 git commit 来说是 -n ），的确是⼀个容许开发者在紧急情况下超越钩⼦检查的⼿段。然⽽，这也削弱了代码质量保证的制度。以下是⼀些⽅法，可以⽤来加强这些卡点的靠谱办法： • CI/CD流⽔线中增加检查：在你的CI/CD流程中增加 eslint 和 commitlint 的检查步骤。如果检查失败，则阻⽌代码合并或部署。 • 强制挂钩：虽然开发者可能在本地禁⽤钩⼦，但你不能控制别⼈的本地环境。相反，你可以编写服务器端的钩⼦，⽐如在Git仓库的服务器上使⽤ pre-receive 钩⼦，来拒绝不符合规范的提交。 • 定期⾃动化检查：定期运⾏⼀个⾃动化的脚本或GitHubAction，检查代码库的eslint与commitlint违规情况，并⾃动创建⼀个修复问题的issue或拉取请求。 你可以最⼤限度地减少绕过 eslint 和 commitlint 检查的情况。然⽽，值得记住的是，在极少数情况下，可能存在合法的理由需要紧急提交代码。因此，为了灵活性和效率，完全禁⽌ --noverify 可能不是⼀个最佳的选择。好的实践中应该找到安全和灵活性之间的平衡，核⼼在于建⽴⼀个质量意识，制定明智的操作规范。 三、前端不仅仅是 web 的前端 首先要说的是， 前端不再是单一化的对于自己行业的前端了， 比如游戏前端 unity-3D，客户端，安卓，IOS，windows桌面端。以后也许会出现 一个语言配合各种插件进行无缝生成其他端的工具， 而前端想要有竞争力则必须要学会相对应的行业知识。比如做游戏需要知道点点的图形学知识。然后进行行业开发则可以。银行医院则有自己的要求。总之，大前端不是吹的。身为后端出生的我，深深感觉到了前端的发展， 毕竟2016 年的时候美工和前端有时候可以一起做，而现在已经是一个工程化的内容了 工程化仅限于前端开发，它可以应用于各种不同类型的软件开发，包括服务端开发、App开发、桌面程序开发和应用脚本开发。以下是对每个主题的介绍和简单示例： 服务端开发： 在服务端开发中，工程化通常包括自动化构建、依赖管理、测试、持续集成等方面的内容。一个常见的例子是使用Node.js开发一个基本的Web服务器： // server.js const http = require('http'); const server = http.createServer((req, res) => { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.end('Hello, Server!'); }); const PORT = process.env.PORT || 3000; server.listen(PORT, () => { console.log(`Server is running on port ${PORT}`); }); 在这个示例中，我们使用Node.js创建了一个简单的HTTP服务器，然后可以使用构建工具（如Webpack）和测试框架（如Jest）来进一步工程化开发流程。 四、微前端技术的兴起主要源于前端开发领域的框架多样性和版本碎片化的现状。除了主流的 React、Vue 和 Angular 等框架外，还存在许多老旧的项目和其他框架。同时在业务高速迭代的情况下，前端技术的快速演进和多样化导致了许多项目使用不同的框架和版本。然而，这种多样性和碎片化使得项目的维护和升级变得复杂和困难。在这种情况下，业务开发人员在接手升级或持续迭代项目时面临着巨大的困难。 对于需要快速保证整体技术的统一并实现需求的持续迭代的情况，微前端是一个非常好的切入点。它提供了一个渐进式的更新路径，允许团队按照优先级逐步进行技术的更新，并推进工程化中的技术规范化。通过合理的规划和执行，微前端可以帮助团队更好地应对技术变革和需求变化，提高开发效率和产品质量 五、为什么要进行前端工程化 用户的需求从最开始简单的页面在向复杂的应用发展。前端需要做的事情更多，同时也要追求更友好的用户体验。 第一阶段：石器时代 适合小项目，不分前后端，页面由jsp、php、tornado template等在服务端生成，浏览器负责展现。 第二阶段：后端MVC 为了降低复杂度，有了Web Server层的框架升级，比如Structs、Spring MVC等。 以上两个阶段存在的问题 前端开发依赖开发环境 前后端没分离，可维护性差 六、为了统一大家的代码风格，统一使用项目中的配置文件作为配置项。由于 ESLint 的主要功能是代码质量检查，Prettier 的主要功能是代码风格检查，所以不要在 ESLint 中去配置代码风格相关的规则。 prettier。 一个很流行的代码格式化工具，你很容易在编辑器找到实现它的各种插件，这里用它在代码提交前做代码格式化。 eslint。 代码检查工具。eslint 也可以负责一部分代码格式检查的工作，但是 prettier 已经做的很好了，所以我便没用 eslint 的代码格式检查，只让其负责代码错误检查。 七、脚手架存在的意义？（Why） 随着前端工程化的概念越来越深入人心，脚手架的出现就是为减少重复性工作而引入的命令行工具，摆脱ctrl + c, ctrl + v，此话怎讲? 现在新建一个前端项目，已经不是在html头部引入css，尾部引入js那么简单的事了，css都是采用Sass或则Less编写，在js中引入，然后动态构建注入到html中；除了学习基本的js，css语法和热门框架，还需要学习构建工具webpack，babel这些怎么配置，怎么起前端服务，怎么热更新；为了在编写过程中让编辑器帮我们查错以及更加规范，我们还需要引入ESlint；甚至，有些项目还需要引入单元测试（Jest）。对于一个更入门的人来说，这无疑会让人望而却步。而前端脚手架的出现，就让事情简单化，一键命令，新建一个工程，再执行两个npm命令，跑起一个项目。在入门时，无需关注配置什么的，只需要开心的写代码就好。