npm 包管理的基础用法
Node.js 在 2013 年开始变得越来越热,而 npm 也逐渐从一个附属工具,变成了 JavaScript 开发者必须熟悉的生态入口。
Node.js 在 2013 年开始变得越来越热,而 npm 也逐渐从一个附属工具,变成了 JavaScript 开发者必须熟悉的生态入口。
npm 真正开始好用之后,开发者很快就会遇到两个新问题:依赖到底应该装哪个版本,项目命令又该怎么统一。它们看起来像细节,但在 2013 年已经足够决定一个项目是“能复现”还是“只能在作者电脑上运行”。
工具链越丰富,越容易让人产生一种冲动:项目只要稍微多一点脚本和命令,就赶紧引入一层更复杂的构建工具。2013 年我在接触 npm scripts 这套能力时,也有过这种心态,总觉得直接用 scripts 显得有点朴素,好像不上点额外工具就不够“工程化”。
很多人第一次运行 npm init 之后,会把 package.json 看成一个顺手生成出来的文件。可到 2013 年,随着 Node.js 项目越来越多,大家已经慢慢发现:这个文件其实正在变成项目配置和协作信息的中心。
前端开发者刚转到 Node.js 时,经常会在异步这里卡住。页面脚本里也有事件和回调,但放进服务端请求处理后,感受会更强,因为浏览器正在等你返回结果,流程一下就变得更有压力。
2013 年很多前端开发者第一次认真看 Node.js 时,最兴奋的地方往往是“终于可以用 JavaScript 写后端了”。但真正想把它学好,第一步不是写接口,而是先把服务端思维建立起来。
2013 年刚开始用 Node.js 写小服务时,很多项目规模不大,大家对日志的预期也很简单:出问题时能在控制台看到几行输出就行。可我后来越写越觉得,哪怕暂时还没有完整日志系统,只是写到控制台,日志也应该先有最基本的格式感。
Node.js 最吸引前端开发者的地方,往往是“终于能用 JavaScript 写后端”。但刚开始时,如果只顾着找框架、写接口,很容易忽略一个更基本的问题:请求到底是怎么进来,又是怎么返回出去的。