Libscore的撰稿人，包括我们自己的创意总监Jesse Chase，想提供这篇文章作为对项目所获得的所有支持的感谢。Julian Shapiro在上个月发布了Libscore，希望开发人员社区能够发现这个工具有用，并继续感谢在网络。为了那些没听说过的人，Libscore是一个全新的开源项目，它扫描了上百万个网站，以确定它们正在使用哪些第三方JavaScript库。该工具旨在帮助前端开源开发人员衡量他们的影响-你可以阅读所有关于它的信息这里。进来在这篇文章中，我们将对Libscore所利用的技术进行分解，并讨论实现它的一些挑战。我们也有幸与朱利安进行了交谈，并对他在哪里看到的项目有了一些了解去吧，托马斯Davis：一个技术概述不同于传统的网络爬虫，Libscore在无头浏览器中彻底扫描每个网站的运行时环境。这使得Libscore能够监视每个网站上的操作环境，并检测尽可能多的库，甚至那些已经预先打包并作为模块需要的库也是如此。当然，权衡一下，运行一百万个无头浏览器连接比执行基本的cURL请求和解析静态连接要消耗更多的资源HTML我们在设计爬虫程序时获得的最大的见解是，消除第三方插件误报的最佳方法是利用我们正在聚合的更广泛的数据集。第三方图书馆中至少有30万个没有被我们发现。使用像这样的元启发式让我们能够更自信地检测实际上是第三方插件的库，而不仅仅是泄漏到全局的任意JavaScript变量范围。开后端，爬网通过Redis排队，结果存储在MongoDB中。这两种服务都被完全加载到RAM中，这使得我们的restfulapi能够以比查询磁盘更快的速度提供请求。爬行并发性的主要瓶颈是网络带宽，但多亏了DigitalOcean，在不同地区的非高峰时间反复克隆实例和运行爬网简直是轻而易举。最终，只使用几个高RAM的DigitalOcean实例，我们每分钟解析600个网站，并在每个网站结束时在不到36小时内完成整个爬网月。如爬虫程序运行时，每个站点的原始库使用数据被附加到一个主JSON文件中，我们只需使用Nodejs从文件系统读取该文件。收集完所有原始使用数据后，我们将启动一个名为"摄取"的过程，该过程负责聚合结果并使其通过API访问。实际上，我们试图将整个数据集加载到ram中以执行我们的计算，但是很快就遇到了一个奇怪的问题：V8无法为数组分配超过大约1GB的内存。目前，我们正在将原始转储拆分为较小的文件以绕过内存限制，尽管将来我们可能只是重写项目以使用更合适的语言和环境。杰西蔡斯：设计改进虽然Libscore目前是一个非常有价值的工具来呈现库的采用数据，但未来更令人兴奋。为了说明这一点，让我们提前6个月——恰逢盛夏。在这一点上，Libscore已经在前百万个站点中爬过6次了（或者说是600万个域爬网！）为图书馆带来了丰富的逐月趋势数据使用。依据为用户提供一个即将发布的时间序列图，以及在同一时间段内绘制多个库的能力，开发人员将对库如何随时间变化有新的了解。例如，用户将能够了解为什么一个库的使用率从一个月骤降到下一个月——这可能是由于另一个库的采用率增加。很快，这些数据将形象化了。朱利安Shapiro:LibscoreLibscore的未来不仅仅是JavaScript统计的一个目的地；它还是一个可以在开源项目营销中利用的数据存储。我们实现这一点的一个方法是通过显示实时站点计数的嵌入式徽章。开源开发人员可以在他们的GitHub自述文件中展示这些徽章，而撰写开源文章的记者也可以将这些徽章包括在内，以提供关于图书馆。在除了徽章，我们还发布了关于JavaScript库使用状况的季度报告。帮助开发者了解这些正在下降的流行趋势。我们希望这些报告将成为有关web开发工具现状的讨论的宝贵贡献，并最终为社区提供他们可以用来制作的具体数据决策。创造者开发人员——Julian ShapiroBackend开发商——Thomas Davis创意总监——Jesse Chase