前言本文主要讲述如何正确实现一个合格的npm包教学。不要花太多时间在具体的代码实现上。定位在教学方式上，主要是让学生知道如何正确处理代码实现以外的一些工作。有兴趣的朋友可以自行参考monitor-event-emitter。麻雀虽小，五脏俱全。demo可以在控制台演示每次执行事件处理程序时的日志信息。今年的目标之一就是深入学习Typescript。此前，Vue技术栈是中流砥柱。去年，公司开始用react+antd+typescript开发新后端。这对于一向习惯了javascript松散类型的我来说，是一个不小的挑战。很多时候，习惯性地使用any来避免所有的问题。现在回头看以前的一些业务代码，火爆得让我不禁反感。不由得开始思考自己之前学习打字稿的方式，大部分都是在看的阶段。不管是官方文档还是技术文档，我都看了很多，但最后还是苦苦挣扎自己去做。所以我决定改过自新，打算尝试用typescript写一个库。巧合的是，在之前接触过的业务代码中，经常能看到我们公司的大牛用javascript写的一个事件触发器，所以打算推倒重来，用typescript重新实现。一是加深对typescript的理解和应用，二是弥补长期以来技术输出的不足。同时，希望丰富图书馆的功能。最好有一个很好的概述，因为我涵盖的主题范围很广，我会简单地提一些老生常谈的事情。对于一些比较难理解的点，大家可以参考gitcommit提交记录看看我做了哪些工作。有兴趣不懂的可以自行去看官方文档。而有些东西，我也可能是第一次接触，如有不妥还请见谅。请给我更多的柔情认真看完这篇文章，相信你一定能有所收获。要点如下。写功能代码，还有哪些工程配置是你必须要注意和实现的，它们会反馈给你更规范、更标准的开发如何写一个更规范的文档，了解一些有趣的技术点Excalidraw手绘风格设计图表，风格独特，程序员必备github动作。各大厂家出品，必属精品。你通常可以用几行代码做很多有趣的事情。写一个博客shields.io很有必要，让你的图书馆看起来更正规。图标设计库实现第一步：创建工程。没什么可说的。首先创建一个仓库。这里我们将写好的库发布到npm官网，方便其他人免费下载使用，所以重点是要选择一个好名字，什么是好名字，我的理解有两点避免重复包名，见名知义mkdirmonitor-event-emitter//创建文件夹cdmonitor-event-emitter//进入文件夹gitinit//成为git仓库npminit-y//初始化包并生成一个package.json包配置文件这里我刚开始的包名不叫这个。在第一个版本发布后，我再次更改了名称，实现了我的库的核心功能（控制台实时打印日志快照）。为了让别人看到包名，可以大致知道它是什么，有什么特点，是否吸引我下载使用。第二步：完善包配置文件，完善package.json文件。这是非常有意义的。它是别人从理解你的包到能够正确使用你的包的核心。挑几个点说说主库的入口文件，你都配置了什么，最后别人安装使用这个库的时候，要找这个文件，避免冗余文件路径，引入描述库的描述文件.一句话，越精越好，突出库的亮点，吸引别人使用，是库声明文件的关键类型，因为是用typescript开发的包，别人用的时候，为什么会有代码提示和参数类型纠错功能，即文件提供的能力。哪些文件上传到npminclude。无需将所有文件和文件夹向上推送。里面的文件可以使库正常工作，也便于用户理解。越少越好，越多越好。在repository中填写你的github项目仓库，这样其他人在使用库的过程中有问题，或者你只是想看看你的个人主页，至少你可以在条目中找到库类型的关键字关键字。比如我的库，主要是实现事件的实时监控。我用的这些monitors,events,emitter的第三步：项目配置具体功能实现前的重要一步，工程领域不可或缺的一部分，粗略的说，husky在我们自己的仓库目录下有个目录叫.git，并且在里面放置了一些脚本钩子，为了方便git步骤的执行，先执行或者后执行一些额外的脚本，这样我们就可以干预它的进程，做一些有趣的事情。比如pre-commit也是最常用的脚本。主要用来做commit前的一些检查工作，比如你的提交信息是否符合规范，别人是否能根据你的提交信息看出你提交的代码意图等。另一个是代码风格和质量验证。配合eslint、prettier、stylelint，简直不要太爽。你可以自己写一些脚本。比如我之前尝试用node实现一个小功能。当哨兵版本号与changelog版本号不匹配时，拒绝本次提交的逻辑被拒绝。不过还是用现成的库哈士奇比较方便。lint-staged一句话解释就是限制了husky脚本的执行范围。只是为了验证一下我这次提交的内容，在大家重构一个老项目或者添加代码质量和风格验证的时候，可能会更好的体现它的意义。毕竟没有人愿意只提交一行代码，那样会暴露前人写的硬核代码的风格或者质量问题。虽然有自动修复的问题，但还是有一些问题小编无法自动帮我们修复，尤其是有强迫症的小哥，估计瞬间心态就炸了。eslint主要用于管理代码质量问题。请用let，用var我会报错！但我也可以非常仔细地帮你改正错误。修不好就得麻烦自己手动操作prettier了。它主要用于管理代码风格问题。约束大家有统一的开发风格，避免风格不一致导致的merge冲突或者报错。比如语句末尾要不要用分号，只有一个参数的函数要不要用括号括起来，要用双引号还是单引号。没有好坏之分。我的团队讨论了一套大家都能接受的规范。stylelint主要用于管理样式代码的质量和样式。比如颜色应该是#000或者#000000或者黑色，还有style属性的顺序。虽然这两种方式都不会影响页面的显示效果，但是从长期维护的角度来说都是非常有意义的。而且上面说的顺序问题也是解决性能优化的一个小点，因为可以减少浏览器重排或者重绘commitlint约束提交信息规范，不要只说gitcommit-m'updatealldaylong'是的，你告诉我，你更新了什么？涉及的范围是什么？重构还是删除？永远记住一句话，发信息是给人看的，不是给人看的，没人能通过你弱更新的六个字母看出你的脑洞。同时我也可以保证，当你回头看提交信息的时候，你依然会一头雾水。第四步：这个库的特性到这里，我们就可以正式开始实现我们的功能代码了。库核心文件大约有400行代码，不包括注释。实现了一个轻量级的事件监控触发器。个人觉得，如果熟悉ES6语法，还是很容易读懂的。如果对具体实现感兴趣，可以参考gitcommit提交记录。如果大家有更好的实现思路，可以提issue或者通过pr参与项目。每次接收到事件执行命令并执行函数时，控制台会以表格的形式实时打印出日志，方便调试和问题定位。实际效果请参考演示控制台。大体思路请参考这张图：是否对库的主要特性有太多的限制。因为我个人的感受是，限制越少，使用起来越方便，人们就越愿意使用和了解它。有一个普遍的场景，虽然你写的东西很好用，但是限制太多了。实例化的时候需要传N个参数才能触及它的灵魂，所以我大概会放弃使用它。请记住，使用的成本越高，被废弃的可能性就越大。不过话说回来，很多库看起来用起来很自由，没有太大的精神负担，因为它的很多逻辑都是高度内聚的。说白了，开发者已经预测到了你所有的使用习惯和场景。在库中实现的时候，大部分在设计之初就考虑过是用对象还是地图来维护我的事件中心。由于涉及到频繁的add、remove、check等逻辑。我觉得还是选择map比较合适，毕竟它自带的一些方法确实好用。这里想表达的是，实现功能的方式有很多种，但是在设计之初，一定要有一定的整体概念。你应该思考如何更好、更方便、更直观地实施，而不是实施到一半发现自己迷失在起跑线上，推翻它从头开始只是头皮发麻，支持实时监控能力。大致意思就是在我们的业务代码中，可能有N个不起眼的地方注册了N个事件监听器，也可能在N个角落里悄无声息地被触发。如果没有监控机制，很难找出它们执行的真实环境和情况，比如什么类型的函数处理器？执行参数是什么？返回结果是什么？执行的顺序是什么等等。但是有了实时观察的能力，你可以很方便的在控制台实时观察到事件的触发情况，包括它们的入参、出参、类型。这样更容易定位问题，这样后面能用表格或图片的东西，大部分都可以用来表达意图，所以不要用苍白的词来表达。因为这是一个快节奏的社会，大多数人都没有耐心。所以我把map结构的复杂（这里的复杂指的是map类型的数据，在控制台打印出来后看起来不是很清楚）事件执行快照转换成数组模型，以a的形式呈现给大家控制台中的表。更易于阅读和调试。同时支持mode参数，也可以让你自由选择需要看什么样的数据。目前支持default,cool自定义提示信息，根据你使用时传入的scope字段，实现相关日志信息在控制台的分类展示。这样可以很方便的区分出不同业务下出现的问题，从而快速定位和修改问题，然后不断优化功能代码的实现，记得保持代码的易读性。.第五步：单元测试当你认为你写的核心逻辑已经实现了，你就要进行单元测试了。您希望确保您的代码在其他人使用它之前将出现问题的可能性降至最低。对于大部分的功能使用场景，都需要通过单元自测提前预演。几乎所有好的库都有单元自测模块。它的意义不仅仅在于发现错误并改正错误，更有价值的是它可以检测出一些你在实现时没有考虑到的地方，并驱动你重新完善业务逻辑。开玩笑的单元测试框架。之前没用过，按照文档尝试使用，发现还是挺容易理解和使用的。_这里有点啰嗦，我不太会写异步的。虽然看了文档的用法，但是说到我的step-by-stepscenario，还是不太明白怎么写。那些擅长它的人可以帮助改进它。PR，磕头感谢_第六步：写一个合格的README当你觉得一切准备就绪的时候就可以发布npm了。等等，最重要的一步来了。也就是写一个标准格式的README.md。什么是标准？细化一下我的理解：大纲清晰，主要包括以下几个部分。demo可以用一个真实的demo场景给别人看你的库的特点，所以不要用Paletext为什么要用这个包。你可以解释一下这个包的用途，以及它和现有的一些同类包的区别，重点解决什么问题。安装如何安装你的包，支持哪些环境使用最基本的使用方法。其中，举几个例子，让人知道如何使用config这个包支持的参数有哪些，含义是什么，todo的类型是什么，接下来要实现的功能，并记录下当前的不好点，看看稍后将优化正式化并认真对待。如果你认为你想做的是一件有意义的事情。然后做对，让它看起来像那样。shields.io的一些小图标，比如你的库用的是什么语言，单元测试覆盖率是多少，打包体积是多少。这些是影响别人是否愿意使用你的图书馆的关键点，看起来很有说服力。需要提醒小伙伴们的是，这里的一些图标不仅仅是显示静态数据的图标。比如我的codecov图标中的单元自测覆盖率，在提交代码时通过githubaction实时向第三方报告测试覆盖率报告，很有意思。在这里安利大家学习githubaction，真的很好吃。我只是个前端小白，你让我处理一些太深奥的后台服务器相关的专业配置，比如nginx、jenkins的配置，小妾未必能搞定。而且学了之后，你简直就是神了，你想实现的一切，简单的几行代码就可以实现。比如部署网站，定时执行任务，拦截单元测试，有人提交issue时通知我等等，用githubpages写博客的朋友，一定要学会使用，不就是执行push吗命令？，你本地博客的最新内容已经部署到网上让别人知道了，是不是很爽？第七步：博客和推广博客以推广您的图书馆。你需要能够用通俗易懂的语言告诉大家你做了什么，它的意义是什么？成长给你带来了什么，同时解决了哪些问题。让大家从你的文章中有所收获，同时吸引大家参与到你的项目中来。这里想借用一个梗，那就是：不会写博客的程序员，不一定是不合格的程序员。但是愿意写博客的程序员，以后一定会成为合格的程序员。写出原创作品不易，被人称道，被人珍视。至此，何不来一波马克三下。monitor-event-emitter源码demo效果演示
