标签: jdists 零碎代码
作者:王集鹄 2016年3月23日
这两天发生了一件在开源社区引起了不小的波澜的事:
一个开发者把自己的组件( left-pad )从 NPM
下架了,导致被依赖的其他组件(包括一些流行的工具,如: babel )无法安装。
看到这段 license 的日志,这事多半是早有预谋的。
当然我不是想要讨论这件事的是非,只是抛一个新的问题「如何管理零碎代码?」。
一些小小的代码片段:封装成组件有些浪费,配置文件都比代码多;不封装,到用的时候还得四处寻找复制粘贴。
比如这段格式化代码,功能非常简单,但也不想每次用都现敲代码。
function format(template, json) { return template.replace(/#/{(.*?)/}/g, function(all, key) { return json && (key in json) ? json[key] : ""; }); }
所以有很多人造轮子的时候,也有很多人在造螺丝钉。怎么管理螺丝钉一样的零碎代码,这篇文章介绍一种方案,抛砖引玉。
left-pad
组件并不复杂,有效代码也就十几行
function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch = ' '; len = len - str.length; while (++i < len) { str = ch + str; } return str; }
leftpad = require('left-pad') leftpad('foo', 5) // => " foo" leftpad('foobar', 6) // => "foobar" leftpad(1, 2, 0) // => "01"
function leftpad2(str, len, ch) { return new Array( Math.max(0, len - String(str).length + 1) ).join(ch === 0 ? 0 : (ch || ' ')) + str; }
零碎代码虽然可以随手写出,但会牺牲稳定性和复用性。
而过多的零碎代码组件化也会导致新的问题 -- 依赖臃肿,下游依赖成本提高。
NPM
依赖变化的风险 组件开发者难顾及 NPM
较深依赖层级和依赖增量变化。
我们享受开源组件生态福利同时,也得面对这种组件依赖发生变化的风险。
一个项目的依赖简单分为两类:
*「运行依赖」发布(publish)后的依赖,在运行期中使用*「开发依赖」发布前的依赖,在开发期中使用
如: NPM
package.json
声明
{ ... "dependencies": { // 运行依赖类 ... }, "devDependencies": { // 开发依赖类 ... }, ... }
安装一个组件时其「运行依赖」都会被下载,包括嵌套「运行依赖」。而「开发依赖」则不会被下载。
通常「开发依赖」都是放一些开发工具,比如构建、测试、规范检查等。那么它只能放工具吗?
不妨想象一种场景:「我的项目」依赖 animate.css
组件,但只用到其中一个文件 bounce.css
。
{ "name": "my-package", ... "dependencies": { // 运行依赖类 "animate.css": "^1.0.0" }, }
如果别的项目依赖「我的项目」,显然安装依赖的时候,逃离不了下载整个 animate.css
的命运。
于是我想到:把 animate.css
看作资源,只抽取 bounce.css
文件作为「我的项目」一部分一起发布。
实现也不复杂:构建时简单写一条复制命令。
{ "name": "my-package", ... "devDependencies": { // 运行依赖类 "animate.css": "^1.0.0" }, "scripts": { "dist": "cp node_modules/src/bounce.css vendor/bounce.css" // 构建复制 } ... }
那么别的项目依赖「我的项目」就不用再下载完整的 animate.css
,妈妈再也不用担心我的磁盘满了。
依赖有三个形式:
通常大家都关注第一种形式,下文重点介绍第三种形式:零碎代码依赖
造轮子和用轮子并不冲突,这是供需关系,共生走向繁荣。
现在已经很少见不需要构建过程项目,请大胆的使用构建工具,让开发期更自由自在。
jdists 是一款强大的代码块预处理工具
详情参考: jdists
jdists 使用一种类似 XML 标记的方式声明代码块。
如下代码,声明 tag 为 function
属性 name 为 encodeHTML
的代码片段 「来源 jstrs」
/*<function name="encodeHTML">*/ var htmlEncodeDict = { '"': 'quot', '<': 'lt', '>': 'gt', '&': 'amp', ' ': 'nbsp' }; /** * HTML编码 * @param {string} text 文本 '''</example>''' */ function encodeHTML(text) { return String(text).replace(/["<>& ]/g, function(all) { return '&' + htmlEncodeDict[all] + ';'; }); } /*</function>*/
引入时指定文件和依赖关系 「来源 jhtmls」
/*<jdists encoding="fndep" import="../node_modules/jstrs/jstrs.js" depend="encodeHTML">*/ var jstrs = require('jstrs'); var encodeHTML = jstrs.encodeHTML; /*</jdists>*/
/*<function name="encodeHTML">*/ var htmlEncodeDict = { ... }; ... function encodeHTML(text) { ... } /*</function>*/
截止我们已经完成第三种依赖形式的处理
代码块粒度的按需加载是动态类型语言的痛点,部分代码的生命周期难以捕获。使用 jdists 管理碎片代码依赖,目前还是一个不错的选择。