Vesper@之一

#

🔥本文或许可以帮你快速了解前端工程和工程化

当我准备开始写这篇文章的时候，我突然觉得有些迷茫~

通常来讲，我会确定一个主题，然后会让AI给我一个可能的提纲，而我来根据自己的理解，收集，参考一些依据，做一些论证小实验，从而来完成一篇相对负责任的文章，可是这一次我有点犹豫了，因为就这一个主题下，AI给我的提纲和我想说的出入有点大，或者说AI太八股了，而我想说的是一些能够快速解释前端工程化的杂谈。

这是 AI 给我的提纲：

image

这提纲没什么不好的，全面，但是偏正式，偏八股。

而我想说的可能更适合于从实践的角度快速理解前端工程并非想解释前端工程化，因为我觉得只有你知道前端工程的概念，你才能明白工程化。

以下我会从实际工作中的视角代入前端工程，做一个简单的全览。

here we go！

⚠️ 不过在开始之前也需要了解一些前端工程化的八股概念 (偷个懒直接交给gpt)：

⚠️ 阅读本文之后，你会有以下收获：

正文开始👉

⚠️ 特别提示：以下内容旨在帮助快速理解相对局部、相对微观的前端工程化，更多的是前端工程的东西，并不会全面且细致的去阐述前端工程化，若需八股，还是得多看看面经~

当你入职后拿到一个repo坑位后，什么是前端工程？📌

一般来说我们入职后会先熟悉团队的各种开发规范，工作流，通常最初你大概率会负责一个repo坑，也不排除多个或者monorepo的情况，但总体是一样的，下面我们用一个基础的monorepo举例：

image

正常来讲你的前端工程都是基于git做版本管理，基于node和npm做工程管理，而webpack，vite，rollup等其实是基于node的上层工程管理框架，当然也有一些基于rust的工程管理库，比如Rspack，当然了，这几个主要是负责前端工程的打包构建等方面。

我是怎么看的，任何一个Application都是一堆代码和资源组成，这些代码和资源分散在各个文件或文件夹里，而前端工程就是它们和管理的总和。

简单来说就是你看到的repo所有都是前端工程，这是一句废话，但是请听我慢慢解释：

或许你会奇怪为什么没有webpack或者vite或者其他框架的配置文件，其实是有的，只不过在packages目录下具体的子项目里， 不过我想要说的是，不论是webpack还是vite，这些开发及构建工具都是基于node的能力开发的上层框架，而你也可以不用这些， 直接用node提供的能力来开发及构建自己的项目，当然工作中没人会这么做，因为他们提供了强大，便捷，全面的功能。

这就是你拿到的前端项目，这就是前端工程。

当你在 development 环境开发时，什么是前端工程？📌

试想一下当你进入开发阶段了，你会干嘛？我想大多数情况下是这样的（注意：这里并不会深入的探讨每一个步骤的具体实现，而是粗略介绍）：

  1. npm install
    • npm会在node_modules下去安装在npmjs.org官方源（具体源需要根据你的npmrc配置或者你本地npm config配置）搜索到的你的package.json里声明的所有依赖。
    • 并会生成对应的lock文件，方便统一所有开发人员的依赖版本。
  2. npm run dev
    • npm会找到对应的pacakge.script的dev命令，执行命令，这时取决于你的package.json中dev的配置，比如：cross-env API_ENV=development NODE_ENV=development webpack serve --config webpack/webpack.dev.ts，这段命令是用cross-env定义了2个node的环境变量，并根据指定webpack目录下的配置文件，来webpack serve启动。
  3. 编码
    • 编码时，vscode中你的eslint，prettier插件会根据你的eslint和prettier的配置文件来检查你的代码规范和代码风格，基于AST。
    • 一般来说你用的编辑器中，比如vscode，有LSP（Language Server Protocol）服务，为你提供顺畅的编码体验，比如：自动完成，跳转定义，查找引用等。
  4. 保存 -> 更新
    • 一般来说，你修改完代码之后（注意如果修改的是对应的启动配置文件，需要重新npm run），webpack和vite都会进行编译，并更新代码，也就是热替换简称HMR（Hot Module Replace）,而这也是基于node的能力实现的，这里以webpack为例，通常来说开发环境下会启用一个Websocket来进行通信，如有更新，相对应的文件hash会改变，并且告诉浏览器加载新的文件，从而达到热替换的效果。
    • 这里也可以提一句前端常用的devServer配置，也就是绕过浏览器的同源策略的常用方案，proxy代理，其背后也是通过node实现，比如通过httpProxyMiddleware这类中间件来转发你的请求，一旦你配置了devServer或者proxy那么，webpack就会拦截你代码里的请求，转发到目标服务器，以达到绕过浏览器同源策略的效果。
  5. 跑测试用例
    • 一般来说前端单元测试，如果是工具函数的测试用例，就相对简单一些，导入方法，调用，看执行结果是否符合预期即可，也是运行在node。
    • 我们会在开发环境做的稍微复杂一点的单元测试应该来说是组件、页面的功能测试，他会用到一些无头浏览器（headless browser），也是基于node这个JavaScript运行时的，比如：谷歌的Puppeteer，只是它并不会显示UI，但是你仍然可以请求html页面，click某个按钮，检测页面是否有正常显示，或判断某个input元素上是否出现了某个class。
  6. 提交代码

    • 如果你项目配置了husky，并成功安装了githook，那么会根据你配置的githook来做相应的操作，比如下图配置了2个钩子，一个是在执行git commit之前触发，一个是在git commit时触发。

      image

      分别有以下代码： pre-commit：

      2

      commit-msg：

      1

    • pre-commit的代码，会在你git commit之前触发这一段bash命令，在git commit之前会执行npx lint-staged，npx是npm的一个包运行器，我们这里用npx来执行lint-staged，会调用三方库lint-staged，它默认会先读取你的执行目录下的.lintstagedrc这种配置文件，会根据配置文件里的代码，在你的git暂存区进行相应的操作，通常来讲你的.lintstagedrc文件里面是如下代码：

      {
  "*.{js,jsx,ts,tsx,vue}": ["prettier --write", "eslint --fix"]
}

      通常被用来做代码规范的检查，以及代码风格的转换，当然你完全可以随意做其他操作~。

    • commit-msg的代码，会调用三方库commitlint，它默认会根据执行目录下的commitlint.config.js之类的配置文件的具体配置，来对你的commit的message进行检查。

不难看出以上步骤，几乎都是基于node这个runtime来执行，基本上可以说是前端工程离不开node。但现在有一种用rust来构建前端工程体系的趋势，比如Bun，SWC，Rspack，Oxlint等。

当你集成到 test 环境测试时，什么是前端工程？（TLDR）📌

当你集成到 production 部署时，什么是前端工程？（TLDR）📌

😊okk~ 关于局部且微观的前端工程化就水到这里啦~ 未完待续~

This site is open source. Improve this page.