island205 / bodule Goto Github PK

Node 社区三种我尝试过的打包方案, 都遵循 CommonJS 规范,
打包代码当中生成一遍 require 机制, 完成重用, 三种方案是

• Component

https://github.com/component/component
http://component.io/

Usage: component <command> [options]

Options:

  -h, --help     output usage information
  -V, --version  output the version number

Commands:

  install [name ...]      install one or more components
  create [dir]            create a component skeleton
  search [query]          search with the given query
  convert <file ...>      convert html files to js modules
  info <name> [prop]      output json component information
  changes <name>          output changelog contents
  docs <name>             output readme contents
  wiki                    open the components list wiki page
  build                   build the component
  ls                      list installed components

• Browserify

https://github.com/substack/node-browserify
http://browserify.org/

Usage: browserify [entry files] {OPTIONS}

Standard Options:

    --outfile, -o  Write the browserify bundle to this file.
                   If unspecified, browserify prints to stdout.

    --require, -r  A module name or file to bundle.require()
                   Optionally use a colon separator to set the target.

      --entry, -e  An entry point of your app

     --ignore, -i  Omit a file from the output bundle.

   --external, -x  Reference a file from another bundle.

  --transform, -t  Use a transform module on top-level files.

    --command, -c  Use a transform command on top-level files.

  --standalone -s  Generate a UMD bundle for the supplied export name.
                   This bundle works with other module systems and sets the name
                   given as a window global if no module system is found.

       --debug -d  Enable source maps that allow you to debug your files
                   separately.

       --help, -h  Show this message

For advanced options, type `browserify help advanced`.

Specify a parameter.

• commonjs-everywhere

https://github.com/michaelficarra/commonjs-everywhere

$ bin/cjsify --help

  Usage: cjsify OPT* path/to/entry-file.ext OPT*

  -m, --minify            minify output
  -o, --output FILE       output to FILE instead of stdout
  -r, --root DIR          unqualified requires are relative to DIR (default: cwd)
  -v, --verbose           verbose output sent to stderr
  -w, --watch             watch input files/dependencies for changes and rebuild bundle
  -x, --export NAME       export the given entry module as NAME
  --deps                  do not bundle; just list the files that would be bundled
  --help                  display this help message
  --ignore-missing        continue without error when dependency resolution fails
  --node                  include process object; emulate node environment (default: on)
  --source-map-file FILE  output a source map to FILE

关于 browserify 和 cjsify 我最近有尝试, 在另一个 Issue 里写了
coffee-js/languages#55
当研究的话还不深入, 我大致罗列一些我了解的方面作为对比

• 模块

Component 用 Github 作为仓库, 代码都上传到 Github,
深层的递归依赖似乎是没有的, 对于前端不太需要
Component 的模块里除了 JS 代码还有 CSS 和 HTML

browserify 和 cjsify 使用的是 NPM 的模块依赖算法
也大量引用 Node 的模块, 一些 Node 上的模块有对应的浏览器版本实现
浏览器模块比如 Backbone 直接是可用的 browserify 模块

Node 模块的一个问题是打包会引入太多的代码, 浏览器有网络的限制
因此 Component 的观点是尽量用小的模块, 体现在模块上了
而 browserify 升级 2.0 时似乎也有做这方面工作, 其他不清楚
因此 jQuery 之类大型的模块, 在社区有排斥的声音

• CoffeeScript 和 SourceMap

必不可少的 coffee.. Component 没提到什么支持的, 大概没
browserify 有个 coffeeify 插件, 可以实现 coffee 代码的编译
前两位作者都是不喜欢 coffee 的, 只有后一位 coffee 2.0 作者亲近
cjsify 对 coffee 的支持是最好的, 体验和 Node 里 coffee 几乎一致

注意区别的是 coffeeify 和 cjsify 支持 coffee 的方式不同
coffeeify 是插件, 而 cjsify 直接内置了 coffee-script-redux 模块
内置模块的话, 用的 coffee 语法就是 2.0 beta 的语法了, 有不同
不过用 coffee 的人毕竟不是绝大多数, 也不能算多开心

SourceMap 从我写 coffee 的体验看是 cjsify 相对最好
browserify 用的是 coffee v1.6.2 实现的 SourceMap, 问题也带着了
Component 我就到现在的没用上 SourceMap, 也不指望了

• 对我而言的方便

cjsify 的 watch 功能延续了 Node 平台 coffee 的好处, 必需的
另外两者当前版本没有看到, browserify 也许以后会有

编译报错的感觉都不好, 只有模块不存在的提示是清晰的
这些似乎通过匹配源码字符串来查找依赖进行打包, 因此字符串是必要的
另外在处理路径上我想也不是很清晰, 我用 cjsify 发现必须根目录一致

考虑到玩 Node 的方便, 我个人倾向这类前端解决方案
不清楚到大项目要考虑哪些问题, 所以这里也都没有对比过

• 浏览器端模块化的执行结构
• 语法结构
• 实现方式

欢迎补充

Welcome

This is a group for discussing module for browser.

open issue for your topic

我没有参与过学校外面的项目, 说的有局限... 纳入考虑吧,,
另外看英文老长的 AMD CMD 争论我也是不得要领...

今天早上是 CoffeeScript 更新 1.6.1 开始支持 SourceMaps
http://coffeescript.org/#source-maps
以前是 CoffeeScript-Redux 有支持 SourceMaps, 当时真没当回事
http://ryanflorence.com/2012/coffeescript-source-maps/
另外一个是前些天看到的 *-Redux 项目作者的另一个项目
https://github.com/michaelficarra/commonjs-everywhere
当时看介绍只是把 CommonJS 模块编译到单个 JS 文件, 并且保持文件不破坏什么的
之前有 Browserify 这么做, Component 项目也是这么做的
我冒失地发了一个帖, 至少我觉得会是一种可能...
http://cnodejs.org/topic/5135c32bdf9e9fcc581a66b5
像之前那个神一样的讨论里说的, 打包后的代码破坏了各种调试信息
dexteryy/OzJS#10
而不打包就有加载速度和兼容性的问题

SourceMap 本来发明就是为解决这个场景里的问题, 只是我没察觉到
在 commonjs-everywhere README 里给的例子却很清晰了
压缩后前端的代码, 在调试的控制台里还是精确定位 .js .coffee 的文件
当这成熟了, Component 的方案在调试上问题解决了, 上手就很轻松
搜索 Component 项目, 也看到提及 SourceMap 支持的, 只是文档没找到
componentjs/component#85
再往后也会有 Grunt 的插件提供更多编译的方便

我做一些设想, 如果后端能直接写 require, 我个人非常倾向用简洁的 require
类似地, 采用这套方案的人人会增多, 意味着又一个 NPM 类似的社区
Component 现在模块已经不少, 模块列表改来改去也非常清晰
http://component.io/
那么其他的 AMD CMD 方案会不会是更少人会去用, 而形成一家独大?
至少 RequireJS SeaJS 社区本来不如 Component 大
我主要是有这样的想法, 不知道几种技术上的优缺点会不会结果变成那样?

一、 GNU 风格的版本号命名格式 :
主版本号 . 子版本号 . 修正版本号 . 编译版本号
英文对照 : Major_Version_Number.Minor_Version_Number.Revision_Number.Build_Number

二、 GNU 风格的版本号管理策略：

1．项目初版本时 , 版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0, 如果你为人很低调 , 我想你会选择那个主版本号为 0 的方式 ;

2．当项目在进行了局部修改或 bug 修正时 , 主版本号和子版本号都不变 , 修正版本号加 1;

1. 当项目在原有的基础上增加了部分功能时 , 主版本号不变 , 子版本号加 1, 修正版本号复位为 0, 因而可以被忽略掉 ;

   4．当项目在进行了重大修改或局部修正累积较多 , 而导致项目整体发生全局变化时 , 主版本号加 1;

   5．另外 , 编译版本号一般是编译器在编译过程中自动生成的 , 我们只定义其格式 , 并不进行人为控制 .

source:http://blog.sina.com.cn/s/blog_61fd0d590100etrh.html

实际上coffee-script的代码可以运行在浏览器端，只是通过main指定的是给node使用的，切会用到一些核心模块。

Bodule，又一个Node模块Browser化的工具！

目标

给Node的模块文件加上Brower Loader的Wrapper，编译后的代码输出到指定目录。

示例

目录中有main.js、spinning.js、package.json，其中main.js内容如下：

    // 通过 require 引入依赖
    var $ = require('jquery');
    var Spinning = require('./spinning');

    // 通过 exports 对外提供接口
    exports.doSomething = ...

    // 或者通过 module.exports 提供整个接口
    module.exports = ...

使用Bodule，运行 bodule main.js --loader=seajs，会被打包为：

// 所有模块都通过 define 来定义
define(function(require, exports, module) {

  // 通过 require 引入依赖
  var $ = require('[email protected]');
  var Spinning = require('./spinning');

  // 通过 exports 对外提供接口
  exports.doSomething = ...

  // 或者通过 module.exports 提供整个接口
  module.exports = ...

});

其中，@1.5.1是运行npm install之后所采用的jquery版本。

API

@jiyinyiyong 继续我们在coffee-js/languages#50 (comment) 的话题。

现在绝大多数的加载器都是异步加载的，所以需要有wrapper，你想实现的是完全同步加载。即require('module')是同步的，no callback。

而目前加载器之所以异步都是为了性能；

要想实现同步的require要么使用xhr同步加载代码，或者干脆直接把需要的代码打包起来，noloader就是这么做的，包括component也是这么做的。

但是是不是可以这样，require既可以是同步的，也可以是异步的。

想想node.js中的文件读取，有同步，也有异步。node中的require引入其他模块的时候，自然也是需要读取模块文件的，所以使用的是readFileSync，而不是readFile，如果node,js使用readFile的话，require也可以是异步的。

例如：

require('fs', function (fs) {
    // do with fs module
})

• 在node中，同步的require对应readFileSync，异步的对应readFile;
• 在浏览器中，同步的require对应同步的xhr或者打包源码等等，异步的对应异步的xhr，或者script tag等。

同步或者异步的require应该并存，有的代码可以打包，有的代码可以异步加载。

最后同步的require，node-webkit项目已经实现了，直接把node跑在webkit中。

最近百度发布了它们的前端集成解决方案——F.I.S

这是我的看法（转自知乎）：

fis是一个大集合，只有这样级别的公司才需要使用这种级别的工具来解决问题，我觉得包括以下几个方面：

1. 静态资源编译（压缩、md5等等）
2. 静态资源引用路径替换（在此之上做了扩展“三种语言能力”）
3. 资源打包，map.json是关键，扩展后端模板语言，实现前后端架构；
4. 编译插件
5. 组件资源共享
   Yeoman有1、2的功能点；3中map.json的信息也可以放到数据库中，扩展的模板语言也可以到数据库中读取；4有点类似grunt；5是npm。

大家交流交流呀

我发现 SourceMap 里的 @ sourceURL 可以对 eval 的代码生成报错

<script src="require.js" entry="main.js" defer></script>

于是在支持 SourceMap 的 Chrome 就能按行报错了 tiye/banyan@89fb3c6
不过这几天在想, 毕竟前端代码没有 sandbox, 只有 <iframe> 才能提供
我觉得 <iframe> 可能是不错的模块化方案
<iframe> 之间相互间的消息只有 .postMessage, 不知道能不能写出好的封装