node升级的小坑

起因

node最近的发展日新月异，现在都已经到node7了，公司的项目中使用的node版本一直还是v0.10.30的，这个版本的node已经停止维护了，并且新版本的node提供了ES6语法的支持，性能上也有一定提升，node版本的升级也是项目组提了好久的话题，直到最近业务特性比较少，才提上日程一步一步解决。

升级方案

首先做了了升级预调，我们想要升级到的版本是几乎原生支持全部ES6语法的6.10.0（可以在http://node.green/上查看ES6语法覆盖率），并且是node官网的目前推荐的长期维护版本。做了一些升级的尝试，发现从v0.10.30升级到v6.10.0版本面临的主要问题是我们开发了大量native模块，这两个版本native模块开发使用的api完全不一样，需要升级所有的native模块，这是一个工程量不小的体力活。

因为node持续不断的更新，也有大神考虑到了native模块升级的难题，写了一个nan模块，对上层提供native模块通用接口，对下层封装各个版本的native模块api，这样我们只要用nan重写所有的native模块，以后即使再升级也只要重新编译navtive模块，或者升级nan模块就可以了，然而依然是体力投入巨大的活，好在组里有勤劳勇敢的小伙完成了这个任务。升级完native模块，新版本的node其实很多内置模块的api也有变动，后面陆陆续续碰到过一些坑，这里先不详述。

我们的业务使用pm2管理进程，我们把node-6.10.0执行文件提交到我们的代码库中，pm2配置文件中指定使用业务代码根目录下面的node启动进程，这样看似已经完成了node的升级，实际上还没有，系统默认使用的node依然是v0.10.30，也就意味着启动pm2守护进程还是用的node-0.10.30，而且我们开发环境陆续碰到一些问题，比如使用npm依然是老的版本，使用node-gyp编译native模块依然使用的node-0.10.30，编译出来的模块新版不可用等，因此还需要升级系统默认node，其实也就是一个cp指令，但是升级系统node到node-6.10.0后又出现了pm2启动失败，查到原因是因为node-6.10.0的内置path模块行为有变化，导致执行老版本的pm2失败，于是又升级pm2到新版本，这样终于完成了整个node版本的升级

最后还碰到一个坑，新版本的npm采用扁平目录结构安装第三方模块，这会导致我们要安装一个新的第三方模块时node_modules目录产生很大变动，我们担心这样提交上去会对业务带来不可预知的问题，因此又在开发环境安装了nvm，利用nvm维护0.10.30版本的node，将npm指向老版本的npm，使用层级目录结构安装新的模块，这样终于完成了现网环境和开发环境的node升级。

总结

从现网可用到开发测试部署好用，排了一系列的坑，感觉node你走得太快了，等等我们这些还有好多业务要开发的程序员吧~