将 jscodeshift 更新到最新版本

我想列出一些需要讨论的主题，以使 jscodeshift 脱离停滞状态。 1. 最大的问题在于 recast。 这套库在过去两年中几乎没有得到维护，有大约 150 个问题和 40 个 pull request 等待合并。 似乎 80% 的与 jscodeshift 相关的问题实际上是 recast 问题。 为了解决 jscodeshift 的未决问题，要么 recast 本身需要解决它们，要么 jscodeshift 需要采用/创建自己的 recast 分支来解决它们。 在过去的一年半左右的时间里，putout 的主要开发者一直在维护一个 recast 分支，并为其添加了许多修复。 可能有必要考虑转向 @putout/recast，而不是 recast 上游。 我也一直在为 evcodeshift 创建一个 @putout/recast 分支，该分支添加了一些其他内容，以便在 vscode 中更容易调试 evcodeshift 转换。 2. 关于 recast 可以说的，也可以在较小程度上说到 ast-types。 3. 现有的未决问题和 pull request 将如何处理？其中一些问题/pull request 太久以前了，我不知道它们是否仍然有用。此外，当前打开的 pull request 太多，可能会吓跑想要贡献的人。目前，是否有意义关闭大多数 pull request？如果其中任何 pull request 都可以通过一些测试轻松、安全地合并，我们是否应该这样做？ 4. 类似地，许多问题并没有标记。是否有任何问题需要后向标记，以便我们更容易在特征请求的“干草”中搜索缺陷的“针”呢？ 5. jscodeshift 启动时使用“babel5compat”设置，该设置保留 babel 解析器更改在 pre-babel 6 AST 中，这似乎是为了避免破坏旧的现有 codemods。必须明确指定“babylon”配置，该配置针对越来越多的人似乎抱怨他们无法访问的新的 post-Babel 6 功能。目前，是否应该将 jscodeshift 切换为 babylon 作为默认值？ 6. 类似地，是否有任何 Facebooker 能告诉我 Facebook 内部使用的解析器配置是 jscodeshift 转换？ babel5compat（当前默认值）、babylon、ts 等。我猜破坏 Facebook 传统 codemods 的新版 jscodeshift 会导致不良后果，因此我想知道我面临的情况。可能可以编写一些自动检测兼容性功能，扫描 codemod 代码以猜测要使用的解析器，但我想先看看是否需要写这个功能。 7. 项目中有一些未标记的问题，这使得明确搜索缺陷（与特征请求相比）有一些挑战。我想假设应该没有问题将它们标记以使其更易于搜索？