从零做一个开源项

开源包含了那些

源码
文档，如二次开发文档和用户使用文档
开发环境，告诉二次开发者如何搭建和运行代码
**允许他人贡献代码**，而不是仅仅给别人阅读源码的权限
**问题**，用户提问，维护者答复，问题共享（而不是私聊）
**问题列表和升级计划**，记录当前问题，以及何时解决、何时升级

其他配套设施

官网，如 wangEditor 官网
文档，可以和官网整合在一起
问答社区，wangEditor 的问题社区就用了 github issue
及时交流社区，即 QQ 群、微信群

注册账号

创建 github 仓库(协议选 mit，选 add README.md)
https://github.com/cxvh/is-visit-google.git

注册 npmjs 账号

开发环境

node 环境

规范版本号

打开 package.json 文件，将版本号定义为 “version”: “0.0.1” 。以后我们每次正式提交代码，版本号都不一样。版本号分三级，分别为：
一级，重构版本
二级，重大功能改进
三级，小升级或者 bug 修复

为何从 0.0.1 开始？因为 0.x.x 可以认为是非正式版本、测试版，而从 1.x.x 开始，就是正式发布的版本了。

规范一级目录

项目的一级目录要提前规范好，最起码一些常用的目录要提前订好留用，不能乱来。例如：
src - 源代码
release - 发布结果
test - 单元测试用例
doc - 文档
example - 示例

1 2	npm init mkdir src release test doc example

构建工具

安装插件

1
2
3

npm i babel-loader @babel/core @babel/preset-env babel-register jsxobj babel-preset-es2015 webpack webpack-cli --save-dev --registry=https://registry.npm.taobao.org
npm i http-server -g # mac >> sudo npm i http-server -g
npm i gitbook-cli -g # mac >> sudo npm i gitbook-cli -g

项目根目录下创建 webpack.config.js 文件，内容如

const path=require('path')
module.exports={
    entry:'./src/index.js',
    mode:'development',
    output:{
        //hash指定6位
        filename:'[name]_bundle.js',
        path:path.join(__dirname,'release'),
    }
}

package.json 新增

{
  "scripts": {
    "start": "http-server -p 3000",
    "build": "webpack --config webpack.config.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

运行示例

release 的内容已经发布出来了，还要运行起来，最简单的方式，在 example 创建 test.html，然后引用 release 的内容。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>example</title>
  </head>
  <body>
    <p>example</p>
    <script src="../release/bundle.js"></script>
  </body>
</html>

运行 npm run example ，浏览器访问

规范 git 分支

至少要存在两个分支，master 和 dev ， dev 是开发中的代码。当然，你可以规范更多的分支，例如 next fix-bug 等，但是注意一个原则 —— 用不到的就先不要规划。

完善 README.md

README.md 是开源项目的一张脸，用户的第一印象。必须包含以下内容：

产品简介（此处要突出特点，打差异化竞争）
产品安装和下载
快速使用（详细的使用文档或者二次开发文档，外链即可）
交流提问区
关于作者（放你的博客链接，和收款二维码）
最后，把以上完成的工作，都提交到 github 中。

提交代码

写代码
具体写什么代码不是本文的重点，你尽情的根据自己的项目来写自己的代码就是了。记得一定要使用编码规范的工具，例如 es-lint 等，否则经过长时间的维护，必然留坑。
写文档 & 写测试用例

注意，文档和测试用例对于一个开源产品来说非常重要！非常重要！非常重要！而且，文档和测试用例本身就是代码不可分割的一部分。
如何写测试用例，需要用到其他工具，内容也相对独立，这里就不介绍了，自己去查一查吧。再次强调，测试用例很重要！！！

在写文档之前，还需要准备其他的工具。定位到项目目录下，npm i gitbook-cli -g 安装 gitbook ，然后创建 SUMMARY.md ，内容如下：

# Summary

- [项目介绍](README.md)
- [使用文档](doc/use/README.md)
  - [使用 1](doc/use/use1.md)
  - [使用 2](doc/use/use2.md)
- [二次开发](doc/dev/README.md)
  - [开发 1](doc/dev/dev1.md)
  - [开发 2](doc/dev/dev2.md)

其实一看这个文件内容就知道，这是一个文档的目录，你可以根据自己项目的需要重新定义这个目录。需要注意的是，第一行 * 项目介绍对应的是已经存在的 README.md 文件。

运行 gitbook init ，会看到各个文件都被创建了，就可以完善各个文档的内容。内容完成之后，运行 gitbook build 可以将 md 文件发布为 html 文件，默认放在 _book 文件夹。启动了 npm run example 之后，可以访问 http://127.0.0.1:8880/_book/ 查看效果。

最后，再次修改一下 README.md ，把文档的链接加上

1	[如何使用](./doc/use/README.md) [二次开发](./doc/dev/README.md)

提交第一版代码

首先，修改一下 .gitignore 文件，加上一行 _book ，把打包出来的文件忽略掉。然后用之前的方式提交到 github 的 master 分支，这里不再赘述了。

接下来，创建 tag 并提交，代码如下：

1 2	git tag -a 'v0.0.1' -m 'first commit' git push origin v0.0.1

提交之后，下载地址就有了， https://github.com/cxvh/is-visit-google/releases 这里可以下载到各个版本的源码。

最后要提交到 npm 上，能让使用者通过 npm 进行安装。首先，运行 npm add user 和 npm login 来登录，根据提示将你之前注册 npm 时的账号、密码、邮箱写上就行了，问题不大。然后，在项目的根目录运行 npm publish . ，此时问题来了！！！

运行之后报了 403 错误，刚才明明登录成功了，不可能有权限问题呀。后来一查才知道，原来 fast-cache 在 npm 中和其他项目重名了！！！没办法，只能改名，将 package.json 中的名称改为 fast-cache-npm ，然后再发布就成功了。

发布之后，通过 https://www.npmjs.com/package/is-visit-google 就可以访问 npm 项目主页了。

撤回提交

npm unpublish 名字

升级代码并提交

上述是第一次提交代码的流程，下面简述一下升级代码之后的提交流程。在代码开发阶段的步骤总结如下： -来一个 dev 分支，不要在 master 分支开发 -修改 package.json 版本号，按照之前既定的版本规则修改，不能乱改 -修改代码、文档和测试用例 -自测 -将 dev 分支提交到远程

代码开发完成之后，提交的流程如下： -再次确认版本号，因为版本号非常重要 -将 dev 合并到 master ，并提交 master 到远程 -创建 tag 并提交到远程 -提交到 npm

合并 pr

pr 即 Pull Request 的简称。

开源软件最大的特色就是允许全世界的开发者都能为其贡献代码，你这个开源项目也不例外。其他人很有可能会通过 github 的 pr 为你的项目贡献自己的代码，到时候你既得欣然接受，又不能茫然接受。

其他人贡献的 pr 可以通过 https://github.com/cxvh/is-visit-google/pulls 链接看到。对于每一个 pr ，如果你想合并，直接 merge 就好了（合并完之后，本地代码要随时更新一下）；如果你不想合并，留言说明然后关闭掉即可。

创建官网

我们通过 github pages 的机制即可免费创建项目的挂网，不用花一分钱。

创建项目

登录 github ，创建一个名为 fast-cache.github.io 的项目，名字必须是这一个！！！然后下载到本地，即 git clone xxxx 。然后，进入项目目录，新建一个 index.html ，然后随便写点什么，例如 <h1>hello world</h1> ，提交到 github 远程。

最后，访问 fast-cache.github.io ，你就能看到刚才的内容了，最简单的官网就这么出来了。做到这里，你应该知道 github pages 就是一个静态页面的服务器，上传相应的 html 就能显示。

生成官网

此前用 gitbook 将文档生成为 html 了，应该还记得。那么我们现在重新运行 gitbook build 生成 html ，然后将所有的 html 拷贝到这里来，全部提交上去，正式的官网也就出来了。

更新 README.md
记得要修改 README.md ，把官网的地址加进去。

如何宣传

“酒香不怕巷子深”这句话在当代并不适用，特别是互联网中。我在 N 年前看过一本创业公司老板写的研发项目管理方面的书，到现在就记住一句话 —— “一个公司的核心竞争力，一是技术，二是营销”。因此，虽然是一个简单的开源项目，宣传也是必须必要的。

宣传和更新维护都是一个漫长的过程，作为屌丝账户的我们（不是 google facebook 等明星账户），能做的只能是坚持。

写博客

首先，要围绕着你做的产品功能来写博客。例如针对 fast-cache ，我们可以写类似这样的博客。分体分两类，第一类是相关的技术干货文章，第二类是产品介绍，应该以第一类为主。

总结如何做前端缓存
前端缓存的坑
预防前端内存泄露
前端缓存插件 fast-cache 使用总结
fast-cache 开发半年记

其次，要正确选择发表的网站，我的建议是这样的：

选择一个地方作为你博客的唯一主页，例如 github ，像创建官网一样创建个人博客网站。
博客贴到各大博客网站，如掘金、知乎专栏、博客园。选择三个流量较大的即可，不用到处乱贴。
博客内容要写明白原文的链接，并写明产权。
最好能找到一些媒体（如 InfoQ）或者大牛公众号帮你转发。

回答相关问题

去知乎、sf.gg 甚至是 stackoverflow 上面去搜索、关注与你产品相关的问题，积极参与回答。回答问题也有技巧：

字数只能多不能少。最好图文并茂，还能讲个笑话
回答要专业，经过亲自测试，不要想当然的瞎猜
回答问题的最后，顺便推广自己的产品

口碑宣传

所谓口碑宣传就是让用户资源的帮助宣传，那就需要把产品做好，那如何做“好”呢？

明确产品定位，有特色。做“T”型产品，差异化竞争。把一方面做好就行了，所有都做好不可能。
及时回复问题，定期更新升级，做好升级计划，让用户看到产品在不管进步和变化。

持续迭代

主要来探讨一下如何有效率的持续迭代，再不影响工作、生活的情况下。

统一问题收集区

github issue

定期答复和升级

让别人自愿、积极的去提交 issue 的前提是你能及时的答复。根据我的经验，给你以下建议：

定期回复 每天（下班或者上班之前）看看 github issues 然后先答复，临时无法搞清楚的就回复“周末时看下再答复”。这样每天大约花费 5-15 分钟即可，出去抽根烟的功夫。最后，需要修改的问题，先记录下。
定期升级 每周拿出 2 个小时（随便一个晚上或者周末时间）把记录下的问题，按照优先级高低顺序修复。就 2 小时，改多少算多少，改不完下周再说。改完的问题要及时回复 issue 并 close 。每周 2 小时，对你这周的工作生活应该不会受到影响。