generate-jsmap

自动生成jsmap表及基础build.conf文件

由于目前模块加载器core.js中模块加载方式是通过key->value的形式，在开发过程中需要人工单独配置jsmap表，包含线上合并文件后的jsmap、线下开发的jsmap，以及打包配置文件也需要单独编写，整个过程比较繁琐，该工具主要解决以上问题。

主要功能点

1. 自动生成线上、开发环境的jsmap
2. 自动生成基础的build.conf打包配置
3. 实时监听项目文件变化，更新jsmap
4. 实时监听build.conf变化更新jsmap

总的来说，不需要单独手动维护jsmap表，而且对于大多数项目js打包要求，不需要手动编写build.conf配置文件。

具体使用示例

a. 安装

npm install generate-jsmap -g

b. 进入示例项目所有目录

这里准备了一个demo示例项目，该目录结构和我们项目基本一致

git clone https://github.com/zhangchen2397/dependency.git

cd ./dependency/demo

进入demo目录后，注意此时项目中没有build.conf文件，在index.jsp文件中，不管是线上还是线下jsmap都为空，且前后多我注释，如下：

 
<% if (!isTest) { %>
    <script type="text/javascript" id="file_config">
        var g_config = {
            //onlineJsmapStart
            jsmap: {},
            //onlineJsmapEnd
            testEnv: false,
            staticPath: '/infocdn/wap30/info_app/travel',
            serverDomain: 'http://infocdn.3g.qq.com/g/storeinc',
            buildType: 'project',
            storeInc: {
                'store': true,
                'inc': true,
                'debug': false
            }
        };
    </script>
<% } else { %>
    <script>
        var g_config = {
            //envJsmapStart
            jsmap: {},
            //envJsmapEnd
            testEnv: true,
            staticPath: '/infoapp/travel/touch',
            buildType: 'project',
            storeInc: {
                'store': false,
                'inc': false,
                'debug': true
            }
        };
    </script>
<% } %>

jsmap前后的注释不要删除，是用来自动生成jsmap的标记，其余的配置和之前一样写就行。这样后续开发或上线都不需要手动添加jsmap了。

c. 运行命令gd

gd [buildConfPath] [jsmapPath]

如目录结构和demo示例一致，即jsmap所在的index.jsp及build.conf所在的目录都在项目的根目录下，直接运行gd命令即可：

//在demo目录下直接运行`gd`命令

gd

运行后发现在项目根目录下自动生成了build.conf配置文件，合并的基本规则为除pages目录下的文件合并为一个包，pages下的文件单独打包，线上大部分项目也都是这种合并规则，这种情况下，所有的开发过程无需关心build.conf及jsmap了。

如项目打包比较复杂，直接修改build.conf，jsmap会同步自动更新

d. 更多使用示例

如jsmap不在index.jsp中，或build.conf不在项目所在目录下，通过gd参数也可以单独指定

gd ./conf/build.conf ./mt_config.jsp

当build.conf有修改或有增加删除js文件时，终端实时提示生成jsmap是否成功或失败，如：

注：路径均相对于运行当前命令所在目录。

更多todo list (YY)

这个需要组内一起讨论，如此前会上所讨论的，将公共模块放在svn独立的common路径下，和项目开发路径平级存放，如下：

project
    ├── common .......................  通用模块目录结构
    |     ├── base .................... MT基础库
    |     |     ├── core
    |     |     ├── pm
    |     |     └── storeinc
    |     ├── lib ..................... 底层库
    |     |     ├── zepto
    |     |     ├── fastclick
    |     |     └── iscroll
    |     ├── vendor .................. 第三方开源组件
    |     |     ├── swipe
    |     |     ├── flipsnap
    |     |     └── tab
    |     └── mod ..................... 手腾独立开发组件
    |           ├── comment
    |           ├── dialog
    |           └── tips
    |       
    ├── travel ......................... 旅游项目目录结构
    |     ├── js
    |     |     ├── mod ................ 当前项目通用模块
    |     |     |    ├── fullimg
    |     |     |    ├── lazyload
    |     |     |    └── more
    |     |     └── page ............... 页面级运行时文件
    |     |          ├── home
    |     |          ├── list
    |     |          └── more
    |     ├── index.jsp
    |     └── build.conf
    |
    └── movie

有了以上这种规范的目录结构后，借助模块加载器可以非常方便的分析依赖，而且在引用一个通用组件时，不需要关注它所依赖的其他组件，直接引用即可，也无需通过svn external将通用模块外链到当前项目中来，如：

define( 'page/home', [ 
    'common:lib/zepto',  //引入common模块下的 lib/zepto
    'common:mod/tips',   //引入common模块下的 mod/tips
    'mod/lazyload'       //引入当前模块下的 mod/lazyload
], function( $, tips, lazyload ) {
    console.log( $ );
    console.log( tips );
    console.log( lazyload );
} );

以上仅是个人意见和想法，具体还需要组内一起讨论。