mpb manages bars through a heap, out of a 92-word README

Three patch releases in five weeks, and v8 in the module path

The module path in go.mod is github.com/vbauerster/mpb/v8, so the major version is part of every import path a consumer writes. Releases have been moving inside that line: v8.16.0 on 2026-08-24, v8.16.1 on 2026-09-01 and v8.16.2 on 2026-09-28, which is three patch versions in five weeks. The last commit is dated 2026-09-26, two days before the newest tag, so tag and branch head sit close together. Nothing in the README states a version requirement or a stability promise for the v8 line, and the root carries no changelog file, so that sequence has to be read off the release list rather than off the project. The one documentation link at the top of the README points at pkg.go.dev, where the version specific package docs live.

go 1.26.0 in go.mod, and a stringer tool directive

Two lines of go.mod set the floor for anyone building or contributing. The language version is declared as go 1.26.0, and a tool directive pins golang.org/x/tools/cmd/stringer, the code generator, while the tree keeps an internal/ directory for generated or private code. The same golang.org/x/tools module appears again as an indirect requirement at v0.32.0, alongside golang.org/x/mod, golang.org/x/sync and golang.org/x/sys. Four direct requirements sit above that indirect block: ewma v1.2.0 for the ETA estimate, stripansi, go-runewidth v0.0.30, and cupwriter v0.0.5, which shares the account name with the library. The README mentions none of this and has no build, test or install section. The only trace of automation is the pair of workflow badges at the top, one pointing at test.yml and one at golangci-lint.yml.

Six documented features, four direct dependencies, nothing about escapes

The feature list has six entries: multiple bars, setting a total while a bar is already running, adding and removing bars dynamically, cancelling the whole rendering process, four predefined decorators (elapsed time, an ewma based ETA, percentage and a bytes counter), and decorator width synchronization across bars. Four direct requirements support that list, and only one of them is named in it. ewma v1.2.0 is the ETA estimator, and no smoothing factor or window is configurable anywhere in the documentation. go-runewidth v0.0.30 underpins the width arithmetic that the sync feature needs. cupwriter v0.0.5 is a writer from the same author. stripansi is required without a single documented feature mentioning colour or escape sequences. The indirect block adds clipperhouse/uax29/v2 v2.7.0 to the four golang.org/x modules.

The single-bar example stops inside PrependDecorators

The single-bar snippet sets the container width first and then creates a bar that inherits it, and the decorator list is where the written example ends: it opens mpb.PrependDecorators and stops at a comment about the one space on the right of a name. The shape that survives is still readable. A container is built with an option that carries a custom width, the bar is created with an int64 total, and the second argument is a builder chain for the bar style rather than a plain integer. Everything after that point, which is where the decorators themselves would be listed, is not there to read.

p := mpb.New(mpb.WithWidth(64))

total := 100
name := "Single Bar:"
// create a single bar, which will inherit container's width
bar := p.New(int64(total),
    // BarFillerBuilder with custom style
    mpb.BarStyle().Lbound("╢").Filler("▌").Tip("▌").Padding("░").Rbound("╟"),
    mpb.PrependDecorators(

AddBar with a WaitGroup, and three examples that are links only

The second snippet is the one that shows the bar lifecycle. Bars are added with p.AddBar instead of being created up front, the WaitGroup is incremented once per bar, and the percentage decorator is given the WCSyncSpace option, which the comment ties to the DSyncWidth bit that enables column width synchronization. Underneath that, the tree keeps bar_heap.go and heap_manager.go, so bars are ordered through a heap rather than a plain slice, which is what makes dynamic add and remove workable. Then the documentation thins out: five example directories are linked, and only singleBar and multiBars get code, while dynTotal, queueBar and io are bare links to their main.go files.

var wg sync.WaitGroup
// passed wg will be accounted at p.Wait() call
p := mpb.New(mpb.WithWaitGroup(&wg))
total, numBars := 100, 3
wg.Add(numBars)

for i := range numBars {
    name := fmt.Sprintf("Bar#%d:", i)
    bar := p.AddBar(int64(total),
        mpb.PrependDecorators(
            // simple name decorator
            decor.Name(name),
            // decor.DSyncWidth bit enables column width synchronization
            decor.Percentage(decor.WCSyncSpace),
        ),
        mpb.AppendDecorators(

Three filler implementations in the tree, one shown in the README

The tree splits bar filling across three files: bar_filler_bar.go, bar_filler_nop.go and bar_filler_spinner.go. Only the bar filler reaches the documentation, through a builder chain naming a left bound, the filler glyph, the tip, the padding and a right bound. That chain is where the width question turns concrete, because the glyphs used there are Unicode box drawing and block characters, so each one has to be measured in terminal cells rather than in bytes. go-runewidth is the direct requirement that answers that, and the width synchronization feature is what keeps decorator columns aligned once several bars share a screen. The spinner and the no-op filler are selected from the same kind of builder, but nothing in the written example shows either of them.

UNLICENSE at the root, and no support path anywhere in the text

The root file is UNLICENSE and the license field says Unlicense, so the two agree, and there is no second license file or per-directory licensing question in the tree. Everything else about the presentation is thin. The README amounts to about ninety words of prose and two code fragments, names no maintainer, links no issue tracker, no chat room and no discussion forum, and offers no compatibility guidance for the v8 line. The only outbound links are the package documentation and the two workflow badges, so the release history explaining what changed in three recent patch versions is not reachable from the project text. The repository does carry a CONTRIBUTING entry and a proxywriter.go, proxyreader.go and proxyreadseeker.go trio, none of which the README mentions.

Editorial conclusion

mpb fits a Go command line tool that needs several bars at once, decorator columns that line up, and a decorator vocabulary instead of bespoke bar drawing, and it does not fit a reader who needs build steps, a changelog or a stated compatibility policy, because none of that is in the project text. Before adopting it, read three things in the source instead of in the docs: the go 1.26.0 line in go.mod against your own toolchain, the four direct requirements (ewma, stripansi, go-runewidth, cupwriter) against what you already ship, and the two half finished decorator lists in the examples, which is where you will end up reading the API from.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes