中英文模式阅读
中文模式阅读
英文模式阅读

How to Inspect Node.js with Grunt-SWATCH (!watch) and Fiveo


我知道,我知道......封面图片中的插座并不是我们在这篇文章中讨论的插座类型,但最近我一直专注于构建新工作站的想法ThreadRipper
是一个怪物!我的意思是它实际上可能是解决方案,从不觉得我的计算机永远不够快,无论我升级到使用什么(现在它是Intel I7第8代CPU)。


我多年来一直使用的每台桌面/工作站(有一台)总是有很多不足之处。在你的电脑上等待COMPUTE糟透了!屏幕故障,似乎永无止境的进度旋转器,滞后时间等真正打破了生产力和工作流程。


无论如何关于主题,远离...Tangent

NodeBB (Node.js Forum) Hacking {#nodebb-node-js-forum-hacking}


正如我最近所写的那样,我最近的黑客攻击时间已经花在了论坛软件NodeBB上。 NodeBB开发人员的构建过程依赖于Grunt任务运行器,它本身也是用Node.js构建的。当你可以在一个主要基于你最喜欢的框架构建的生态系统中工作时(例如Node.js❤️),这很棒。


但是,当涉及到调试,以及当您的构建工具和其他软件层都使用Node.js构建时,有时事情会变得有点棘手。就像你想要通过时一样--inspect
标记到节点可执行文件以启动调试会话,目的是调试插件代码,而不是它上面的层(Grunt,NodeBB)。


我不知道任何特定于Grunt cli的命令行选项,可用于将启动Node调试会话的意图传递到任务级别。我尝试了几件事无济于事,但仍然有一些选择可以完成它:

  1. Start Grunt by calling Node directly, ala node --inspect /path/to/grunt
  2. Start the Node Inspector programmatically using the still experimental Inspector API
  3. Start the Node Inspector after the fact using Linux signals, SIGUSR1 to be exact.

Tradeoffs {#tradeoffs}


当然,这些解决方案中的每一个都提供了自己的障碍,并且大多数事情包括积极和消极方面!


在这篇文章中,我将讨论这些解决方案中的每一个,详细说明我使用每个解决方案时遇到的问题。我们将看到利用Inspector API如何利用NPM module fiveo
可能,以及该工具如何使用Node.js的Linux信号更加强大。最后,我将展示如何在此处提供的方案中,选项#3被证明是最佳解决方案。选择#3选项如何成为编写grunt-swatch插件的催化剂,该插件目前的功能,以及它可以做多少工作。


所以这个命令可以很好地启动调试器:

node --inspect /home/batman/.nvm/versions/node/v10.16.0/bin/grunt


并且grunt将继续做其在实际启动NodeBB服务器之前执行一系列构建步骤的事情。然而,请注意通过调用节点来启动初始Node进程的重要事实--inspect
当Grunt推出全新流程时,它将面临挑战。


很奇怪,当启动节点子进程并且在设置了inspect标志的情况下调用父进程时,子进程将继承该设置。但是出于同样的原因,如果你用节点调用节点--inspect
就像我们一样,你面对这些好消息😒在控制台里盯着你:

failed: address already in use


那些failed: address already in use
消息的发生是因为作为套接字服务器的检查器已经在父进程上启动,在我们的例子中是Grunt。因此,当孩子们从遗传开始--inspect
flag的默认参数设置为localhost:9229
,Node尝试启动检查器套接字服务器(我们称之为" inspect process
"从现在开始"使用默认端口9229。


解决方法是将我们的初始命令更改为:

node --inspect=0 /home/batman/.nvm/versions/node/v10.16.0/bin/grunt


"=0"
导致检查过程选择随机端口,如您所见,已选择39380和46704。Random Insepctor Ports


这很好,因为现在我们有两个检查程序进程在运行!不那么伟大的部分是我们不关心它们中的任何一个......

NodeBB's Build Setup {#nodebb-s-build-setup}


我无法完全解释 WHY
Grunt flow
组成NodeBB的Gruntfile:NodeBB Gruntfile.js snipit


但我可以这么说 WHAT
它正在做的基本上是分配一个初始化序列,它负责构建css,语言文件,模板,构建/捆绑Javascript等等......然后第二个进程被分叉以实际启动NodeBB服务器,资产准备就绪并且良好去。


更进一步,每次检测到更改都归功于监视过程(grunt-contrib-watch
),当前的NodeBB进程被终止并且新的进程被启动。随着新流程的到来......确切地说,每个周期都会生成一个新的随机调试端口。


这再次使我们的调试工作变得复杂并提出了一些问题。

  • How do we keep track of all of these random inspector ports?
  • Further as we are working on a remote server, how do we handle port forwarding?
  • Do we really care about the intermediate inspector sessions?

当我们思考那些时,让我们自己去......


当我们最初想要调试我们自己的代码时,这样做需要更具"侵入性"的方法。此选项需要包含检查器模块,这本身并不是什么大问题。我们一直需要代码,检查器模块是核心Node.js模块,而不是一些第三方代码。


但是,为了使该模块真正有用,必须编写额外的代码并将其添加到我们的代码库中。

const inspector = require('inspector')

要相当......

stepped away to hack on some other code...

Last Night! {#last-night-}


所以昨晚我写这篇文章时,我开始写这篇文章了 to be quite
说实话,我之前没有给过检查员模块。虽然这样做是为了尽可能以最明智的方式写这篇文章,但我还是被送了一个兔子洞。


其中之一我从编写了一个小型库,在核心检查器模块的顶部添加了一些糖,结果证明它非常酷。现在,在编写了这个小型库后,我建议不要使用检查器模块,最好不要使用fiveo
这反过来为你做了,同时添加一些漂亮的功能,如使用9229之类的端口this GitHub issue
是关于。Fiveo Demo Gif


不过,你可能不喜欢我的小图书馆,你可能对编写自己的图书馆不感兴趣。使用检查器api需要向您自己添加额外代码的事实仍然存在。这可能是使第二个选项成为您项目的不良选择的一个因素。这导致我们进入第三个也是最后一个选项......


所以最终我找到的最佳解决方案是使用UNIX / Linuxsignals
。这是一个指向联机帮助页的链接,可以让您全面了解哪些信号是准确的。它的长短是信号可以改变接收它们的进程的行为。 Note that signals are not supported on Windows.
来自Node的官方文档:


如果收到SIGUSR1信号,Node.js也将开始侦听调试消息。 (SIGUSR1在Windows上不可用。)

The Plan {#the-plan}


总体思路是我们可以在需要时将SIGUSR1信号传递给特定于我们代码的节点过程,而不是在此之前,从而消除了我们不关心的所有噪声。像NodeBB在初始阶段所做的那样的噪音(记住它分叉了一些东西),或者Grunt代码进入的内容等等。


我们准备启动调试器的重点是Grunt执行其init任务,启动NodeBB服务器之后的点,并且可以通过配置为运行的端口访问论坛tcp/45670
。那时我们需要确定NodeBB正在监听的进程ID,因为我们需要一个进程ID来将信号传递到适当的位置。收到后SIGUSR1
,Node将启动检查程序进程,我们可以开始调试!


我们刚才在前一段中描述的正是我们的Grunt插件 grunt-swatch
确实。它类似于 grunt-contrib-watch
因为它不断观察你环境的变化,不同之处在于 grunt-swatch
不看文件系统而是网络,因此名称来源于 socket watch


咕噜-的contrib手表


每当添加,更改或删除监视文件模式时,运行预定义任务


一个应该能够为插件编写其他"动作",但是我只编写了nim(恰当命名但也是一个回调函数)NiM
)行动nim.js
Code for nim action showing SIGUSR1


您可以看到它的功能相当简单,但正是我们所需要的。它使用Linuxkill
命令(也是an entertaining Sci-Fi
顺便说一句!)发送SIGUSR1
发信号给我们 swatched
处理。正如你所看到的那样close()
函数目前没有做任何事情,那是因为在写作之前fiveo
,无法通过信号方法关闭节点检查器。但是如果包含fiveo,我们可以访问SIGUSR2
这可以关闭检查员的过程......让事情更加整洁🧹。Code for nim action showing SIGUSR2


以下是您可以从中看到的输出swatch:nim
日志输出,nim操作实际上是关闭先前打开的节点检查器套接字。在下面的屏幕截图中,您可以看到此websocket的完整打开/关闭循环:ws://localhost:9230/b26fc131-af5e-4943-b911-a25b4261e43c
Log for nim action showing SIGUSR2


Grunt与我的grunt-swatch任务相关地加载和配置将确保在我的开发过程中,检查员将在我需要时智能地停止并启动。

grunt.loadNpmTasks('grunt-swatch')

进一步NiM
将确保DevTools始终在我需要的地方,打开正确的检查员websocket并准备好。NiM Popup Screenshot


我们终于得到它了。通过使用grunt-swatch,fiveo,以及NiM
Chromium Extension
,我们的NodeBB插件开发工作流程大大改进!我当然不会错过这个命令的手动过程,反过来,🔁和重复:

pid=`netstat -lnp|grep 45670|awk 'BEGIN {FS=" "}{print $7}'|cut -f1 -d"/"'`
kill -SIGUSR1 $pid

接下来的一些步骤可能是设计一种与debugee进程通信的方法,以便动态地更改调试器端口。为了能够从Grunt配置设置调试端口,实质上强制Node应用程序在预配置(开发中,后运行时)端口上打开调试器将是理想的!


我希望你发现这篇文章很有帮助。以下是相关链接:

中英文模式阅读
中文模式阅读
英文模式阅读

查看英文原文

查看更多文章


公众号:银河系1号


联系邮箱:public@space-explore.com


(未经同意,请勿转载)