CLI: Add nodeinfo command using Optique #414
Conversation
dodok8
changed the title
issues-auto-labeler
bot
added
breaking change
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @dodok8, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly upgrades the CLI by introducing a powerful nodeinfo command. This command allows users to query and visualize information about Fediverse instances in a user-friendly format, including a unique ASCII art representation of the instance's favicon. The underlying implementation leverages the Optique framework for command parsing and includes robust error handling and display options to cater to different user needs.
Highlights
- New CLI Command:
nodeinfo: Introduced a new command-line interface tool to fetch and display detailed information about remote Fediverse nodes using the NodeInfo protocol. - Optique Integration: The
nodeinfocommand has been migrated to use the Optique framework for robust command-line argument parsing and definition, enhancing its structure and maintainability. - Enhanced Output with Favicon ASCII Art: The command now fetches the favicon of the remote instance and renders it as colorful ASCII art directly in the terminal, providing a visually engaging summary. It includes logic to detect terminal color support (truecolor, 256-color, or none).
- Flexible Data Display Options: Added various options to control the output, including displaying the raw NodeInfo JSON document, attempting best-effort parsing for malformed documents, suppressing favicon display, and showing extended metadata.
- Comprehensive Testing: New unit tests have been added for favicon URL extraction, RGB to 256-color conversion, and ASCII art generation, ensuring the reliability of the new features.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request migrates the nodeinfo command to use Optique and significantly enhances its functionality by adding favicon fetching and ASCII art rendering. The changes are well-structured and the new tests are comprehensive. My feedback focuses on improving the robustness of the implementation, particularly in parsing HTML and ICO files, and enhancing the maintainability of the output formatting logic.
| const LINK_REGEXP = | ||
| /<link((?:\s+(?:[-a-z]+)=(?:"[^"]*"|'[^']*'|[^\s]+))*)\s*\/?>/ig; | ||
| const LINK_ATTRS_REGEXP = /(?:\s+([-a-z]+)=("[^"]*"|'[^']*'|[^\s]+))/ig; |
There was a problem hiding this comment.
Using regular expressions to parse HTML is fragile and can break with slightly different but valid HTML structures. It's more robust to use a proper HTML parser, like Deno's @std/html/dom. This would also simplify the logic for extracting attributes and make it easier to implement more sophisticated logic for selecting the best icon, rather than just taking the first one that matches.
Here's an example of how getFaviconUrl could be rewritten using a DOM parser. This would require adding @std/html to your deno.json imports.
import { DOMParser } from "jsr:@std/html/dom";
export async function getFaviconUrl(
url: string | URL,
userAgent?: string,
): Promise<URL> {
const response = await fetch(url, {
headers: {
"User-Agent": userAgent == null ? getUserAgent() : userAgent,
},
});
const text = await response.text();
const doc = new DOMParser().parseFromString(text, "text/html");
if (!doc) {
return new URL("/favicon.ico", response.url);
}
for (const link of doc.querySelectorAll("link[rel~='icon'], link[rel~='apple-touch-icon']")) {
const href = link.getAttribute("href");
if (!href || href.endsWith(".svg")) {
continue;
}
const sizes = link.getAttribute("sizes");
if (sizes?.match(/\d+x\d+/)) {
const [w, h] = sizes.split("x").map((v) => parseInt(v, 10));
if (w < 38 || h < 19) {
continue;
}
}
return new URL(href, response.url);
}
return new URL("/favicon.ico", response.url);
}| const images = await parseICO(buffer); | ||
| if (images.length < 1) { | ||
| throw new Error("No images found in the ICO file."); | ||
| } | ||
| buffer = images[0].buffer; |
There was a problem hiding this comment.
The current implementation for handling ICO files takes the first image from the container. ICO files can contain multiple images of different sizes, and the first one is not guaranteed to be the largest or of the best quality. It would be better to iterate through the images and select the one with the largest dimensions to ensure the best quality for the ASCII art.
const images = await parseICO(buffer);
if (images.length < 1) {
throw new Error("No images found in the ICO file.
}
// Select the largest image from the ICO file
const largestImage = images.reduce((prev, current) =>
(prev.width * prev.height > current.width * current.height) ? prev : current
);
buffer = largestImage.buffer;| const next = () => { | ||
| i++; | ||
| if (i >= layout.length) layout.push(" ".repeat(defaultWidth)); | ||
| return i; | ||
| }; |
There was a problem hiding this comment.
The current approach for building the output layout by mutating the layout array with a next() helper function is a bit difficult to follow and maintain. It relies on a shared counter and side effects, which can be error-prone. A more declarative approach, where you build the right-side content separately and then merge it with the ASCII art, would be more readable and robust.
Here's a sketch of an alternative approach:
// 1. Generate the ASCII art lines (same as before)
// let layout = getAsciiArt(...)
// 2. Build the right-side info lines in a separate array
const infoLines: string[] = [];
infoLines.push(colors.bold(url.host));
infoLines.push(colors.dim("=".repeat(url.host.length)));
// ... add all other info lines
// 3. Merge the two arrays for the final output
const outputLines: string[] = [];
const numLines = Math.max(layout.length, infoLines.length);
for (let i = 0; i < numLines; i++) {
const left = layout[i] ?? " ".repeat(defaultWidth);
const right = infoLines[i] ?? "";
outputLines.push(`${left} ${right}`);
}
console.log(outputLines.join("\n"));
dodok8
force-pushed
the
dodok8-issue-399
branch
from
353680b to
1124ee2
Compare
|
The docs for this pull request have been published: |
|
The latest push to this pull request has been published to JSR and npm as a pre-release:
|
2 participants
Summary
Migrate
nodeinfousing OptiqueRelated Issue
Reference the related issue(s) by number, e.g.:
nodeinfocommand using Optique #399Changes
nodeinfo.test.tsnodeinfo.tsnodealias.Benefits
Migrate to Optique, which supports all runtimes.
Checklist
deno task test-allon your machine?Additional Notes
Include any other information, context, or considerations.