online阳光-专注于大前端行业领域

前言官方文档 既然已经有ESLint以及stylelint了，为啥还要有这个prettier呢？👽 我们都知道，项目团队在研发过程中，必须严格遵循统一的一个代码规范，即便是拥有了ESLint与stylelint的加持，在实际的编码过程中，也还是难免需要借助于插件、三方库来协助规范整个团队的项目开发，因此，我们需要在项目中通过统一提供的编码规则配置方案，由项目自身的开发依赖以及配置方案，完成项目自身的代码规范化自动控制，保证项目在不同的ide、环境，不同的人员手中都是采用的统一的一个配置的！！！ 什么是prettier prettier是一种自用的代码格式化程序，支持有：js、JSX、Vue、Flow等等语言，它删除了原始样式，并确保所有的输出都符合一致的格式！😕 比如 🈶 👇 1⃣ 个函数： 1234function foo(arg0, arg1, arg2, arg3){ // ... 此处隐藏代码的实现} ☝ 针对上述的函数，假如调用foo函数所传递的参数是较为简单的常量或者是变量的话，则一般一行是能够正常展示完整的，但是，如果传递的参数是一个函数的执行结果，而且这 ...

前言Stylelint官方文档 与之前学习的 ESLint 相类似，Stylelint作为一个css linter，可帮助我们避免编写错误的css样式代码，并强制执行预先协商好的“约定”配置，配置可从标准的配置继承而来，也可重写！ Stylelint的相关特性 提供的现成的业界css语法和功能的自定义规则； 支持插件的方式，可创建自定义规则； 提供自我修复的能力，自动修复配置告知的预警规则； 可根据自己的习惯进行自定义； 可从html、markdown、css-in-js等文件中提取css进行校验； 可扩展至scss、sass、less、sugarSS 👉 Stylelint可有效帮助我们避免一些不必要的错误，比如有： 拼写错误的css属性； 重复的选择器； 畸形的grid布局区域 👉 Stylelint还可按照配置约定来执行，比如有： 设置适用单位； 强制命名模式，比如自定义属性； 设置限制，比如设置id选择器的数量； 指定符号，比如现代颜色函数； 如何使用？ 关于Stylelint的使用，一般 🈶 👇 3⃣ 个步骤： 安装相关的环境以及配置 通过命令来安装 ...

前言ESLint官方文档 根据配置方案，来发现并报告 js中的问题以及提供建议的工具，目的是使代码风格更加一致，同时避免不必要的错误！👉 由于要发现代码中的错误，因此ESLint必不可少地需要解析代码文件(采用Espree，从Acorn基础上演变而来)，对解析生成的AST树进行方案评估。另外，在配置文件中的每一个规则都是一个个的插件！！ 😕 这里提及到配置方案，也就是我们所使用的配置文件，它是都包含有哪些成员呢？它是如何被使用的呢？ 👇 将一一解释一下！！ ESLint集成 一般的，在现有项目中集成ESLint，无非 🈶 2⃣ 种方式： 1. 一键初始化 通过在项目中直接执行 👇 的命令，将自动在当前项目中安装对应的ESLint检测工具环境： 1npm install @eslint/config 2. 手动安装 + CommonJS + CLI 通过在项目中安装这个ESLint依赖，并创建对应的.eslintrc文件，如下所示： 1npm install --save-dev eslint 安装依赖完成后，采用CommonJS的方式来编写这个.eslintrc文 ...

前言 在刚开始接触这个express框架的时候，利用其脚手架命令，来创建项目的过程中，发现其中 🈶 一种渲染引擎: handlebars，这种引擎在之前的学习文档中 handlebars的学习与使用用 已经有具体提及到，本章节主要想将自己在使用express + hbs搭建这个SSR渲染页面的过程给记录下来，方便后续自己 🈶 来及时查阅！ 一、express项目初始化 借助于express应用程序生成器，进行项目的初始化工作 1express --view=hbs express-hbs-demo ☝ 命令则在当前目录中创建了一个名为express-hbs-demo的express项目，进入该目录，并安装相应的依赖，然后执行对应的脚本程序，将程序运行起来: 1npm install && npm run start 运行结果如下：👾 与此相对应的生成的文件目录结构如下： 二、追加express-hbs库的支持 要让程序能够支持handlebars的相关特性(比如helper、partials)，那么我们可以是借助于 express-hbs 三方库，通过在应用程 ...

前言最近，任何行业都被chatGPT影响：一款好用到超出认知的聊天机器人，其强大的学习和处理收集能力，能够完美地编撰文案、编程的辅助(从咱这两次周末的分享会议总结得知)、语种翻译，还能进行绘制插画，提供法律知识工作等等！基本上是你要什么，他就给什么，而且还能够超出自己想象地来提供，可以说是目前人工智能界最靓的仔！ 😕 那么，我们是不是需要担忧一个问题：我们怕不是要失业了吧？在倾佩chatGPT之余，再次感慨万千：这个激流勇进的时代，稳定已经成为过去时！比如我们的经验可能随时过时，我们的工作可能随时被取代或被更好的方式所折服！ 我能够做点什么？感激生活/工作中的变化，所有一成不变的路，其实都是下坡路！从自身从事编码工作以来，前5年基本上是只做android应用开发，可以说自己在前1-2年的时间内，基本上是从入门到上手到应用实战，然后后面几年基本上是在重复前两年的工作，而且除了业务上的熟悉工作之外，每天的工作内容就是重复昨天的编码工作，能力上毫无进展，思维也比较呆板。这种一成不变的路线，诚然是不需要费劲思考，但也会让自己在生活中的改变面前丧失竞争力，唯有主动求变、提升自己的竞争力，才能够 ...

前言官方文档 关于HtmlWebpackPlugin插件的时间，相信不少童鞋应该都是比较熟悉的了，在一些现成的脚手架(像vue-cli、react-cli等开源三方脚手架)中，都被集成进去成为其核心成员脚手架模块，负责将结果目标内容文件给输出出来， 0⃣ 配置的方式来快速开发这个业务项目， 😕 但是，在实际的项目开发过程中，避无可避地需要针对现有的采用脚手架搭建起来的项目进行定制化的配置，来满足不断变更的业务需求，提升编码的效率，因此，很有必要来对所使用的相关插件(HtmlWebpackPlugin)进行深入的了解！关于官方的解释是：HtmlWebpackPlugin 简化了 HTML 文件的创建，以便为你的 webpack 包提供服务。这对于那些文件名中包含哈希值，并且哈希值会随着每次编译而改变的 webpack 包特别有用。你可以让该插件为你生成一个 HTML 文件，使用 lodash 模板提供模板，或者使用你自己的 loader。👾 这里提及的使用默认的lodash模版来生成Html文件，还可以使用自己的loader，比如像handlerbars-loader、html-l ...

前言webpack官方loader介绍 关于webpack中的Loader，平时项目中可能比较少用到，一般的脚手架程序都自动集成相关的loader，但是如果我们能够将不同的loader给搭配起来，形成项目自身特色的loader集合体的话，在开发/编码过程中可以提升不少的效率，而且也让程序可以 🈶 更健壮的稳定性！😕 那么什么是Loader？如何使用Loader？Loader的加载执行过程是怎样的？一般都有哪些常用的Loader？如何自定义Loader来辅助工作？ 什么是Loader？ loader用于对模块的源代码进行转换，可以让我们在使用import或者’load’模块时预处理文件，通过对loader的定义与使用，可以让我们在处理不同的文件格式时，采用不同的文件解析协议，比如像*.hbs、*.vue等文件，通过采用对应的loader来将其解析为不同的内容！比如将typescript转换为普通的js，活着将内联图像转换为data URL，甚至允许我们直接在js模块中直接导入css文件。😕 关键在于预处理，使得我们的所有的模块(文件)加载时都可以先处理转换一下，采用一些官方的公 ...

前言 本文主要着重介绍关于webpack中的模块是如何管理的，其实在网络上已经也有不少的文章关于ES6、CommonJS、AMD的相关介绍了，本文主要侧重于这个模块管理的使用方式！三者都是对模块进行依赖管理的目的，实现同步/异步加载的目标！ ESM ESM主要包含 🈶 2⃣ 个关键词：import和export！ export export 语句用于从模块中导出实时绑定的函数、对象或原始值，以便其他程序可以通过 import 语句使用它们。被导出的绑定值依然可以在本地进行修改。在使用 import 进行导入时，这些绑定值只能被导入模块所读取，但在 export 导出模块中对这些绑定值进行修改，所修改的值也会实时地更新。存在 🈶 种方式的导出： 命名导出（每个模块包含任意数量） 默认导出（每个模块包含一个） 语法规则： 123456789101112131415161718192021222324252627// 导出单个特性export let name1, name2, …, nameN; // also var, constexport let name1 = …, ...

前言DefinePlugin官网链接 允许在编译时将你代码中的变量替换为其他值或表达式，它并不是变量赋值，而是在编译期间进行字符串的精准匹配与替换！可以理解为，我们在webpack打包的项目中，通过在配置文件(webpack.config.js)中使用插件DefinePlugin，并传递给该插件对应的变量/表达式，都可以在项目中的*.js文件中访问到这些变量/表达式的定义，而无需重复地在所有的文件中进行二次定义！这意味着我们可以定义全局开关等控制，来对代码进行区别式运行的操作！ 用法123456789// webpack.config.jsmodule.exports = { plugins: [ new webpack.DefinePlugin({ // 此处是相关的变量/表达式的配置 a: 999 }) ]} 关于该插件中每个健值对可以 🈶 👇 的定义方式： 如果该值为字符串，它将被作为代码片段来使用; 如果该值不是字符串，则将被转换成字符串（包括函数方法）; 如果值是一个对象，则它所有的键将使用相同方法定义（也就是遍历key来替换）; ...

我是谁 webpack中与assets资源进行交互的模块，逐渐通过对NormalModuleFacotry.hooks.createParser、NoemalModuleFactory.createGenerator、Compilation.hooks.renderManifest等几个钩子容器函数的监听！ 干预的钩子函数 通过提供的干预的钩子函数，创建对应的Parser以及Generator对象，来处理webpack中的默认的对asset资源加载的统一配置，也就是对配置的实现！ 1、NormalModuleFactory.hooks.createParser 针对不同类型的createParser创建对应的Parser对象，主要由以下 👇 几种类型的asset： asset类型 对应创建的Parser asset AssetParser asset/inline AssetParser asset/resource AssetParser asset/source AssetSourceParser 2、NormalModuleFactory.ho ...

前言 作为webpack中的代码生成器插件，主要负责将对应的chunk生成对应的结果字符串内容！在开始具体解析之前，首先，现看一下 👇 2⃣ 个最简单的结果生成情况对比！ 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657 (() => { // webpackBootstrap var __webpack_modules__ = ({/***/ "./src/module1.js":/*!************************!*\ !*** ./src/module1.js ***! \************************//***/ ((module) => {module.exports = function test() { console.info("我是来自于模块一中的test方法");};/***/ }) });/************************ ...

前言 Module，作为webpack中的基本模块单元，继承于DependenciesBlock，使其具备缓存其他模块而形成的依赖关系，也就是说，webpack中的关于模块的定义声明皆来自于此！我们所定义的一个个文档都是一个个的模块，模块之间允许互相依赖，而依赖在程序中的表现形式，则是以DependenciesBlock中的Dependency[]数组来存储的 DependenciesBlock 作为抽象的模块基类，允许添加/删除依赖，就像是Array数组般一样！ 通过其成员属性dependencies(Dependency数组类型)，来维护引用依赖的其他模块，主要用与同步加载的其他模块； 通过其成员属性block(AsyncDependenciesBlock数组类型)，来维护引用依赖的其他模块，采用异步分割代码加载的方式来加载的其他模块； parent属性，指向父模块； Dependency 作为依赖模块形成的基本单元，是一个模块关系的基本单元，可以认为是依赖的代码位置描述对象，其成员属性/方法主要有： loc: 是一个DepencencyLocation对象，代表依赖形成 ...

前言 作为实际开始编译的入口，该插件由webpack的核心默认插件自动加载，无需额外通过配置文件引入！ 入口的开始 通过对该插件的代码阅读后发现，该插件主要针对两个钩子容器函数设置监听动作 compiler.hooks.compilation compiler.hooks.make 🌠 下面我们关键分析一下这个compiler.hooks.make触发时，做了什么动作！ 一切编译动作的源头 在compiler.hooks.make方法触发时，在该插件中通过调用compilation.addEntry来从入口文件加载相关的依赖文件！一切回到了 Compilation.js

前言 在阅读到Compilation的代码执行过程时，发现有一个隐藏的异步队列执行者，😕 这里为啥要单独整一篇文章来阐述这个异步队列执行者呢？我觉得应该是在于它的一个比较独特的设计理念打动了我，下面就来具体分析一下并尝试来使用这个异步队列的执行者！添加完成一个元素后，自动执行一个对应的回调动作，并能够实现与父AsyncQueue对象共享的“线程队列”资源 如何使用？1234567891011121314151617const AsyncQueue = require("../../lib/util/AsyncQueue");let child = new AsyncQueue({ name: "test", parallelism: 2, processor: () => { console.info("我是来自于processor的执行动作"); }});child.add({}, err => { console.info("我是来自于添加失败后的回调！");});child.add({}, err => { console.info("我是 ...

前言 官方链接 DllPlugin一般与DllReferencePlugin配套使用， 😕 为什么这么说呢？ DllPlugin一般用来在webpack中创建一个单独的dll-only-bundles，同时生成一个名为manifest.json文件； DllReferencePlugin则是会通过引用上述第一步所创建出来的manifest.json文件，来告知如何加载模块；一般在webpack.config.js中使用，此插件会把 dll-only-bundles 引用到需要的预编译的依赖中，用某种方法实现了拆分 bundles，同时还大幅度提升了构建的速度，从字面意思上称之为：”动态链接引用插件+对应json配置使用” dll动态链接库 **动态链接库(Dynamic-link library，简写为DLL)**，是在winsows系统中实现共享函数库的一种方式，一般就是把一些经常回共享的代码制作成DLL文档，当可执行文件调用到DLL文档中的函数的时候，才会将DLL加载到内存中，当程序有需求时函数才进行过滤，可大幅降低存储！ 👽 DLL其实就是一个缓存文档，使用的时候，不 ...

前言官方链接 webpack中真正的”编译器执行者”，Compilation实例能够访问所有的模块和它们的依赖（大部分是循环依赖）。 它会对应用程序的依赖图中所有模块， 进行字面上的编译(literal compilation)。 在编译阶段，模块会被加载(load)、封存(seal)、优化(optimize)、 分块(chunk)、哈希(hash)和重新创建(restore)。👇 是关于Compilation对象的组成结构： Compilation的工作流程是怎样的呢？ 👽 其实Compilation自身并没有做任何的动作，而是一堆的插件它们负责来实现的！因为Compiler创建完这个Compilation对象之后，就没有针对这个Compilation对象进行调用其相关的API了，而是将Compilation以及params作为参数，来触发Complier.hooks.thisCompilation 首先，针对一个上面最简单的webpack.config.js进行一个针对thisCompilation事件的一个插件执行队列分析，从上图中我们可以对应整理对应的执行队列： ...

前言官方链接 NormalModuleReplacementPlugin 允许我们将与 resourceRegExp 匹配的资源替换为 newResource。如果 newResource 是相对的，则它是相对于先前资源解析的。如果 newResource 是一个函数，它应该覆盖所提供资源的请求属性。☝ 官方的描述有点绕，简而言之，就是模块的在加载之前进行一个替换，这个替换按照正则表达式resourceRegExp所定义的表达式来实现替换，可以实现到类似于cross-env工具的效果：通过自定义变量的方式来达到根据不同的变量来尽性替换的目的！ 如何使用(官方例子)比如我们 🈶 👇 的一个webpack.config.js配置文件： 1234567891011121314module.exports = function(env){ var appTarget = env.APP_TARGET || 'VERSION_A'; return { // ... 此处隐藏其他的配置 plugins: [ new NormalModuleReplacement( ...

前言 官方链接单从其名字上来看，可以简单理解为创建module的工厂！ 而实际在阅读完它的源码的时候发现，其实它就真的是用来创建module的工厂！Compiler使用NormalModuleFactory模块生成各类模块，从entry入口开始，此模块回分解每个请求，解析配置文件webpack.config.js内容来查找进一步的请求，然后通过分解所有的请求以及解析新的文件来爬去全部的文件，最后，每个依赖项都会成为一个模块实例！！😕 那么NormalModuleFactory是如何从entry开始来解析的呢？解析过程是怎样的？ ☝ 从这里我们可以清楚地知晓NormalModuleFactory是被Compiler所创建的，通过传递一个配置对象，来创建的NormalModuleFactory对象的，那么这个配置对象中的属性又是怎么一回事呢？👉 首先，webpack中的文件都是一个个的模块，也就是说要将文件“转变”为模块，需要fs文件模块，通过读取文件来进行的源文件的读取，但是node中仅仅只能够识别到普通的js/json/node等文件格式，像图片资源等这些，又如何被识别到呢？我们 ...

前言 维护着一个data属性，主要负责记录与读取之前的构建记录，关于这个构建记录，官方的描述是：webpack 的 “records” 记录 - 即「用于存储跨多次构建(across multiple builds)的模块标识符」的数据片段，一般可以通过与webpack.config.js配合配置，直接讲对应的文件给输出出来，可以使用此文件来跟踪在每次构建之间的模块变化。只要简单的设置一下路径,就可以生成这个 JSON 文件 如何使用 配合webpack.config.js，在构建打包的时候输出对应的文件，便于调试调整优化打包配置文件，如下图所示： 监听的钩子生命周期有 Compiler.hooks.readRecords: 从之前的缓存(data，map对象)中读取缓存过的构建记录； Compiler.hooks.emitRecords: 写入构建缓存记录 Compiler.hooks.thisCompilation: