实施前端工程化过程中的几个概念的边界和作用

前端工程化涉及的几个概念和作用区分清楚了，前端工程化做起来就得心应手了。

先来一张图，直观地看看这貌似混乱的关系

眼花了吗？接下来讲几个概念就清楚了

技术域（或技术方案）

也就是图中黄色的椭圆形部分，其中包含了形形色色的前端技术域，所以说前端技术百花齐放真不是吹的。

这部分也是本图的核心部分，如果没有形形色色的技术域，就没有形形色色的 lint （左上角那些云彩图形），也就没有各种转译工具（右上角那些图）：

lint

直白地说，就是定一个风格规范，让你和你同事的代码风格保持一致，不至于 ggpull 看到代码之后每个人都萌生去打别人的冲动。

转译工具

我们想彰显自己时刻走在一大波码农的前列，于是就用最风骚的姿势来 coding，可是 ES6/7/8 浏览器原生不支持啊，typescript 写了也不能直接运行啊，怎么办？

好办，转译工具上场。

ES6/7/8 有 babel 来管，typescript 可以使用 tsc 来处理，balabalabala...，这就是所谓的转译工具，它们用更骚气的操作，把你最风骚的姿势，幻化成一个个朴实无华的花朵

webpack

假如我写了一个项目，模块划分地极其精美，写起来贼爽，可是不能一股脑儿都塞给浏览器让它运行的时候也一个一个地加载吧？那么能否把项目中的文件经过某种处理，最终输出一个或若干个包？

可以，webpack 上场，打包专用。

对了，项目中使用了 ES6/7/8，还用了 typescript，对了，还有 less，能否在打包过程中统一处理掉？

也没问题，于是针对各种技术域就有了各种 loader：ts-loader、babel-loader、less-lodaer...

webpack 真是一个神奇的存在，看了文档就忘记，用的时候再看，看完再忘，忘完再看，如此往复循环，生生不息...好在这并不是一个高频发生的噩梦

综上

我想说的是：技术域是核心，为了解决特定问题，围绕着它们产生了一个个的工具，于是形成了生态圈，lint、转译工具、webpack 都是生态圈中的一分子，它们各有其专业用途。

当你知道了这几个概念的关系和它们的定位，在实施前端工程化的时候心中就有了边界。它们都是锤子，是不同用途的锤子，而你是锤子手（注意不是锤子手机）。

p.s.: 本文没有经过严格考证，仅供粗浅理解，但依然欢迎指正。

转载于:https://juejin.im/post/5bfd29fce51d4551584c87e4