test(*): add lint-md-cli, and auto fix all issues

chengcjun · Aug 21, 2019 · 1517e86 · 1517e86
1 parent c8f86df
commit 1517e86
Show file tree

Hide file tree

Showing 49 changed files with 282 additions and 269 deletions.
diff --git a/.lintmdrc b/.lintmdrc
@@ -0,0 +1,7 @@
+{
+  "excludeFiles": [],
+  "rules": {
+    "no-long-code": 0,
+    "no-trailing-punctuation": 0
+  }
+}
diff --git a/.travis.yml b/.travis.yml
@@ -0,0 +1,6 @@
+language: node_js
+node_js:
+  - "10"
+before_install:
+  - npm i -g lint-md-cli
+script: lint-md ./
diff --git a/001.精读 js 模块化发展.md b/001.精读 js 模块化发展.md
@@ -10,7 +10,7 @@
 
 <img src="assets/1/cube.jpeg" alt="logo" width="500" />
 
-> 如今，Javascript 模块化规范非常方便、自然，但这个新规范仅执行了2年，就在 4 年前，js 的模块化还停留在运行时支持，10 年前，通过后端模版定义、注释定义模块依赖。对经历过来的人来说，历史的模块化方式还停留在脑海中，反而新上手的同学会更快接受现代的模块化规范。
+> 如今，Javascript 模块化规范非常方便、自然，但这个新规范仅执行了 2 年，就在 4 年前，js 的模块化还停留在运行时支持，10 年前，通过后端模版定义、注释定义模块依赖。对经历过来的人来说，历史的模块化方式还停留在脑海中，反而新上手的同学会更快接受现代的模块化规范。
 
 但为什么要了解 Javascript 模块化发展的历史呢？因为凡事都有两面性，了解 Javascript 模块化规范，有利于我们思考出更好的模块化方案，纵观历史，从 1999 年开始，模块化方案最多维持两年，就出现了新的替代方案，比原有的模块化更清晰、强壮，我们不能被现代模块化方式限制住思维，因为现在的 ES2015 模块化方案距离发布也仅仅过了两年。
 
@@ -26,7 +26,7 @@
 
 **外部依赖定义 (2007)**: 这种定义方式在 cocos2d-js 开发中普遍使用，其核心思想是将依赖抽出单独文件定义，这种方式不利于项目管理，毕竟依赖抽到代码之外，我是不是得两头找呢？所以才有通过 webpack 打包为一个文件的方式暴力替换为 commonjs 的方式出现。
 
-**Sandbox模式 (2009)**: 这种模块化方式很简单，暴力，将所有模块塞到一个 `sanbox` 变量中，硬伤是无法解决明明冲突问题，毕竟都塞到一个 `sandbox` 对象里，而 `Sandbox` 对象也需要定义在全局，存在被覆盖的风险。模块化需要保证全局变量尽量干净，目前为止的模块化方案都没有很好的做到这一点。
+**Sandbox 模式 (2009)**: 这种模块化方式很简单，暴力，将所有模块塞到一个 `sanbox` 变量中，硬伤是无法解决明明冲突问题，毕竟都塞到一个 `sandbox` 对象里，而 `Sandbox` 对象也需要定义在全局，存在被覆盖的风险。模块化需要保证全局变量尽量干净，目前为止的模块化方案都没有很好的做到这一点。
 
 **依赖注入 (2009)**: 就是大家熟知的 angular1.0，依赖注入的思想现在已广泛运用在 react、vue 等流行框架中。但依赖注入和解决模块化问题还差得远。
 
@@ -52,7 +52,7 @@
 
 这篇文章所提供的模块化历史的方案都是逻辑模块化，**从 CommonJS 方案开始前端把服务端的解决方案搬过来之后，算是看到标准物理与逻辑统一的模块化**。但之后前端工程不得不引入模块化构建这一步。正是这一步给前端开发无疑带来了诸多的不便，尤其是现在我们开发过程中经常为了优化这个工具带了很多额外的成本。
 
-从 CommonJS 之前其实都只是封装，并没有一套模块化规范，这个就有些像类与包的概念。我在10年左右用的最多的还是 YUI2，YUI2 是用 namespace 来做模块化的，但有很多问题没有解决，比如多版本共存，因此后来 YUI3 出来了。
+从 CommonJS 之前其实都只是封装，并没有一套模块化规范，这个就有些像类与包的概念。我在 10 年左右用的最多的还是 YUI2，YUI2 是用 namespace 来做模块化的，但有很多问题没有解决，比如多版本共存，因此后来 YUI3 出来了。
 
 ```javascript
 YUI().use('node', 'event', function (Y) {
@@ -118,7 +118,7 @@ YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo
 ### 补充阅读
 
 - [JavaScript 模块化七日谈](https://huangxuan.me/2015/07/09/js-module-7day/)
-- [JavaScript模块化编程简史（2009-2016）](https://yuguo.us/weblog/javascript-module-development-history/)
+- [JavaScript 模块化编程简史（2009-2016）](https://yuguo.us/weblog/javascript-module-development-history/)
 
 # 总结
 

diff --git a/002.精读模态框的最佳实践.md b/002.精读模态框的最佳实践.md
@@ -72,7 +72,7 @@
 
 ### 可访问性的反思
 
-Accessibility 翻译过来是『无障碍访问』，是对不同终端用户的体验完善。每一个模态框，都要有通过键盘关闭的功能，通常使用ESC键。似乎我们程序员多少总会把我们自我的惯性思维带进实现的产品，尤其是当我们敲着外置的键盘，用着 PC 的时候。
+Accessibility 翻译过来是『无障碍访问』，是对不同终端用户的体验完善。每一个模态框，都要有通过键盘关闭的功能，通常使用 ESC 键。似乎我们程序员多少总会把我们自我的惯性思维带进实现的产品，尤其是当我们敲着外置的键盘，用着 PC 的时候。
 
 下面的这些问题都是对可访问性的反思：
 

diff --git a/003.精读前后端渲染之争.md b/003.精读前后端渲染之争.md
@@ -17,7 +17,7 @@
 **前端渲染的优势**
 
 - 局部刷新。无需每次都进行完整页面请求
-- 懒加载。如在页面初始时只加载可视区域内的数据，滚动后rp加载其它数据，可以通过 react-lazyload 实现
+- 懒加载。如在页面初始时只加载可视区域内的数据，滚动后 rp 加载其它数据，可以通过 react-lazyload 实现
 - 富交互。使用 JS 实现各种酷炫效果
 - 节约服务器成本。省电省钱，JS 支持 CDN 部署，且部署极其简单，只需要服务器支持静态文件即可
 - 天生的关注分离设计。服务器来访问数据库提供接口，JS 只关注数据获取和展现
@@ -36,7 +36,7 @@
 
 本次提出独到观点的同学有：[@javie007](http://link.zhihu.com/?target=https%3A//github.com/javie007) [@杨森](https://www.zhihu.com/people/c93b7957f6308990c7e3b16103c9356b) [@流形](https://www.zhihu.com/people/6c772f9726a914ed4a4b90c88010461c) [@camsong](https://www.zhihu.com/people/078cc0fb15845759ad8295b0f0e50099) [@Turbe Xue](https://www.zhihu.com/people/turbe-xue) [@淡苍](https://www.zhihu.com/people/5ac53c9c0484e83672e1c1716bdf0ff9) [@留影](https://www.zhihu.com/people/38c3c75795824de1bc5d99cff904a832) [@FrankFang](http://link.zhihu.com/?target=https%3A//github.com/FrankFang) [@alcat2008](http://link.zhihu.com/?target=https%3A//github.com/alcat2008) [@xile611](http://link.zhihu.com/?target=https%3A//github.com/xile611) [@twobin](http://link.zhihu.com/?target=https%3A//github.com/twobin) [@黄子毅](https://www.zhihu.com/people/3ec85a04bc9eaa35b1830874cc463a52) 精读由此归纳。
 
-大家对前端和后端渲染的现状基本达成共识。即前端渲染是未来趋势，但前端渲染遇到了首屏性能和SEO的问题。对于同构争议最多，在此我归纳一下。
+大家对前端和后端渲染的现状基本达成共识。即前端渲染是未来趋势，但前端渲染遇到了首屏性能和 SEO 的问题。对于同构争议最多，在此我归纳一下。
 
 ### 前端渲染遇到的问题
 
@@ -46,7 +46,7 @@ SEO 很好理解。由于传统的搜索引擎只会从 HTML 中抓取数据，
 
 ### 同构的优点
 
-同构恰恰就是为了解决前端渲染遇到的问题才产生的，至 2014 年底伴随着 React 的崛起而被认为是前端框架应具备的一大杀器，以至于当时很多人为了用此特性而[放弃 Angular 1 而转向 React](http://link.zhihu.com/?target=https%3A//blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/)。然而近3年过去了，很多产品逐渐从全栈同构的理想化逐渐转到首屏或部分同构。让我们再一次思考同构的优点真是优点吗？
+同构恰恰就是为了解决前端渲染遇到的问题才产生的，至 2014 年底伴随着 React 的崛起而被认为是前端框架应具备的一大杀器，以至于当时很多人为了用此特性而[放弃 Angular 1 而转向 React](http://link.zhihu.com/?target=https%3A//blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/)。然而近 3 年过去了，很多产品逐渐从全栈同构的理想化逐渐转到首屏或部分同构。让我们再一次思考同构的优点真是优点吗？
 
 1. 有助于 SEO
 
@@ -65,7 +65,7 @@ SEO 很好理解。由于传统的搜索引擎只会从 HTML 中抓取数据，
 
 1. 性能
 
-把原来放在几百万浏览器端的工作拿过来给你几台服务器做，这还是花挺多计算力的。尤其是涉及到图表类需要大量计算的场景。这方面调优，可以参考 [walmart的调优策略](https://medium.com/walmartlabs/reactjs-ssr-profiling-and-caching-5d8e9e49240c)。
+把原来放在几百万浏览器端的工作拿过来给你几台服务器做，这还是花挺多计算力的。尤其是涉及到图表类需要大量计算的场景。这方面调优，可以参考 [walmart 的调优策略](https://medium.com/walmartlabs/reactjs-ssr-profiling-and-caching-5d8e9e49240c)。
 
 个性化的缓存是遇到的另外一个问题。可以把每个用户个性化信息缓存到浏览器，这是一个天生的分布式缓存系统。我们有个数据类应用通过在浏览器合理设置缓存，双十一当天节省了 70% 的请求量。试想如果这些缓存全部放到服务器存储，需要的存储空间和计算都是很非常大。
 
@@ -97,7 +97,7 @@ export const isSsr = () => (
 
 5. simple store（redux）
 
-这个 store 是必须以字符串形式塞到前端，所以复杂类型是无法转义成字符串的，比如function。
+这个 store 是必须以字符串形式塞到前端，所以复杂类型是无法转义成字符串的，比如 function。
 
 总的来说，同构渲染实施难度大，不够优雅，无论在前端还是服务端，都需要额外改造。
 
@@ -136,7 +136,7 @@ Next.js 是时下非常流行的基于 React 的同构开发框架。作者之
 
 1. 巧妙地用标准化的解决了请求的问题。同构和页面开发类似，异步是个大难题，异步中难点又在接口请求。Next.js 给组件新增了 getInitialProps 方法来专门处理初始化请求，再也不用手动往页面上塞 DATA 和调用 ReactDOMServer.renderToString
 2. 使用 [styled-jsx](https://github.com/zeit/styled-jsx) 解决了 css-in-js 的问题。这种方案虽然不像 styled-component 那样强大，但足够简单，可以说是最小的成本解决了问题
-3. Fast by default。页面默认拆分文件方式打包，支持Prefetch页面预加载
+3. Fast by default。页面默认拆分文件方式打包，支持 Prefetch 页面预加载
 
 全家桶式的的解决方案。简洁清晰的目录结构，这一点 Redux 等框架真应该学一学。不过全家桶的方案比较适合全新项目使用，旧项目使用要评估好成本
 

diff --git a/005.精读民工叔单页数据流方案.md b/005.精读民工叔单页数据流方案.md
@@ -22,7 +22,7 @@
 3.  局部与全局状态的归一
 4.  分形思想
 5.  action 分散执行
-5.  app级别数据处理，推荐前端 `Orm`
+5.  app 级别数据处理，推荐前端 `Orm`
 
 整体来看，核心思路是推荐组件内部完成数据流的处理，不用关心使用了 `Redux` `Mobx` 或者 `Rxjs`，也不用关心这些库是否有全局管理的野心，如果全局管理那就挂载到全局，但组件内部还是局部管理。
 
@@ -42,7 +42,7 @@
 
 以 Mobx 为代表，轻前端用的较多，因为复杂度集中在后端，前端做好数据展示即可，那么直接拥抱 js 这种基于对象的语言，结合原生 `Map` `Proxy` `Reflect` 将副作用进行到底，开发速度快得飞起。
 
-数据存储方式按照视图形态来，因为视图之间几乎毫无关联，而且特别是数据产品，后端数据量巨大，把数据处理过程搬到前端是不可能的（为了推导出一个视图形态数据，需要动辄几GB的原始数据运算，存储和性能都不适合在前端做）。
+数据存储方式按照视图形态来，因为视图之间几乎毫无关联，而且特别是数据产品，后端数据量巨大，把数据处理过程搬到前端是不可能的（为了推导出一个视图形态数据，需要动辄几 GB 的原始数据运算，存储和性能都不适合在前端做）。
 
 #### 函数式
 
@@ -75,7 +75,7 @@
 
 ### 分形的缺点
 
-对于聊天室或者在线IDE等，全局数据居多，很多交叉绑定的情况，就不适合分形思想，反而纯 Redux 思想更合适。
+对于聊天室或者在线 IDE 等，全局数据居多，很多交叉绑定的情况，就不适合分形思想，反而纯 Redux 思想更合适。
 
 ## 3.3 数据形态，是原始数据还是视图数据？
 

diff --git a/006.精读JavaScript错误堆栈处理.md b/006.精读JavaScript错误堆栈处理.md
@@ -14,7 +14,7 @@
 
 Stack 部分主要在阐明 js 中函数调用栈的概念，它符合栈的基本特性『当调用时，压入栈顶。当它执行完毕时，被弹出栈』，简单看下面的代码：
 
-```
+```plain
 function c() {
 	try {
 		var bar = baz;
@@ -46,7 +46,7 @@ a();
 
 ## 如何使用堆栈追踪
 
-该部分以 NodeJS 环境为例，讲解了 `Error.captureStackTrace `，将 stack 信息作为属性存储在一个对象当中，同时可以过滤掉一些无用的堆栈信息。这样可以隐藏掉用户不需要了解的内部细节。作者也以 Chai 为例，内部使用该方法对代码的调用者屏蔽了不相关的实现细节。通过以 Assertion 对象为例，讲述了具体的内部实现，简单来说通过一个 addChainableMethod 链式调用工具方法，在运行一个 Assertion 时，将它设为标记，其后面的堆栈会被移除；如果 assertion 失败移除起后面所有内部堆栈；如果有内嵌 assertion，将当前 assertion 的方法放到 ssfi 中作为标记，移除后面堆栈帧；
+该部分以 NodeJS 环境为例，讲解了 `Error.captureStackTrace`，将 stack 信息作为属性存储在一个对象当中，同时可以过滤掉一些无用的堆栈信息。这样可以隐藏掉用户不需要了解的内部细节。作者也以 Chai 为例，内部使用该方法对代码的调用者屏蔽了不相关的实现细节。通过以 Assertion 对象为例，讲述了具体的内部实现，简单来说通过一个 addChainableMethod 链式调用工具方法，在运行一个 Assertion 时，将它设为标记，其后面的堆栈会被移除；如果 assertion 失败移除起后面所有内部堆栈；如果有内嵌 assertion，将当前 assertion 的方法放到 ssfi 中作为标记，移除后面堆栈帧；
 
 # 3. 精读
 参与本次精读的同学有：[范洪春](https://www.zhihu.com/people/fanhc/activities)、[黄子毅](https://www.zhihu.com/people/huang-zi-yi-83/answers)、[杨森](https://www.zhihu.com/people/yangsen/answers)、[camsong](https://www.zhihu.com/people/camsong/answers)，该部分由他们的观点总结而出。
@@ -83,7 +83,7 @@ describe('should.js和power-assert的区别', () => {
 
 - 区分操作异常和程序员的失误。操作异常指可预测的不可避免的异常，如无法连接服务器
 - 操作异常应该被处理。程序员的失误不需要处理，如果处理了反而会影响错误排查
-- 操作异常有两种处理方式：同步 (try…catch) 和异步（callback, event - emitter）两种处理方式，但只能选择其中一种。
+- 操作异常有两种处理方式：同步 (try……catch) 和异步（callback, event - emitter）两种处理方式，但只能选择其中一种。
 - 函数定义时应该用文档写清楚参数类型，及可能会发生的合理的失败。以及错误是同步还是异步传给调用者的
 - 缺少参数或参数无效是程序员的错误，一旦发生就应该 throw。
 传递错误时，使用标准的 Error 对象，并附件尽可能多的错误信息，可以使用标准的属性名

diff --git a/007.精读请停止 css-in-js 的行为.md b/007.精读请停止 css-in-js 的行为.md
@@ -81,7 +81,7 @@ react-css-modules 引入了 styleName，将本地变量和全局变量很清晰
 
 另外，使用 react-css-modules，可以方便的覆盖本地变量的样式：
 
-```
+```plain
 import customStyles from './table-custom-styles.css';
 
 <Table styles={customStyles} />;

diff --git a/009.精读 Immutable 结构共享.md b/009.精读 Immutable 结构共享.md
@@ -12,7 +12,7 @@
 
 # 2 内容概要
 
-使用 Object.assign 作用于大对象时，速度会成为瓶颈，比如拥有 `100,000` 个属性的对象，这个操作耗费了 134ms。性能损失主要原因是 “结构共享” 操作需要遍历近10万个属性，而这些引用操作耗费了100ms以上的时间。
+使用 Object.assign 作用于大对象时，速度会成为瓶颈，比如拥有 `100,000` 个属性的对象，这个操作耗费了 134ms。性能损失主要原因是 “结构共享” 操作需要遍历近 10 万个属性，而这些引用操作耗费了 100ms 以上的时间。
 
 解决办法就是减少引用指向的操作数量，而且由于引用指向到任何对象的损耗都几乎一致（无论目标对象极限小或者无穷大，引用消耗时间都几乎没有区别），我们需要一种精心设计的树状结构将打平的引用建立深度，以减少引用操作次数，`vector tries` 就是一种解决思路：