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

题记: 一个人的项目,还有工程化的问题嘛?

我们在推进模块化和组件化的过程中,肯定会不断的沉淀出我们项目的模块和组件。对于这些沉淀出的模块和组件怎么管理?另外怎么依赖也是个问题?

你真的想这样嘛?

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

> [email protected] 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

> [email protected] 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.

时间: 2024-11-10 01:19:30

【转】前端工程化-公共模块的依赖和常用的工作流的相关文章

前端引用公共html模块方案探索

最近临时一个负责公司官网的妹纸请假,于是临时接手了下官网的项目,官网都是静态页面,算是很简单的,但发现页面挺多,而每个页面总有部分是和其他页面一模一样的,比如页头.页尾等,这样就导致一个地方的修改要在其他N个页面手动重复的改下,当然,这是我无法忍受的,于是思考下怎样将公用的部分独立出来供调用. 开始想直接用js异步请求一个公用模块的页面即可,但考虑到官网的SEO问题,就放弃了,接着就想能否用webpack将代码分为开发环境和生产环境,在开发环境进行页面的拼接,完成后输出到生产环境,这样就不会影响

前端优化带来的思考,浅谈前端工程化

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

前端优化带来的思考,浅谈前端工程化【转】

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

前端工程化(摘抄)

目前来说,Web业务日益复杂化和多元化,前端开发已经由以WebPage模式为主转变为以WebApp模式为主了.现在随便找个前端项目,都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了.工程复杂了就会产生许多问题,比如:如何进行高效的多人协作?如何保证项目的可维护性?如何提高项目的开发质量?... 前端工程化是前端架构中重要的一环,就是为了解决上述各种效率方面的问题的.而前端工程本质上是软件工程的一种,因此我们应该从软件工程的角度来研究前端工程. 那么前端工程化需要考虑哪些因素?我认为前

58到家周俊鹏:webpack PK fis,实现前端工程化我更喜欢前者

责编:陈秋歌,关注前端开发领域,寻求报道或者投稿请发邮件chenqg#csdn.net. 欢迎加入"CSDN前端开发者"微信群,参与热点.难点技术交流.请加群主微信「Rachel_qg」,申请入群,务必注明「公司+职位」.另可申请加入CSDN前端开发QQ群:465281214. 2016年,SDCC(中国软件开发者大会)相继走进了上海.深圳.成都.杭州各地.11月18日-20日将在北京完美收官.作为大会的重要分专题,前端开发专题已邀请到58到家高级前端工程师周俊鹏担任大会讲师,现场将分

手机百度前端工程化之路

本文将围绕我半年来在移动前端工程化做的一些工作做的总结,主要从 localstorage缓存和版本号管理 , 模块化 , 静态资源渲染方式 三个方面总结手机百度前端一年内沉淀的解决方案,希望对大家移动开发有所帮助. 一年前存在的问题 可能因为之前项目节奏紧,人力不足原因,一部分phper承担了前端的工作,于是暴漏了一些问题. 粗暴的一刀切 从第一次在厂子写代码开始,就被前辈告诉移动页面,所以的静态资源都要内嵌,即写在script和style内,这样的好处是,网络情况不好的时候,减少http请求.

前端工程化浅析

在过去前端开发一直没有完善的一些代码处理等工具来富足开发,而nodejs火起来之后,很多基于node环境的工具诞生之后对前端开发造成了冲击,慢慢的,使用这些工具来完成项目的搭建和开发这样的方式被称为前端工程化. 使用工程化开发项目原因: 现在的项目不论是规模还是复杂度都有很大程度提高,所以如何快速搭建环境以及搞笑的代码管理,后期处理成为了衡量前端工程师技术的标准 工程化帮我们: 构造环境变得简单.自动化,代码的压缩合并,模块化,抽离都能一步完成,减少了后期处理成本. 现有的工程化工具: grun

四大维度解锁Webpack3.0前端工程化

四大维度解锁Webpack3.0前端工程化网盘地址:https://pan.baidu.com/s/1NBzFqMELoFxxvFtxp0YluQ 密码: pd36备用地址(腾讯微云):https://share.weiyun.com/50QY3pp 密码:d4uwwj 第1章 课程简介讲述课程背景,从前端开发的变化 到 前端工具的发展变化,介绍了课程内容,课程安排. 第2章 学习准备讲述模块化开发的思想.学习环境准备,webpack 的概况,版本更迭,核心概念等,为开始实践学习webpack

前端工程化系列[03]-Grunt构建工具的运转机制

在前端工程化系列[02]-Grunt构建工具的基本使用这篇文章中,已经对Grunt做了简单的介绍,此外,我们还知道了该如何来安装Grunt环境,以及使用一些常见的插件了,这篇文章主要介绍Grunt的核心组件和运转机制. Grunt是一套前端自动化构建工具,可以帮助我们简化开发中需要反复处理的任务,甚至可以实现自动构建等功能. Grunt拥有数量庞大的插件,这些插件能够帮助我们处理开发中遇到的绝大多数构建任务,比如代码的预编译.压缩.代码检查.单元测试等.但为什么在终端输入Grunt相关命令,就能