技术档 | IT-北北报

用npm package-lock或shrinkwrap管理项目依赖

2018/05 22 09:05

管理node依赖是前端开发过程中会遇到的问题。

在Node.js项目开发的时候,我们也经常需要安装和升级对应的依赖。虽然 npm 以及语意化的版本号 (semantic versioning, semver) 让开发过程中依赖的获取和升级变得非常容易, 但不严格的版本号限制,也带来了版本号的不确定性。主要的问题可能有三个:

npm 建议使用 semver 的应用程序版本,但这也完全依赖第三方包遵守这一规则。如果你依赖于的包不遵循 semver ,或者依赖的包的新版本有重大更改(而你使用了 ^ 的宽泛版本安装),这潜在可能是会导致问题的。

另一个问题的出现是由于 npm 安装依赖的机制。npm 的安装包是有层次结构的,手动控制要安装的软件包的版本号可以实现,但是你只能在 package.json 使用精确的版本号控制你的直接依赖包,但那些多层以上的依赖就没办法控制了;一个第三方包不严谨的版本依赖生命可能破坏你的依赖管理。

在开发阶段执行得到的版本,和后续部署时得到的可能是不一致的,更不可控的是,你依赖的第三方包也有这样的情况会导致潜在的上线风险。

如果要控制上线的风险,我们就必需要解决这个问题,这时候,推荐使用 npm shrinkwrap 这个命令来解决问题。

这个命令在node 5版本之后改成了npm install的时候自动生成package-lock.json,其功能和npm-shrinkwrap.json是一致的,只不过shrinkwrap是手动生成的,在此请各位注意

关于package-lock.json/npm-shrinkwrap.json

npm install / shrinkwrap 可以按照当前项目 node_modules 目录内的安装包情况生成稳定的版本号描述。

比方说,有一个包 A

     {       
     "name": "A",       
     "version": "0.1.0",       
     "dependencies": {         
         "B": "<0.1.0"
       }
     }

还有一个包 B

     {       
     "name": "B",       
     "version": "0.0.1",       
     "dependencies": {         
         "C": "<0.1.0"
       }
     }

以及包 C

     {       
     "name": "C",       
     "version": "0.0.1"
     }

你的项目只依赖于 A,于是 npm install 会得到这样的目录结构

   A@0.1.0
     `-- B@0.0.1
         `-- C@0.0.1

这时候,B@0.0.2 发布了,这时候在一个新的环境下执行 npm install 将得到

 A@0.1.0
     `-- B@0.0.2
         `-- C@0.0.1

这时候两次安装得到的版本号就不一致了。而通过 install/shrinkwrap 命令,我们可以保证在所有环境下安装得到稳定的结果。

在项目引入新包的时候,或者 A 的开发者执行一下 npm install / shrinkwrap ,可以在项目根目录得到一个 package-lock.json/npm-shrinkwrap.json 文件。

这个文件内容如下

{  
     "name": "A",  
     "version": "0.1.0",  
     "dependencies": {    
         "B": {      
         "version": "0.0.1",      
         "dependencies": {        
         "C": {          
             "version": "0.0.1"
            }
      }
    }
  }
}

shrinkwrap 命令根据目前安装在node_modules的文件情况锁定依赖版本。在项目中执行 npm install 的时候,npm 会检查在根目录下有没有 package-lock.json/npm-shrinkwrap.json 文件,如果文件存在的话,npm 会使用它(而不是 package.json)来确定安装的各个包的版本号信息。

这样一来,在安装时候确定的所有版本信息会稳定的固化在 package-lock.json/npm-shrinkwrap.json 里。无论是A,B 和 C中的版本如何变化,或者它们的 package.json 文件如何修改,你始终能保证,在你项目中执行 npm install 的到的版本号时稳定的。

在开发中使用 shrinkwrap

在开发过程中,引入一个新包的流程如下

npm install PACKAGE_NAME@VERSION --save 获取特定版本的包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把依赖写入 package-lock.json/npm-shrinkwrap.json 文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述

升级一个包的流程应该是这样

npm outdated 获取项目所有依赖的更新信息

npm install PACKAGE_NAME@VERSION --save 获取特定版本的包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把依赖写入 package-lock.json/npm-shrinkwrap.json  文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json , package.json 描述

删除一个包的流程如下

npm uninstall PACKAGE_NAME --save 删除这个包

测试功能

测试功能正常后,执行 npm install/shrinkwrap 把更新的依赖写入 package-lock.json/npm-shrinkwrap.json  文件

在代码仓库中提交 package-lock.json/npm-shrinkwrap.json  , package.json 描述

比一般的安装多了一步手工生成 package-lock.json/npm-shrinkwrap.json  文件。在实际工作中,有时候我们会忘记这一步,导致上线时候没有获取到依赖包的特定版本。

小结

通过引入 package-lock.json/npm-shrinkwrap.json  文件,我们可以较好的管理项目的依赖关系,让上线变得更轻松。需要注意的是,尽管相关工具可以帮助你减化工作流程、可靠的分发依赖描述,但工具不能取代功能测试;每次升级依赖版本之后,我们仍然应该进行相关测试来确保项目能可靠的运行在该环境中。

Webkit内核-Render树

2017/03 22 17:03

RenderObject类

RenderObject是Render树的节点基础类,提供了一组公共的接口。

webkit0

 

在DOM树中,分为“可视节点”与“非可视节点”,比如”head”、“script”就是典型的“非可视节点”,而“body”、“div”、“canvas”等这些节点通常情况下为“可视节点”,这些节点会呈现一块区域。

对于“可视节点”,Webkit会为他们创建相应的RenderObject对象,一个RenderObject对象保存了为绘制DOM节点所需要的各种信息,如样式布局信息,元素颜色信息。页面上所有的节点构成了RenderObject树,这里要注意,RenderObject树节点和DOM节点不是一一对应关系,下边三个原则会被创建RenderObject节点:

  • DOM树的document节点;
  • DOM树中的“可视节点”;Webkit不会为非可视节点创建RenderObject节点;
  • 某些情况下Webkit匿名RenderObject节点,这些节点不应用于DOM树中的节点,典型的例子是RenderBlock节点。

 

 

匿名RenderBlock对象

 

CSS中有块级元素和内嵌(inline)元素之分。内嵌元素表现的是行布局形式,就是说这些元素以行进行显示。以 div 元素为例,如果设置属性 style 为 display:inline 时,则那是内嵌元素,那么它可能与前面的元素在同一行;如果该元素没有设置这个属性时,则是块级元素,那么在新的行里显示。

 

RenderBlock用来是用来表示块级元素, 为了处理上的方便,某些情况下需要建立匿名的RenderBlock对象,因为RenderBlock的子女必须都是内嵌的元素或者都是非内嵌的元素。所以,当它包含两种元素的时候,那么它会为相邻的内嵌元素创建一个块级RenderBlock节点,然后设置该节点为自己的子女并且设置这些内嵌元素为它的子女。

 

影子DOM

对于影子DOM,就是在DOM节点中还没有实际appendChild的节点,它可能是由createElement方法产生的内容,Javascript代码没有办法访问影子DOM,Webkit需要创建并渲染RenderObject对象,但是不需要把它转换为RenderObject节点。

 

Element类

 

RenderObject对象包含Element类,每个Element对象都会递归调用”attach”函数,该函数检查Element对象是否需要创建RenderObject节点,如果需要会使用NodeRenderingContext类来根据DOM节点的类型来创建RenderObject节点。

 

层次和RenderLayer对象

 

网页是可以分层的,这有俩点原因,一是方便网页开发者开发网页并设置网页层次,二是为了Webkit在处理时更便捷。

在某些类型的RenderObject节点或具有某些CSS样式的RenderObject节点出现时,Webkit就会为这些节点创建RenderLayer对象。RenderLayer创建的基本原则如下:

  • DOM树中Document节点对应的RenderView节点;
  • DOM树中的Document的子女节点,也就是HTML节点对应的RenderBlock节点;
  • 显示的指定CSS位置的RenderObject节点;
  • 有透明效果的RenderObject节点;
  • 节点有溢出(overflow)、alpha或反射等效果的RenderObject节点;
  • 使用Canvas 2D和3D(WebGL)技术的RenderObject节点;
  • Video节点对应的RenderObject节点。 

 

为了直观感受这三种树,如下给出了这三种树及其它们之间的对应关系:

webkit1

 

由此可见他们三者相互之间并不是一一对应的关系。

 

 

 

欢迎关注公众号,我们会不定期分享前沿技术、学习资料,在前端的道路上一起成长

qrcode_public

Webkit内核-节点渲染与JS执行原理

2017/03 09 09:03
webkit-logo

简介

在Webkit中,节点的渲染是由HTMLContructionSite类来完成的,该类包含一个DOM树的根节点HTMLDocument对象,其它的元素都是它的后代元素。

因为HTML文档的Tag标签是有开始结束标记的,所以构建过程使用栈结构是再合适不过的。HTMLContructionSite类中包含一个HTMLElementStack变量,它是一个保存元素节点的栈,在其中的元素就是当前有开始标记但还没有结束标记的的元素节点。

 

实例

一个HTML片段如:

 

<body><div><img></img></div></body>

解释器先做入栈操作,当解释到img元素的开始标记时,栈中的元素就是body、div和img,当遇到img的结束标记时,img出栈,img是div的子元素,当遇到div的结束标记时,div出栈,表明div和它的子女都已经处理完毕,以此类推。

根据DOM标准中的定义,节点有很多中类型、属性,所以他们有一个基础的父类 — Node类。

在Webkit中,DOM中的接口Interface对应于C++的类,Node类是其它类的基类,Node类实际上继承自EventTarget类,它表明Node类能够接受事件;同时,Node类还继承自另外一个关键的基类 — ScriptWrappable,这个与Javascript引擎密切相关。

webkit-nodeElement

Javascript的执行

在HTML解释器工作中,可能会有Javascript代码需要执行,它发生在将字符串解析成词语后创建节点时。这也是为什么全局执行的Javascript代码不能访问DOM树的原因,因为DOM在那个时间点还没有被创建出来。

Webkit将DOM树创建过程中需要执行的Javascript代码交给HTMLScriptRunner类来负责。原理就是利用Javascript引擎来执行Node节点中包含的代码。

因为JS代码可能会调用”document.write”等方法来修改文档结构,所以JS代码的执行会阻碍后面节点的创建,同时也会阻碍后边资源的下载,这也是JS阻塞加载的原理所在。

所以会有俩点建议:

1.将script标签加上”async”属性,说明这是一个可以异步执行的JS代码;

2.将script元素放在body的最后。(更推荐一些)

然而Webkit在这方面进行了一些优化,当遇到需要执行的JS代码时,Webkit会先暂停执行,使用预先扫描器HTMLPreloadScanner类扫描后面的词语。如果Webkit发现有其它资源需要加载,则使用资源加载器HTMLResourcePreloader类来请求资源,在这之后才执行JS代码。预先扫描并不会真实创建节点,所以速度较快。但是并不是所有渲染引擎都做了相关优化,所以第二种方式会更被推荐一些。

 

DOMContentLoaded

当Dom树创建完成后,Webkit触发了”DOMContentLoaded”事件,这就是我们熟悉的window.onload函数,此时一些代码才会在资源加载完成后执行,避免了DOM还没创建就出现操作的问题。

 

另外您可以关注我的公众号,更多技术文章将通过公众号进行分享

qrcode_public



无觅相关文章插件,快速提升流量