Shell

Nodejs 获取 Shell 一行可展示字符长度

https://stackoverflow.com/questions/30335637/get-width-of-terminal-in-node-js

  1. console.log(
  2.   'Terminal size: ' +
  3.     (process.stdout.columns || 10) +
  4.     'x' +
  5.     (process.stdout.rows || 10)
  6. );

parser

babel & jscodeshift

babel 的 transform api 是visitor 风格，也就是声明对什么 ast 做什么处理，然后在遍历过程中被调用，这种不和具体遍历方式耦合的写法是一种设计模式（访问者模式），处理再复杂的场景也能应对。就是处理简单场景显得稍微啰嗦点。

jscodeshift 是 collection 风格，类似 jquery，主动查找 ast，放到集合中操作，适合处理简单场景，要知道每种 ast 是怎么查找到的，然后做转换，要处理很多很多 case，万一查找路径不对，那可能就漏掉了一些情况，比起 babel 来，很难在复杂场景下没有 bug。

就像 jquery 和 mvvm 的区别一样，复杂场景还是 mvvm 的方式（babel）靠谱，不会漏 case。

曾经，babel 的维护者考虑结合两者，用 recast（jscodeshift 的 js parser） 做 parse，用 babel 的 transform 插件，但最终未能成型，解释如下：
https://github.com/facebook/jscodeshift/issues/168

My two cents: The Visitor-based transformation API used by Babel tends to be better for complicated transforms, and transforms that need to be run by other people who don’t fully understand what’s happening behind the scenes, which means handling more edge cases automatically, and not giving up in cases when it’s easier to edit the code by hand. The Collection-based API is much better for hand-supervised codemods, and for transforms where it’s ok if you don’t handle every edge case, because you know that certain patterns of syntax are rare in your specific codebase. These may not be the only possible options in the API landscape, but they’ve proven effective in their respective niches. I don’t think it necessarily makes sense to unify them into one API, but I’m totally in favor of making both kinds of transforms easier to write, if possible.

tsc

一些基础 ts compiler 的 api 介绍
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
简单的例子
https://cloud.tencent.com/developer/article/1452826