Skip to content

registry: add hlint (github:ndmitchell/hlint)#8670

Merged
jdx merged 2 commits intojdx:mainfrom
3w36zj6:feature/add-hlint-to-registry
Mar 21, 2026
Merged

registry: add hlint (github:ndmitchell/hlint)#8670
jdx merged 2 commits intojdx:mainfrom
3w36zj6:feature/add-hlint-to-registry

Conversation

@3w36zj6
Copy link
Copy Markdown
Contributor

@3w36zj6 3w36zj6 commented Mar 21, 2026

@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, 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 integrates hlint, a static analysis tool for Haskell, into the system's registry. This addition enhances the platform's capabilities by providing automated suggestions and improvements for Haskell codebases, aiming to improve code quality and maintainability for users working with Haskell.

Highlights

  • New Tool Added: The hlint tool, a linter for Haskell source code, has been added to the registry.
  • Configuration: A new TOML configuration file (registry/hlint.toml) defines hlint's backend, description, and a test command for version checking.
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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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.

Footnotes

  1. 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.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds hlint to the tool registry. The configuration is simple and appears correct. I have one suggestion to make the tool definition more robust by explicitly listing the supported operating systems, which also brings attention to the lack of ARM architecture support in the upstream releases.

Comment thread registry/hlint.toml
Comment on lines +1 to +3
backends = ["github:ndmitchell/hlint"]
description = "Haskell source code suggestions"
test = { cmd = "hlint --version", expected = "HLint v{{version}}" }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To make the tool definition more robust, it's good practice to specify the supported operating systems. Based on the hlint GitHub releases, it provides binaries for Linux, macOS, and Windows, but only for the x86_64 architecture. This means it won't work on ARM-based systems like Apple Silicon Macs.

By adding the os property, you make this explicit and can prevent installation failures on unsupported platforms.

Consider adding the os property to your configuration:

backends = ["github:ndmitchell/hlint"]
description = "Haskell source code suggestions"
os = ["linux", "macos", "windows"]
test = { cmd = "hlint --version", expected = "HLint v{{version}}" }

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 21, 2026

Greptile Summary

This PR adds hlint — a Haskell source code linter — to the mise tool registry using the github:ndmitchell/hlint backend.

The entry is well-formed and consistent with existing conventions in the registry:

  • The description matches the upstream GitHub repository description exactly.
  • The test field uses hlint --version, with expected = "HLint v{{version}}", which is correct: the cmdargs-based CLI outputs HLint v<version>, (C) Neil Mitchell … and the contains-check against HLint v{{version}} will pass.
  • The TOML structure mirrors similar single-backend entries like github:simonmichael/hledger.

No new structural or logic issues were identified beyond what has already been raised in prior review threads.

Confidence Score: 4/5

  • Safe to merge; the registry entry is correctly structured, though end-user install success depends on binary asset availability in upstream GitHub releases.
  • The TOML format is correct, the test command and expected string are accurate, and the entry follows existing registry conventions. The only outstanding risk — whether pre-built binary assets are consistently published for the latest release — has already been discussed in a prior review thread and is an upstream concern rather than a bug in this file itself.
  • No files require special attention beyond the already-discussed binary release reliability of github:ndmitchell/hlint.

Important Files Changed

Filename Overview
registry/hlint.toml New registry entry for hlint using the github: backend; structure and test format follow existing conventions correctly, though relies solely on the github: backend which depends on pre-built binary releases being available.

Sequence Diagram

sequenceDiagram
    actor User
    participant mise
    participant GitHubAPI as GitHub API<br/>(ndmitchell/hlint)
    participant GitHubRelease as GitHub Release<br/>Asset (binary)

    User->>mise: mise install hlint
    mise->>GitHubAPI: GET /repos/ndmitchell/hlint/releases/latest
    GitHubAPI-->>mise: Release metadata (tag: v3.10)
    mise->>GitHubAPI: List release assets for v3.10
    GitHubAPI-->>mise: Asset list
    alt Binary asset found for platform
        mise->>GitHubRelease: Download hlint binary
        GitHubRelease-->>mise: Binary file
        mise->>mise: Install to tool path
        User->>mise: mise exec hlint -- hlint --version
        mise-->>User: HLint v3.10, (C) Neil Mitchell 2006-2025
    else No binary asset for platform/version
        mise-->>User: Error: no matching asset found
    end
Loading

Last reviewed commit: "Merge branch 'main' ..."

@3w36zj6 3w36zj6 force-pushed the feature/add-hlint-to-registry branch from 089f01c to 4ecfebf Compare March 21, 2026 01:40
Comment thread registry/hlint.toml
@@ -0,0 +1,3 @@
backends = ["github:ndmitchell/hlint"]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Binary release availability for latest version uncertain

The github: backend works by downloading pre-built binary assets from GitHub releases. HLint's release history raises a concern about binary availability:

  • The v3.6.1 changelog entry explicitly reads "Attempt to make a binary release" — implying this was not standard practice before.
  • The release.yml workflow run for v3.10 (the latest release) completed in ~13 seconds, which is far too fast to compile and upload Haskell binaries for multiple platforms (other workflow runs take 26–28 minutes).
  • v3.10 was created directly by the author (ndmitchell), not github-actions, which is a departure from how v3.5–v3.8 were published.

If v3.10 (or future releases) do not include pre-built binary assets, mise install hlint will fail for end users.

Consider verifying the release assets exist, and if binary availability is unreliable, adding a fallback backend (e.g. an asdf: plugin) to improve robustness:

Suggested change
backends = ["github:ndmitchell/hlint"]
backends = ["github:ndmitchell/hlint", "asdf:mise-plugins/mise-hlint"]

(Only if a suitable asdf plugin exists — otherwise at minimum confirm binaries are present at https://github.com/ndmitchell/hlint/releases/tag/v3.10 before merging.)

@jdx jdx enabled auto-merge (squash) March 21, 2026 10:54
@jdx jdx disabled auto-merge March 21, 2026 10:54
@jdx jdx merged commit 3fccc6f into jdx:main Mar 21, 2026
34 checks passed
This was referenced Mar 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants