当前位置:首页 > 开发 > Web前端 > 前端 > 正文

前端工程化-公共模块的依赖和常用的工作流

发表于: 2015-02-02   作者:bee1314   来源:转载   浏览:
摘要: 题记: 一个人的项目,还有工程化的问题嘛?   我们在推进模块化和组件化的过程中,肯定会不断的沉淀出我们项目的模块和组件。对于这些沉淀出的模块和组件怎么管理?另外怎么依赖也是个问题? 你真的想这样嘛?   var BreadCrumb = require(‘../../../../uikit/breadcrumb’); //真心ugly。  
题记: 一个人的项目,还有工程化的问题嘛?
 
我们在推进模块化和组件化的过程中,肯定会不断的沉淀出我们项目的模块和组件。对于这些沉淀出的模块和组件怎么管理?另外怎么依赖也是个问题?
你真的想这样嘛?
 
var BreadCrumb = require(‘../../../../uikit/breadcrumb’); //真心ugly。
 
 
之前也尝试了很多的不同的解决方案,最终发现npm2.0的local module是最简单的,而且最符合模块化思维,我们可以把我们的模块按照功能进行划分。
比如:
uikit
 — breadcrumb.js
 — data-table.js
 — search-form.js
 ...
 util
     —ajax.js
     —pagenation.js
dialog.js
...
 
这样我们建立自己的模块,然后可以单独的维护,单独提交到git,然后通过npm install来进行本地安装。而且解决了依赖的问题。
对于上面的问题,我们可以简单这样玩:
var BreadCrumb = require(‘uikit/breadcrumb’);  //cool.正如我们期待的一般
 
但是通过我们项目多人协调的过程中,不爽的地方暴露出来,因为我们的公共模块很少,我们也在不断努力的在抽取,这样会导致我们公共的模块变化比较大,每次变动的时候都需要删除node_modules下面本地安装的uikit,然后再次npm install ….一次我忍了,二次一声叹息, 三次四次,你妹。。。是的,我懂的,我们都么有那么好的耐心。
 
那怎么办呢??
我们又想按照标准模块的做法,又想酷爽的解决标准模块的依赖问题。不得再次祭出webpack。真的懂我们开发者的心啊,么么哒!
 
由于node的横空出世,彻底解放了前端的生产力。大神们纷纷开始造了一个个轮子。比如想在前端建立前端的仓库,类似maven的仓库,比较有名的是bower(twitter出品),components(tj大神)。所以为了兼容这些轮子,webpack也做了相应的适配。正好这个适配也可以很好的解决上面我提到的我们想要解决的问题。
 
剩下的事情就变得异常的简单了, 一个配置项搞定。
 
在webpack中的配置文件中
module.exports = {
    entry: './index.js',
    output: {
        path: './build',
        filename: 'bundle.js'
    },
    resolve: {
        modulesDirectories: ['', 'uikit', 'node_modules’] //是的,webpack提供了多个模块目录的解析,通过这个解决本地模块的问题。
    }
};
 
for example:
➜  web-module  tree -L 2
.
├── build
│   └── bundle.js
├── index.js
├── package.json
├── uikit
│   ├── index.js
│   ├── package.json
│   └── utils.js
├── webpack.config.js
└── webpack.config.js~

2 directories, 8 files
 
➜  web-module  more uikit/utils.js
var _ = module.exports = {};

_.sayHello = function() {
  console.log('111say hello world...');
};
 
➜  web-module  more index.js
require('uikit/utils').sayHello();
 
打包,
webpack
 
运行
 
➜  web-module  node build/bundle.js
111say hello world...
 
这是你修改utils的方法,就不需要什么本地安装了。
 
 
在我们顺利的解决了模块化依赖的问题后,再来看看工作流的问题。
当我们在开发环境中,我们需要不停的自动的监控打包,然后在上线之前还要做做写优化比如压缩等。于是就需要不停的敲命令了。
 
开发环境,
webpack
webpack -d —-config webpack.config.js
webpack —watch
webpack -d —config webpack.config.js —watch
 
 
上线:
webpack -p —config webpack.production.js
 
敲出上述的命令也真是一件体力活。还好npm的run可以为我们定制一些的工作流。在package.json中配置,相应的参数即可。
{
  "
name": "web-module",
  "
version": "1.0.0",
  "
description": "web module",
  "
main": "index.js",
  "
scripts": {
    "
build": "webpack --config webpack.config.js -w",
    "
release": "webpack --config webpack.production.js",
    "
start": "webpack-dev-server --port 3000 --watch --process --color"
 
},
  "
keywords": [
    "
web",
    "
module"
 
],
  "
author": "hufeng",
  "
license": "ISC"
}
 
 
 
爽直的时刻:
npm run build #开发
npm run dist #正式环境打包
 
➜  web-module npm run build

> web-module@1.0.0 build /Users/bee1314/Code/eggs/web-module
> webpack --config webpack.config.js -w

Hash: a2f467270792fdfe044c
Version: webpack 1.4.15
Time: 77ms
    Asset  Size  Chunks             Chunk Names
bundle.js  1709       0  [emitted]  main
   [0] ./index.js 35 {0} [built]
   [1] ./uikit/utils.js 99 {0} [built]
 
 
➜  web-module npm start

> web-module@1.0.0 start /Users/bee1314/Code/eggs/web-module
> webpack-dev-server --port 3000 --watch --process --color

http://localhost:3000/webpack-dev-server/
webpack result is served from /
content is served from /Users/bee1314/Code/eggs/web-module
Hash: a2f467270792fdfe044c
Version: webpack 1.4.15
Time: 90ms
    Asset  Size  Chunks             Chunk Names
bundle.js  1709       0  [emitted]  main
chunk    {0} bundle.js (main) 134 [rendered]
    [0] ./index.js 35 {0} [built]
    [1] ./uikit/utils.js 99 {0} [built]
webpack: bundle is now VALID.
 
 

前端工程化-公共模块的依赖和常用的工作流

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S
重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S
重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S
我们的项目wecash4.0的前端构建考虑过用fis和grunt. 目录:   前期调研:fis vs grunt vs gulp?  
上两遍文章介绍了前端模块化开发(以seaJs为例)和前端自动化开发(以grunt为例)的流程,参见: ht
     前两篇中我们使用webpack完成了静态资源(css/js/img)等自动写入HTML模板中,同时还可以
1. 前端自动化工作流简介 每种项目都有自己特定的开发流程、工作流程。从需求分析、设计、编码、测
工作流系统相对一般的业务系统要复杂很多,所以把系统分解为多个有机组成部分:  外围工具 包括表
有的时候 人就是犯贱 东西每天回来研究一下 是没有结果的 但是在公司 坚定的研究 那结果就看的见了
这篇是承接《轻量级 Java 开发框架 设计》系列Blog文的后续文章。 如果你对 OSGi 有所了解,应该会
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号