NiceLeeのBlog 用爱发电 bilibili~

Webpack Plugin制作0-序

2021-10-12
nIceLee

阅读:


拟通过制作Plugin和Loader加深对Webpack的认知。

前言

我为什么写下这些东西

  •         曾经看过一部印象深刻的电视剧,记得当时大结局被感动得一塌糊涂,也有还几部小说看得励志打鸡血的。我只记得有那么几个深受触动的瞬间,却总也找不回了。
            也曾有学习巩固基础,感觉学完后目空一切尽在彀中的自信。没想到出道即巅峰,见识或许慢慢的是长了,但心态在随后的繁琐事中慢慢的也没了。
            我想记录下自己此时的状态。或者说,我有这么一个期望,当我回顾此时的学习过程和心路历程,能够快速找回此时的状态。
     
     

  •         这不是我第一遍学webpack了,以前学的时候也听别人讲了webpack的基本原理,讲了这个资源加载用哪几个loader,要做那个使用什么plugin,开发环境该怎么配置,生产环境又怎么怎么样。
            但是没用。没过多久基本上全忘了。有人说这些配置只在项目初始化那会配置一次,而且流行的框架基本上都有脚手架,配置都是现成的,看看文档的事,忘也就忘了。
            我也这样认为,而且一直这样认为,到现在也一样。
            但是当我尝试自己新建一个工程,npm i -S -D一大片相关依赖,然后因为版本问题折腾了半天不成功时,我感到十分沮丧,以及前所未有的挫败感。
            我知道这是因为版本升级,组件接口或者功能变化,组件之间协调出了问题造成的,但也仅此而已了。除了在网上搜索恰当的版本号,我对此无能为力。
            我意识到我从来没有真正了解过Webpack。
            我又想起另一件事情。
            在我上学的时候是有《计算机网络》这门课程的,教材谢希仁那本,那本书挺好,我感觉当时也学得挺好的,至少绩点上还过得去。
            作为一门网络课程,理所当然提到了HTTP协议。你跟我考试这部分,我肯定没问题;你要我说,我也能说个三四五六来。
            但你要我基于套接字手撸一个简单的HTTP0.9服务器,我只能回你一个黑人问号脸。即使这之前因为项目原因我没少做UDP/TCP通信的case。
            这就很尴尬了。
            你以为你懂了,但其实并没有,至少不能学以致用。
            不过真的致用以后,你又会发现其实也就那么一回事,先前只是脑子没开窍。
            接下来HTTP1.1/HTTP2等更加复杂,也许你的coding能力并不足以较小的代价优雅地将它实现,但你应该有了底气。
            举个不那么恰当的例子,虽然你不一定会做菜,但你仍旧可以点评厨师做的食物。当然前提是你品尝过它。
            也正是因为这个经历,我想通过写plugin和loader的方法,从另一个角度重新认识webpack。
     
     

  •         在写这些之前,其实plugin和loader都已经做好了,毕竟只要入了门其实很简单。现在把它写下来告诉别人我是怎么做怎么想的(假设会有人),应该能巩固所学吧。
     
     

  •         我并不能对自己写的内容保证什么。人在面对未知时,视野总是狭隘的。也许经验丰富后高屋建瓴回看此时的东西会不那么成熟。
            说实话,我现在看我半年前写的东西都会感叹那都是些什么啊。
            总不能玩过几下云服务器/服务器就说自己会运维了,写过几个爬虫就说自己会js分析了,跑过几轮模型训练就说自己会机器学习了,用过几次frida就会说自己会Android逆向了,照着别人做了几个玩具就说自己有项目实战经验了。
            我就自曝一下吧,以前学Java Web的时候,我一度以为生产环境和开发没啥两样,都是把Eclipse打开放在那里,然后跑起来…[捂脸]
            在此我还是要狡辩几句,这是因为我从图书馆里借的那几本书没提打包war包以及Apache部署(或许提了,只是我跳过了),而且实习的时候也没接触到项目打包那一块。哈哈哈。
            为此,我还专门想了一下,没了IDE我们应该怎么打包我们的java源代码。 嗨,入门的第一个hello world就是写个类,然后javac编译,然后java执行。 类多了以后,把它们都编译成.class,放个MANIFEST说明文件,把它们压缩一下,改个.jar后缀名,这不就出来了吗。。。
            有时候我们自己都不知道自己无知得多离谱。。。

学习大前端的一些想法

  • 我接触html/js/css算是比较早的,那时h5和css3才刚刚兴起,前端这一块远未成熟。 基本上还属于页面靠下载模板或者直接从其它网页里面抠,撸起袖子直接靠jQuery蛮干的野蛮生长的阶段。
    现在查了一下,Bootstrap那时才刚出生😳。
    当时重心没放在这块,主要在学jsp + java struts2,感觉前端js这东西真的简单,有手就行,我上我也行。
            
    后来听说了js的新规范ES6,也没怎么关注,感觉反正能用就行。
            
    再后来因为需要,主要玩工控机、Arm板或者单片机这些东西,有很长一段时间没有搞过Web这一块,前后端都没有,感觉生疏了不少。
            
    一段时间过去,前端变化是真的大。
            
    以前想要引个库,看别人的readMe基本上是给个script标签引入再加段js代码。 慢慢的这样的Repo越来越少了,清一色的npm + import开干,我尼玛,对非前端人员太不友好了,tmd。
            
    这其实是前端逐渐工程化的一个过程,渐渐不再是手撸html再手撸js+css的事了,即使是新语法的<script type='module' src=...>应对也十分吃力,我们写的源文件在慢慢变成浏览器看不懂的东西,需要经过一定的润色翻译。
    但做出这样的牺牲是有原因的,像Vue、jsx、less这些不说。举一个html模板的例子,这种使用liquid语法实现html套娃,复用代码的方式,就是最早的一种尝试。
    浏览器能读得懂html模板吗?
    也许可以,但那肯定缺少数据,只是个空壳UI。当拆分的更加细致,连样子都会看不到了。举个例子,这篇博客所用的Jekyll,就是这样的实践。
    或许你会说Jekyll用的是ruby,这不算数。但要我说,要是nodejs没有出生,没准这事还真让ruby给包了。当然也可能是其它语言,就看那位伟大的全栈工程师哪个用的最顺手了。

  • 我一度很排斥js和python这两门语言,将它们放在程序语言的底端。排斥是因为它们上手实在是才容易了,然后到处攻城略地。
    浏览器有js,桌面应用electron有js,后端node experss有js,移动端React Native有js,整个都包圆了,到处都有js就离谱。
    还有python,我就没见过搞机器学习的不会python的。不得不说python的生态很完好,你能想到的日常功能基本上都实现了。他们把程序都写好了,只差你写几行代码调用了。

  • Python、JavaScript这类弱类型的语言,写起来非常爽,但是看起来非常费力,这是我的感觉。
    不是它的实现者,对整个工程十分熟悉,在修改较底层代码时会非常吃力。
    我知道我要传入或者返回一个东西,它的作用我也比较了解,但我不知道应该怎么去构造/修改它。 我不确认这个对象具体应该具有哪些属性,生怕多了少了或者错了。 我在要修改的地方上下溯源了几个函数,它们有的只是简单的传递参数,有的只是涉及到部分属性,但我看到的这部分属性就是需要修改的全部了吗?
    我不确定。即使我的修改生效消除了一个bug,心里也没底,不知道是否埋下了不知名的隐患。
    我不知道我的理解到不到位,但我相信TypeScript的诞生是有道理的。

  • 但说了那么多,最后还是逃不过一句真香。。。

我对Webpack的一些理解

  • Webpack是用于将前端代码(.js/ts/jsx/vue/css/less/html…)打包生成浏览器(或其它终端)可用的前端资源的一个工具。
    与Java开发做一个类比,它有点像maven,但又不是。
    因为它缺少maven的包管理功能,这是由npm或yarn来完成的。
    但某些方面又远比maven强大,因为它的编译打包机制使得它在开发测试的过程中占据重要地位。
    可实际上又非常弱鸡,离开插件/加载器模块寸步难行。
    扯这么多,实际上单独拿出来做对比没啥意义,就当大脑的热身运动。

  • Webpack,以及辅助实现webpack功能的plugin、loader的js,可以把它看作与python、ruby、java等语言类同,最好将它和浏览器里运行的js区分开来。
    因为遵从浏览器规范的js是有局限的,本地文件的读写、不受限制的网络请求是它跨不去的坎。
    所以,plugin、loader开发时使用的是node所遵循的规范CommonJS,而不是浏览器的ES6。
    当然,开发时因为测试需要传入浏览器的那部分不算,把这个代入到其它语言的场景应该也很好理解。
    反而是src里面的代码,因为我们要站在浏览器的角度去思考,所以常常写的是ES6。但实际上ES6或者CommonJS二者皆可,因为最终都是要经过node执行babel来翻译,CommonJS它肯定也是认识的。

我该如何获取帮助

  • 一般而言,有四种情况:
  • 对于前两种(尤其是第一种)情况下获得的信息,需要抱着审慎的态度。
    因为它很可能过时了;或者并不适用于你的问题,因为会有很多不同的原因导致相同的异常抛出,当情况复杂时尤其如此。
    正因如此,我从不在CSDN等地方写下自己的东西,只是在自己的小窝里做下笔记。
    • 因为我知道自己不能保证写下的东西的有效性。
      一个东西做完了,过了一段时间还能使用吗?我不确定。
      即使过了很久很久,久到它百分百过时了,我会专门去改动它、删除它吗?我不会。

    • 因为我也不知道自己的视野是不是狭隘,导致我的想法偏于正途;野路子虽然能实现目标,但实际上也许有更优的解决方案。

系列文章


内容
隐藏