开始的开始，前端项目很简单，html放外面，然后新建一个css和js文件夹，看起来很清晰。
随着时间推进，项目变大，问题开始一一出现了：
- html 太多，找起来麻烦
- css 和 js 需要压缩
- css 和 js需要发布到 CDN
- 开始只简单依赖一个jQuery，后来发现依赖的插件越来越多，不好更新维护
- html 里面怎么实现公共一个头
- js和css包含大量重复代码，怎么重构项目
- 前端如何把代码交付给后端填模板代码
很多公司面对这些问题都有了自己的方案，Node 因为语言也是JS，成了很多公司的首选。
相关的热门框架有grunt,gulp,webpack,bower等等。
愿意读文档的人早以用上这些新奇玩意儿并且解决了大量前端问题。
虽然工具很多，但对于很多新团队来说，如何完美地规划项目却仍然是一道坎。
他们不知道应该在何时，如何使用这些工具。前端项目的设计可以非常随意，正是这些随意，让很多人在选择中开始迷茫。
本文将提供一个趋于完美的前端项目结构规划方案，希望能为各位在重构前端项目时提供帮助。
一个规划方案，并不只是定义文件怎么放，文件怎么命名，而更重要的是包含实现整个流程的工具，如果没有工具支持，所有方案都是扯淡。
前端项目结构
根目录 |- assets: 存放所有js和css等，这些资源可能发布到 CDN | |- images: 存放所有 CSS 样式需要的背景图片 | |- fonts: 存放所有 CSS 样式需要的字体 | |- styles: 存放所有CSS | | |- common: 存放公共的 CSS 代码 | |- scripts: 存放所有 JS | | |- common: 存放公共的 JS 代码 |- include: 存放所有公共的 HTML 头尾片段 |- images: 存放前景图片和flash |- libs: 存放前端所需的第三方类库 |- views: 如果使用了后端 MVC 框架，则页面放在这里。 |- _my: 存放开发者自己需要的文件，这个文件夹应该被 GIT 和 SVN 忽略掉。 |- page1.html 存放最终的前端页面，如果使用了 MVC 框架则不需要。
HTML 文档结构
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>标题</title>
<!-- #include virtual="/include/header.inc" -->
<link rel="stylesheet" type="text/css" href="assets/styles/common/blog.css" />
<link rel="stylesheet" type="text/css" href="assets/styles/page2.css" />
</head>
<body>
<!-- #include virtual="/include/body.inc" -->
内容
<!-- #include virtual="/include/footer.inc" -->
<script type="text/javascript" src="assets/scripts/common/blog.js"></script>
<script type="text/javascript" src="assets/scripts/page2.js"></script>
<!-- #include virtual="/include/stat.inc" -->
</body>
</html>
/include/header.inc:
<meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1" />
<meta name="viewport" content="width=device-width, initial-scale=1, minimal-ui, maximum-scale=1, user-scalable=no" />
<meta name="apple-itunes-app" content="app-id, app-argument=">
<meta name="description" content="" />
<meta name="keywords" content="" />
<link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="" />
<link rel="shortcut icon" href="favicon.ico" />
<link rel="apple-touch-icon" href="favicon.png">
<link rel="stylesheet" type="text/css" href="../assets/styles/common/common.css" />
/include/body.inc:
这里可以放一些全站公用的页头，比如需要为全站加一个紧急通知的 banner，可以加在这里。
<!--[if lt IE 9]> <div role="alert">你的浏览器实在<strong>太太太太太太旧了</strong>，放学别走，升级完浏览器再说 <a target="_blank" class="alert-link" href="http://browsehappy.com">立即升级</a> </div> <![endif]-->
/include/footer.inc:
这里可以放一些全站公用的页脚，比如版权声明之类。
<div>版权所有 @copy; 2015 xuld</div> <script type="text/javascript" src="assets/scripts/common/common.js"></script>
/include/stat.inc:
这里可以放一些网站统计代码。
<!-- 在这里添加网站统计代码 -->
其它文件
如果项目里还有公共的侧边栏、广告位等，也可以自行在 include 添加其它文件。
如果一个网站需要有多种不同版权声明，可以分别做一个 footer-full.inc 和 footer-simple.inc，然后公共包含：footer-common.inc。
静态资源引用
如果项目里需要使用 less/sass/coffee 等技术，则可以直接引用这些文件。发布时，发布工具完成这些事情：
1. 编译 less/sass/coffee 文件，转换为对应的 css/js 文件。
2. 更新 HTML 文件里的资源引用地址，引用生成好的 css/js 文件。
3. 为这些资源文件引用地址添加时间戳。
4. 如果项目使用了 CDN，则发布工具应该自动上传文件到 CDN，并更改文件里的路径为 CDN 的地址。
发布前：
<link rel="stylesheet" type="text/css" href="../assets/styles/page1.less" />
发布后：
<link rel="stylesheet" type="text/css" href="http://cdn.com/project/assets/styles/page1.css?_=md5" />
时间戳问题
静态文件由于存在缓存，每次发布如果保持路径不变，很容易导致页面不更新。有三种方案：
- 为路径加上 ?_=md5
- 更新文件名为 page1_md5.js
- 复制到名为 20151021 的文件夹
个人建议使用方案1，因为改动量少，不易出错。但如果CDN不支持，可以采用其它方案。
脚本和样式
如果项目中，一个人专门负责 css,一个人专门负责 js,一个人专门负责将 html 转换为后台代码，则上述文件夹结构是比较合理的。
如果是同一个人负责css和js，则建议不区分 styles 和 scripts 文件夹，直接放在 assets 目录。
如果连转换html 到后台代码都是同一个人，则建议将 css 和 js 直接写在页面里，发布工具负责提取出来：
<style __dest="assets/styles/page1.css"> /* CSS 代码 */ </style>
公共代码依赖
每个HTML页面，都必须引3个js和3个css，分别是：
- 全站公用的 js：common/common.js
- 全项目（或类似页面，比如列表页、详情页）公用的js：common/blog.js
- 页面私有的js：common/page1.js
css 和 js处理方式一致，且一一对应。
个别页面可以引入一些外部的js和css，比如 editor.js 这种比较大的文件。但原则上每个文件最多只能引 5个js和5个css。需要引的文件多时则需要打包合并。
出于性能考虑，有时候可以将页面私有的js和css直接内联到页面。
<script src="assets/page1.js?__inline"></script>
模块化组件
所有可复用组件、第三方框架都放在 libs，libs 文件发布时会被忽略掉，项目里也不能直接引用 libs 下的代码。
如果需要引用一个组件，有三种方案：
- 简单的文件包含
- 基于 CommonJS 模块化方案
- 基于其它模块化方案
简单的文件包含
如果项目较小，并不需要太大模块化东西，直接使用文件包含是最方便的：
common.js
// #include /libs/3rdlibs/jquery-2.1.0.js // #include /libs/3rdlibs/jquery.mobile.js // 其它项目需要的公共代码
发布工具会处理 #include 。
CommonJS 模块化方案
var $ = require(‘libs/3rdlibs/jquery‘);
发布后，CommonJs 模块会被转换为标准的 AMD 模块。
打包问题
假设一个页面需要引用 common.js 和 page1.js ，而这2个js又分别引用了 libs 下的若干个组件（可能有重复）
那么 page1.js 可以添加如下指令排除掉 common.js 所引入的文件
// #exclude common.js var $ = require(‘libs/3rdlibs/jquery‘);
最后生成的代码，page1.js 将包含所有所需的模块，并删除了 common.js 包含的模块。
项目发布和调试
以上所介绍的代码方案是不能直接在浏览器运行的，这里有三个方案可以实现本文所描述的各个功能：
- 在浏览器执行 JS 实现上文所描述的所有功能。优点：兼容性好，缺点：效率低。
- 监听文件改变，文件保存后就解析以上指令并生成文件。优点：兼容性好，处理方便，缺点：不稳定。
- 自定义服务器，这个服务器在请求时自动完成生成任务。优点：效率高且稳定，缺点：需要定制服务器，且只在开发时使用。
其它工具支持
占位图
对应经常切页面的哥们，占位图是非常有用的。
<img src="@100x100.jpg">
Ajax 接口模拟
a.njs:
writeJsonp({
a: 1
});
写在最后
本文所描述的是一种建议的做法，也是一个发布工具所需要提供的功能。每个团队可以针对自己的需求做一些个别的定制。本文所提到的示例都是以 tpack 为原型书写的。不同的工具会有稍微不同的写法。但是其解决的问题是一样的。