为什么 esbuild 相对于别的构建工具打包这么快？ 基于 Golang 编写，会编译成二进制文件。相对于 JIT 编译器有更高的性能。 Golang 语言层面天然支持并行，并且在 esbuild 中被大量使用。JS 只是单线程。 ESbuild 中的一切都是从头开始写的，例如 TypeScript compiler，这样可以不受制于第三方库的性能。 内存被高效使用，例如，整个过程中 ESbuild 只使用了三次 JavaScript AST。 参考文档：Why is esbuild fast? 第一个例子 Docs:Your first bundle 打包方式 命令行 JS 脚本 Go 脚本 单独引入某个 node 库，不做 bundle 处理 electron 使用 esbuild 打包后启动保错，这时候不对 electron 做 bundle 处理； 1 2 3 4 5 6 7 8 9 require("esbuild") .build({ entryPoints: ["main.ts"], bundle: true, platform: "node", external: ["electron"], outfile: "out.js", }) .

函数式编程与命令式编程最大的不同其实在于：

函数式编程关心数据的映射，命令式编程关心解决问题的步骤

JavaScript 的继承是基于原型(prototype)实现的。它的创造者 Brendan Eich 仅仅花了十天便创造了 JavaScript。Brendan Eich 对这个新语言的设计原则是功能不不需要太强，语法越简单越好。于是便借鉴 Self 语⾔实现了 JS 的继承模型。至于 Brendan Eich 为什么没有借鉴当时火的一塌糊涂的 JAVA 的继承思想，这还要从面向对象继承和原型继承的区别说起。 传统的基于类的面向对象语言，基于根深蒂固的二元性： 类定义对象的基本性质和行为。 对象实例是类的特定体现（manifestation）。 例如，假设 Vehicle （车辆）类的对象有一个名称，并且能够执行各种操作，比如“开车上班”和“运送建材”。Bob's car 是类 Vehicle 的特定对象（实例），它的“名字”是“Bob’s car”。在理论上，你可以向 Bob's car 发送消息，告诉它去“运送建材”。 这个例子展示了这种方式的一个问题：如果 Bob's car 恰巧是一辆运动车，那么它将不能运送建材，但这是类 Vehicle 所必须提供的功能。通过使用子类来创造专业的 Vehicle 可产生一种更符合实际的模型；例如 Sports Car（运动车）和 Flatbed Truck（平板卡车）。只有类 Flatbed Truck 的对象需要提供“运送建材”的功能；运动车只需要提供“快速行驶”的功能。然而，这种更深层次的模型需要在设计期间更有洞察力，但是这一般很难做到。 除非设计者能确定地预知一组对象和类在未来都有哪些基本性质和行为，否则将不能设计好一个类的层级。程序最终需要增加行为实在是太频繁了，而系统的很多节段将需要重新设计（或重构）来以适应不同的新场景。系统往往会成长到一定程度然后变得非常僵化（变成屎山）。因为在设计者在最原始时候设计的基类，将逐渐成为一个简单的“错误”。 在基于原型的编程语言中，例如 JavaScript 消除了在类和对象之间的这种二元性。 不再有基于某种“类”的一个对象“实例”，在 JavaScript 中，可以复制一个现有的对象，并改变它。所以 Bob's car 可以通过制作现有的 Vehicle 对象的副本来创建，并增加“快速行驶”方法。用来制作副本的基本对象叫做“原型”。 “原型” 的实现也有两种模式 —— “委托原型” 和 “串接原型”。 JavaScript 是“委托原型”，即在本对象上没有的属性会一直沿着原型链向上寻找。 而“串接原型”类似于生物学上的分裂，属性和方法被原样复制。这样做的好处是对象的作者可以修改这份副本而无须担心对此父类的其他子类产生副作用，但是坏处是会浪费很多内存。 参考链接： wiki Self language

一：如果只是单纯的业务项目，dependencies 和 devDependencies 没有本质的区别 都是将依赖安装到 node_modules 中，然后打包构建。 二：项目开发好后需要作为 npm 包被别的项目引用 在发布 npm 包的时候，本身 dependencies 下的模块会作为依赖，一起被下载；devDependencies 下面的模块不会被下载； 三：peerDependencies 的作用 在开发插件的时候，例如开发 babel 插件的时候，插件本身需要依赖 babel 的核心库。 如果没有申明 peerDependencies，node_modules 的包结构可能是下面这样的情况： 1 2 3 4 5 6 7 8 9 10 . ├── helloWorld │ └── node_modules │ ├── babel │ ├── babel-plugin1 │ │ └── nodule_modules │ │ └── babel │ └── babel-plugin2 │ │ └── nodule_modules │ │ └── babel 从上面的依赖图可以看出，helloWorld 本身已经安装了一次 babel ，但是因为因为在 babel-plugin1 和 babel-plugin2 中的 dependencies 也声明了 babel，所以最后 babel 会被安装三次，有两次安装是冗余的。