写点什么

NodeJs 深入浅出之旅:包与 NPM 🌛

用户头像
空城机
关注
发布于: 1 小时前
NodeJs深入浅出之旅:包与NPM 🌛

包与 NPM

Node 组织了自身的核心模块,也使得第三方文件模块可以有序的编写和使用。


但是在第三方模块中,模块与模块之间仍然是散列在各地的,相互之间不能直接引用


所以在模块外,包和 NPM 是将模块联系起来的机制。


  • 包组织模块示意图



CommonJS 的包规范定义其实也很简单,由包结构和包描述文件两部分组成。

包结构

用于组织包中的各种文件,是一个存档文件,即一个目录直接打包为.zip 或 tar.gz 格式的文件。


符合规范的包目录:

  • package.json: 包描述文件

  • bin: 用于存放可执行二进制文件的目录

  • lib: 用于存放 JavaScript 代码的目录

  • doc: 用于存放文档的目录

  • test: 用于存放单元测试用例的代码

package.json 包描述文件

NPM 所有行为都与包描述文件的字段息息相关


一些字段:

  • name: 包名。 规范定义需要用小写的字母和数字组成,不允许出现空格。 包名必须是唯一的,以免对外公布时产生重名冲突

  • description: 包简介

  • version: 版本号,关于其介绍在《Node.js学习(一)——简介》也有提及

  • keywords: 关键字数组, NPM 中主要用来作分类搜索。

  • maintainers: 包维护者列表。 每个维护者由name、email和web这 3 个属性组成。 NPM 通过这个属性进行权限认证。

  • 格式:

"maintainers":[{ "name":"kongchengji", "email":"111@.com", "web":"[http:](https://blog.csdn.net/qq_36171287)" }]
复制代码


  • contributors: 贡献者列表,格式与维护者列表相同

  • bugs: 一个可以反馈 bug 的网页地址或邮件地址

  • licenses: 当前包所使用的许可证列表,表示包在哪些许可证下使用


  • 格式:

     "licenses":[{ "type": "GPLv2", "url":"" }]     // 或者     "license": "ISC"
复制代码


  • repositories: 托管源代码的位置列表,表明可以通过哪些方式和地址访问包源代码。


  • 格式:

    "repository": {    "type": "git",    "url": "git+https://github.com/kongchengji/UiSelfMade.git"  },
复制代码


  • dependencies: 使用当前包所需要依赖的包列表。 这个属性非常重要

  • homepage: 当前包的网站地址

  • os: 操作系统支持列表, 如果列表为空,则不对操作系统做任何假设

  • cpi: CPU 架构支持列表

  • engine:支持的 JavaScript 引擎列表

  • directories:包目录说明

  • implements: 实施规范的列表。 标志当前包实现了 CommonJS 哪些规范

  • scripts: 脚本说明对象。 主要用于被包管理器用来安装、编译、测试和卸载包


  • 格式:

        "scripts": {            "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",            "start": "npm run dev",            "lint": "eslint --ext .js,.vue src",            "build": "node build/build.js"        },
复制代码


NPM 与包规范区别在于多了四个字段:


  • author: 包作者 :ok_man:

  • bin: 一些包作者希望包可以作为命令行工具使用。

  • main: 模块引入包时,会有限检查这个字段,并将其作为包中其余模块的入口模块。 如果不存在,require 会查找包目录下的 index.js、index.node、index.json 作为默认入口

  • devDependencies: 一些模块只在开发时需要依赖。

  • devDependencies:开发环境使用 dependencies:生产环境使用



前后端共用模块

JavaScript 在 Node 出现后,有一项优势 --> 一些模块可以在前后端实现共用。


但是前后端上始终还是有一些差别的 :sweat_drops:

前后端模块侧重点

前后端 JavaScript 分别搁置在 HTPP 的两端,扮演的角色并不同。


浏览器端的 JavaScript 需要经历从同一个服务器端分发到多个客户端执行,瓶颈是带宽,从网络加载代码服务器端的 JavaScript 是相同代码需要多次执行,瓶颈是 CPU 和内存等资源,从磁盘中加载


在前端 JavaScript 中,主要还是应用 AMD 规范


CommonJS 并不完全适用于前端 JavaScript,比如 Node 的模块引入基本是同步的,但是前端引入如果使用同步引入,UI 在初始化过程中需要花费很多时间等待脚本加载完成。

AMD 规范

AMD 规范 是CommonJS规范的一个延伸,全称:Asynchronous Module Definition。是异步模块定义


模块定义:define(id?, dependencies?, factory);id 是模块的名字,它是可选的参数。

dependencies 指定了所要依赖的模块列表,它是一个数组,也是可选的参数

AMD 需要在声明模块时指定所有的依赖,通过形参传递依赖到模块内容中:

define(['./a', './b'], function (dep1, dep2) {    a.doSomethimg()    b.doSomething()});
复制代码

CMD 规范

与 AMD 规范相对的还有 CMD 规范,全称:Common Module Definition。是公共模块定义


这是由国内的玉伯(也是一位大佬)提出的


模块定义:define(factory)


CMD 支持动态引入:

define(function(require, exports, module) {    var a=require('./a')    a.doSomethimg()    var b=require('./b')    b.doSomething()})
复制代码


在需要依赖模块时, 随时调用 require()引入即可


  • CMD 推崇依赖就近; AMD 推崇依赖前置

  • CMD 是延迟执行; AMD 是提前执行

  • CMD 性能好,因为只有用户需要的时候才执行; AMD 用户体验好,因为没有延迟,依赖模块提前执行了


AMD 和 CMD 最大的区别是对依赖模块的执行时机处理不同

兼容多种模块规范

创建一个 hello 方法,让 hello 方法能在不同运行环境中运行,兼容 Node、AMD、CMD 和常见浏览器


  • 匿名函数前加一个;是个好习惯 name 是方法名,definition 是方法体

  • 通过typeof检测环境是否为 AMD 或 CMD 还是 Node 环境

  • 可以将模块执行结果挂载在 window 变量中,这样可以直接调用


// 匿名函数前加一个;是个好习惯  name是方法名,definition是方法体;(function (name, definition) {    //检查环境是否是AMD或CMD    var hasDefine = typeof define === 'function',    // 检查环境是否为Node    hasExports = typeof module !== 'undefined' && mudule.exports;
if(hasDefine) { define(definition); } else if (hasExports) { module.exports = definition(); } else { // 将模块的执行结果挂在window变量中,在浏览器中this指向window对象 this[name] = definition(); }})('hello', function () { var hello = function () { console.log('hello'); } return hello;});
复制代码


发布于: 1 小时前阅读数: 5
用户头像

空城机

关注

曾经沧海难为水,只是当时已惘然 2021.03.22 加入

业余作者,在线水文 主要干前端的活,业余会学学python 欢迎各位关注,互相学习,互相进步

评论

发布
暂无评论
NodeJs深入浅出之旅:包与NPM 🌛