Egg 期刊 06 - VSCode 调试优化 && Alinode 接入

eggjs-feed-06， 系列期刊，用于汇总近期值得关注的 egg 相关动态，将不定期发布。

小编按：这是年前最后一期 egg-feed 了，大家都已经开始回家过年了吧？一想想有好几天不能写代码，手还是真痒痒的，年关愁啊。
从 2.0 发布到现在，GitHub Star 新增 1.3k star，过年路上的朋友们随手动动，凑个整数。

VSCode 一键调试 Egg 完美版

这是一个持续了近 2 年的折腾过程，VSCode 早期版本，对 Node Cluster 的调试支持一直不是很友好，譬如：

• 开发期重启进程后，不支持重新 attach。

• Cluster 重启后 debugPort 会自增，VSCode 也不支持 attach 新端口。

• Egg 的 多进程模型 多了 Agent 处理公关事务，在开发期也有 3 个进程（master/agent/worker）。

在这期间，我们做了不少的努力，持续优化着 Egg 的调试体验。
终于，随着 VSCode@1.20 的发布，这个话题终于可以告一个段落。
仅需安装 vscode-eggjs 即可零配置一键调试 Egg 。
具体折腾过程参见：VSCode 调试 Egg 完美版 - 进化史
—-

Alinode 接入指南

@朴灵 老师的 alinode 已经全功能免费开放，改名为 Node.js 性能平台 。

Node.js 性能平台是面向所有 Node.js 应用提供 性能监控、安全提醒、故障排查、性能优化 等服务的整体性解决方案，提供完善的工具链和服务，协助开发者快速发现和定位线上问题。

• 传送地址：https://node.console.aliyun.com

• 实属居家旅行，内存泄露，线上性能分析必备利器。

• 同时更新了 Egg 的 alinode 接入文档。

关于 module.exports 的吐槽

Egg 的 Config 支持几种配置方式，但无奈的是，很多新手都会混淆 exports 和 module.exports 。

// config/config.default.js
exports.view = {};
module.exports = appInfo => {
  const config = {};
  config.keys = '123456';
  return config;
};

这种低级错误，在日常解答中出现过很多次，甚至集团内部都有，有时候真会让我有点怀疑人生。 累计到昨天光我自己就解答了 18 次了，不自觉的总会带有一点怒气的去回复，但这样怼人其实真的不好。

如何能帮助开发者避免低级错误，又能保持好维护者的答疑心情呢？
对此，@天猪 提出了一个 RFC 提案，据说类库名有亮点，欢迎围观。

值得注意的讨论和变更

在 eggjs 团队的日常协作中，遵循「基于 GitLab 的硬盘式异步协作模式」。 通过 issue 发起 RFC 提案 -> 讨论定稿-> 提交 Pull Request -> Code Review -> 发布。 这样便于沉淀，即使是当时没有参与讨论的开发者，事后也能通过 issue 了解某个功能设计的前因后果。

Θ 新增了 egg-socket.io 文档

• 文档地址：egg-socket.io 文档 。

• 感谢 @苏依 同学的贡献。

Θ egg-schedule 优化

• 支持执行日志单独输出到： egg-schedule.log ，方便排查问题。

• 在自定义 schedule 类型时支持传递额外的参数。

• PR 地址： egg-schedule#35 和 文档地址 。

Θ Egg 英文官网上线

• 传送门：https://eggjs.org/en/index.html

• 感谢各位贡献者：English translation

• 目前还有高级用法没翻译完成，欢迎加入。

ES6 Class Extends 性能分析

• @宗羽 大神在做 hessian 性能优化时的发现的一个 class extends 性能问题。

• 围观地址：https://zhuanlan.zhihu.com/p/33538431

• 当然，大家也不能因哽废食，他特别强调了：

写这篇文章的目的不是让你不要用 ES6 Class + extends，只是客观反映目前 js 引擎对于各种类定义、继承方式的处理现状。对于普通的场景我建议你该怎么写还怎么写，因为我相信 v8 和其他 js 引擎迟早会解决这个问题，没有必要因为一点性能牺牲代码的优雅。从上面 benchmark 的数据不如直接原型链方式高效，但也是千万级ops/sec，所以基本上不太会成为你代码的瓶颈。

npm scripts 小知识一则

这个问题也是最近比较常解答的，一并分享出来。
熟悉 egg 项目的同学一定见过这段 package.json 的配置：

"scripts": {
  "start": "egg-scripts start",
  "stop": "egg-scripts stop",
  "dev": "egg-bin dev",
  "debug": "egg-bin debug",
  "test": "npm run lint -- --fix && npm run test-local",
  "test-local": "egg-bin test",
  "cov": "egg-bin cov",
  "lint": "eslint .",
  "ci": "npm run lint && npm run cov",
  "autod": "autod"
},
"devDependencies": {
  "egg-bin": "^4.3.6",
}

有人会很好奇，egg-bin 这些命令，是不是要全局安装啊？
其实不需要，它们是作为 devDependencies 引入的，这里是 npm 的一个机制 ：

• 开发者执行 npm run dev 时，会去 package.json 找到对应的 “dev”: “egg-bin dev” 并执行这条指令。

• 同时，npm 会把 ./node_modules/.bin 目录加入到本次的 PATH 中。

• 因此，系统就会执行 ./node_modules/.bin/egg-bin。

• 而这个 bin 是 npm install egg-bin 时生成的软链。

至于为什么不全局呢，因为我们的理念是尽可能的自包含，项目自带自己所需要的所有依赖，况且全局容易出现冲突。

另外，还跟大家分享一个小技巧：「如何同机部署多个项目时，使用不同的 Node 版本？」
其实很简单，使用我们的 nodeinstall 在构建期把对应的 Node 安装到项目的 node_modules 目录下即可，根据上面阐述的原理，在 npm start 时会优先使用项目目录下的 Node 。
当然，这是以前的方式了，在 Docker 时代就不用那么麻烦了。
—-

写在最后

2018 年第一场业界分享 - 蚂蚁 SeeConf ，分享了 AntDesign 等背后的故事，真是业界良心。

另，小编当场就被蚂蚁的设计师们给震撼住了，他们对着我们码农说：

我不是针对你，我是在说各位的 Slide 都是渣渣。

对应的 Slide 也都出了，欢迎围观：参加第一届蚂蚁体验科技大会 SEE Conf 2018 是什么体验？