gleam-lang/gleam

Improve experience when publishing packages in a gleam monorepo

Open

#5418 opened on Mar 3, 2026

View on GitHub
 (3 comments) (0 reactions) (0 assignees)Rust (21,417 stars) (960 forks)batch import
help wanted

Description

This is a collection of issues I ran into when I tried to publish my own packages from a gleam monorepo and ideas on how we could improve that.

To be clear, I am talking about a project setup like this:

.
├── package_a
│   ├── gleam.toml
│   ├── manifest.toml
│   ├── README.md
│   └── src
│       └── app.gleam
├── package_b
│   ├── gleam.toml
│   ├── manifest.toml
│   ├── README.md
│   └── src
│       └── app.gleam
├── README.md
└── .git

Warning when there is no tag prefix or path in repository in gleam.toml

To make the hexdocs code references work, you need to make sure you link the correct path of your package inside of the git repository:

# gleam.toml
repository = { type = "github", user = "...", repo = "...", path = "package_a", tag-prefix = "pck-a-" }

If there is a mismatch between location of the .git directory (see point below) and the location of the gleam package, we could issue a warning that code references in hexdocs might not work if they do not match.

Make .git directory discovery more robust

When I published my package I did not get the git tag message after running gleam publish.

Having looked at the current source code, I think we can make the logic for detecting the .git directory more robust: https://github.com/gleam-lang/gleam/blob/4bcd14f500a4b7259eacec51fb7c93c23b588ec4/compiler-cli/src/publish.rs#L116-L132

Instead, we could run git rev-parse --show-toplevel to know if we are in a .git directory.

As it states on https://git-scm.com/docs/git-rev-parse:

Unless otherwise specified, most of the options and operation modes require you to run this command inside a git repository or a working tree that is under the control of a git repository, and will give you a fatal error otherwise.

Command for checking hexdocs references

This might be kind of out there, but judging from the reaction in Discord, invalid hexdocs references are fairly common, especially among new users. So it would be cool if there was a command that could check if any of the hexdocs links run into 404 or github (or other providers) pages that do not exist.

Definitely something someone (me) could provide as a separate package, but wanted to bring up the idea anyways.


Let me know what y'all think! Obviously there is a lot to consider with different providers and lots of edge cases that aren't on my map.

Contributor guide