Implementation of Rusts `dbg!` macro for quick and easy debugging during development

# godbg 🐛 [![Build Status](https://travis-ci.org/tylerwince/godbg.svg?branch=master)](https://travis-ci.org/tylerwince/godbg)

`godbg` is an implementation of the Rust2018 builtin debugging macro `dbg`.

The purpose of this package is to provide a better and more effective workflow for
people who are "print debuggers".

`go get github.com/tylerwince/godbg`

## The old way:

```go

package main

import "fmt"

func main() {
    a := 1
    fmt.Printf("My variable: a is equal to: %d", a)
}

```
outputs:

```
My variable: a is equal to: 1
```

## The _new_ (and better) way

```go

package main

import . "github.com/tylerwince/godbg"

func main() {
    a := 1
    Dbg(a)
}

```
outputs:

```
[main.go:7] a = 1
```

### This project is a work in progress and all feedback is appreciated.

The next features that are planned are:

- [ ] Tests
- [ ] Fancy Mode (display information about the whole callstack)
- [ ] Performance Optimizations
- [ ] Typing information


godbg

Analyze and visualize the size of dependencies in compiled Golang binaries, providing insight into their impact on the final build

# go-size-analyzer

[![Go Report Card](https://goreportcard.com/badge/github.com/Zxilly/go-size-analyzer)](https://goreportcard.com/report/github.com/Zxilly/go-size-analyzer)
[![Tests](https://github.com/Zxilly/go-size-analyzer/actions/workflows/built-tests.yml/badge.svg)](https://github.com/Zxilly/go-size-analyzer/actions/workflows/built-tests.yml)
[![Codecov](https://img.shields.io/codecov/c/gh/Zxilly/go-size-analyzer)](https://codecov.io/github/Zxilly/go-size-analyzer)
[![GitHub release](https://img.shields.io/github/v/release/Zxilly/go-size-analyzer)](https://github.com/Zxilly/go-size-analyzer/releases)
[![go-recipes](https://raw.githubusercontent.com/nikolaydubina/go-recipes/main/badge.svg?raw=true)](https://github.com/nikolaydubina/go-recipes?tab=readme-ov-file#-visualise-dependencies-size-in-compiled-binaries-with-go-size-analyzer)
[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/Zxilly/go-size-analyzer/badge)](https://scorecard.dev/viewer/?uri=github.com/Zxilly/go-size-analyzer)

English | [简体中文](./README_zh_CN.md)

A simple tool to analyze the size of a Go compiled binary.

- [x] Cross-platform support for analyzing `ELF`, `Mach-O`, `PE` and `WebAssembly (experimental)` binary formats
- [x] Detailed size breakdown by packages and sections
- [x] Support multiple output formats: `text`, `json`, `html`, `svg`
- [x] Interactive exploration via web interface and terminal UI
- [x] Binary comparison with diff mode (supports `json` and `text` output)

## Installation

[![Packaging status](https://repology.org/badge/vertical-allrepos/go-size-analyzer.svg)](https://repology.org/project/go-size-analyzer/versions)

### [Download the latest binary](https://github.com/Zxilly/go-size-analyzer/releases)

### MacOS / Linux via Homebrew:

Using [Homebrew](https://brew.sh/)
```
brew install go-size-analyzer
```

### Windows:

Using [scoop](https://scoop.sh/)
```
scoop install go-size-analyzer
```

### Go Install:
```
go install github.com/Zxilly/go-size-analyzer/cmd/gsa@latest
```

## Usage

### Example

#### Web mode

```bash
$ gsa --web golang-compiled-binary
```

Will start a web server on port 8080, you can view the result in your browser.

Or you can use the WebAssembly version in the browser: [GSA Treemap](https://gsa.zxilly.dev)

> [!NOTE]  
> Due to the limitation of the browser, the WebAssembly version is much slower than the native version.
> Normally costs 10x time to analyze the same binary.
> 
> Only recommended for analysing small applications (less than 30 MB in size)

The web page will look like this:

![image](https://github.com/Zxilly/go-size-analyzer/assets/31370133/e69583ce-b189-4a0d-b108-c3b7d5c33a82)

You can click to expand the package to see the details.

#### Terminal UI

```bash
$ gsa --tui golang-compiled-binary
```

[![asciicast](https://asciinema.org/a/670664.svg)](https://asciinema.org/a/670664)

#### Text mode 

```bash
$ gsa docker-compose-linux-x86_64
┌─────────────────────────────────────────────────────────────────────────────────┐
│ docker-compose-linux-x86_64                                                     │
├─────────┬──────────────────────────────────────────────────┬────────┬───────────┤
│ PERCENT │ NAME                                             │ SIZE   │ TYPE      │
├─────────┼──────────────────────────────────────────────────┼────────┼───────────┤
│ 17.37%  │ k8s.io/api                                       │ 11 MB  │ vendor    │
│ 15.52%  │ .rodata                                          │ 9.8 MB │ section   │
│ 8.92%   │ .gopclntab                                       │ 5.6 MB │ section   │
│ 7.51%   │ .strtab                                          │ 4.7 MB │ section   │
│ 5.13%   │ k8s.io/client-go                                 │ 3.2 MB │ vendor    │
│ 3.36%   │ .symtab                                          │ 2.1 MB │ section   │
│ 3.29%   │ github.com/moby/buildkit                         │ 2.1 MB │ vendor    │
│ 2.02%   │ google.golang.org/protobuf                       │ 1.3 MB │ vendor    │
│ 1.96%   │ github.com/google/gnostic-models                 │ 1.2 MB │ vendor    │
│ 1.82%   │ k8s.io/apimachinery                              │ 1.1 MB │ vendor    │
│ 1.73%   │ net                                              │ 1.1 MB │ std       │
│ 1.72%   │ github.com/aws/aws-sdk-go-v2                     │ 1.1 MB │ vendor    │
│ 1.57%   │ crypto                                           │ 991 kB │ std       │
│ 1.53%   │ github.com/docker/compose/v2                     │ 964 kB │ vendor    │
│ 1.48%   │ github.com/gogo/protobuf                         │ 931 kB │ vendor    │
│ 1.40%   │ runtime                                          │ 884 kB │ std       │
│ 1.32%   │ go.opentelemetry.io/otel                         │ 833 kB │ vendor    │
│ 1.28%   │ .text                                            │ 809 kB │ section   │
│ 1.18%   │ google.golang.org/grpc                           │ 742 kB │ vendor    │

...[Collapsed]...

│ 0.00%   │ github.com/google/shlex                          │ 0 B    │ vendor    │
│ 0.00%   │ github.com/pmezard/go-difflib                    │ 0 B    │ vendor    │
│ 0.00%   │ go.uber.org/mock                                 │ 0 B    │ vendor    │
│ 0.00%   │ github.com/kballard/go-shellquote                │ 0 B    │ vendor    │
│ 0.00%   │ tags.cncf.io/container-device-interface          │ 0 B    │ vendor    │
│ 0.00%   │ github.com/josharian/intern                      │ 0 B    │ vendor    │
│ 0.00%   │ github.com/shibumi/go-pathspec                   │ 0 B    │ vendor    │
│ 0.00%   │ dario.cat/mergo                                  │ 0 B    │ vendor    │
│ 0.00%   │ github.com/mattn/go-colorable                    │ 0 B    │ vendor    │
│ 0.00%   │ github.com/secure-systems-lab/go-securesystemslib│ 0 B    │ vendor    │
├─────────┼──────────────────────────────────────────────────┼────────┼───────────┤
│ 100%    │ KNOWN                                            │ 63 MB  │           │
│ 100%    │ TOTAL                                            │ 63 MB  │           │
└─────────┴──────────────────────────────────────────────────┴────────┴───────────┘

```

#### Diff Mode

```bash
$ gsa bin-linux-1.21-amd64 bin-linux-1.22-amd64
┌────────────────────────────────────────────────────────────────┐
│ Diff between bin-linux-1.21-amd64 and bin-linux-1.22-amd64     │
├─────────┬──────────────────────┬──────────┬──────────┬─────────┤
│ PERCENT │ NAME                 │ OLD SIZE │ NEW SIZE │ DIFF    │
├─────────┼──────────────────────┼──────────┼──────────┼─────────┤
│ +28.69% │ runtime              │ 801 kB   │ 1.0 MB   │ +230 kB │
│ +100%   │ internal/chacha8rand │          │ 3.1 kB   │ +3.1 kB │
│ +5.70%  │ <autogenerated>      │ 18 kB    │ 19 kB    │ +1.0 kB │
│ +8.59%  │ internal/abi         │ 6.1 kB   │ 6.6 kB   │ +525 B  │
│ +10.52% │ internal/cpu         │ 4.9 kB   │ 5.4 kB   │ +515 B  │
│ +4.45%  │ internal/reflectlite │ 3.9 kB   │ 4.1 kB   │ +173 B  │
│ +2.64%  │ internal/bytealg     │ 1.5 kB   │ 1.5 kB   │ +39 B   │
│ +0.80%  │ strconv              │ 4.0 kB   │ 4.0 kB   │ +32 B   │
│ +0.19%  │ syscall              │ 13 kB    │ 13 kB    │ +24 B   │
│ -0.37%  │ embed                │ 8.6 kB   │ 8.6 kB   │ -32 B   │
│ -0.16%  │ main                 │ 19 kB    │ 19 kB    │ -32 B   │
│ -0.38%  │ reflect              │ 25 kB    │ 25 kB    │ -96 B   │
│ -0.26%  │ time                 │ 87 kB    │ 87 kB    │ -224 B  │
│ -7.95%  │ sync                 │ 9.5 kB   │ 8.7 kB   │ -755 B  │
├─────────┼──────────────────────┼──────────┼──────────┼─────────┤
│ +8.47%  │ .rodata              │ 122 kB   │ 132 kB   │ +10 kB  │
│ +5.04%  │ .gopclntab           │ 144 kB   │ 152 kB   │ +7.3 kB │
│ +3.61%  │ .debug_info          │ 168 kB   │ 174 kB   │ +6.1 kB │
│ +3.52%  │ .debug_loc           │ 81 kB    │ 84 kB    │ +2.9 kB │
│ +3.03%  │ .debug_line          │ 80 kB    │ 82 kB    │ +2.4 kB │
│ +3.41%  │ .symtab              │ 59 kB    │ 61 kB    │ +2.0 kB │
│ +4.29%  │ .debug_frame         │ 29 kB    │ 30 kB    │ +1.2 kB │
│ +1.25%  │ .strtab              │ 61 kB    │ 62 kB    │ +763 B  │
│ +3.28%  │ .debug_ranges        │ 13 kB    │ 13 kB    │ +415 B  │
│ +5.13%  │ .data                │ 5.0 kB   │ 5.2 kB   │ +256 B  │
│ +7.32%  │ .typelink            │ 1.3 kB   │ 1.3 kB   │ +92 B   │
│ +27.78% │ .go.buildinfo        │ 288 B    │ 368 B    │ +80 B   │
│ -1.56%  │ .debug_gdb_scripts   │ 64 B     │ 63 B     │ -1 B    │
│ -0.63%  │ .noptrdata           │ 2.5 kB   │ 2.5 kB   │ -16 B   │
├─────────┼──────────────────────┼──────────┼──────────┼─────────┤
│ +3.86%  │ bin-linux-1.21-amd64 │ 1.6 MB   │ 1.6 MB   │ +61 kB  │
│         │ bin-linux-1.22-amd64 │          │          │         │
└─────────┴──────────────────────┴──────────┴──────────┴─────────┘
```

#### Svg Mode

```bash
$ gsa cockroach-darwin-amd64 -f svg -o data.svg --hide-sections
```

![image](./assets/example.svg)

### Full options

```bash
A tool for determining the extent to which dependencies contribute to the
bloated size of compiled Go binaries.

Arguments:
  <file>           Binary file to analyze or result json file for diff
  [<diff file>]    New binary file or result json file to compare, optional

Flags:
  -h, --help             Show context-sensitive help.
      --verbose          Verbose output
  -f, --format="text"    Output format, possible values: text,json,html,svg
      --no-disasm        Skip disassembly pass
      --no-symbol        Skip symbol pass
      --no-dwarf         Skip dwarf pass
  -o, --output=STRING    Write to file
      --version          Show version

Text output options
  --hide-sections    Hide sections
  --hide-main        Hide main package
  --hide-std         Hide standard library

Json output options
  --indent=INDENT    Indentation for json output
  --compact          Hide function details, replacement with size

Svg output options
  --width=1028         Width of the svg treemap
  --height=640         Height of the svg treemap
  --margin-box=4       Margin between boxes
  --padding-box=4      Padding between box border and content
  --padding-root=32    Padding around root content

Web interface options
  --web               use web interface to explore the details
  --listen=":8080"    listen address
  --open              Open browser
  --update-cache      Update the cache file for the web UI

Terminal interface options
  --tui    Use terminal interface to explore the details

Imports analysis options
  --imports    Try analyze package imports from source

```

> [!CAUTION]
>
> The tool can work with stripped binaries, but it may lead to inaccurate results.

## TODO

- [ ] Add more pattern for disassembling the binary
- [x] Extract the information from the DWARF section
- [x] Count the symbol size itself to package
- [ ] Add other charts like flame graph, pie chart, etc.
- [ ] Support C++/Rust symbol demangling in cgo
- [x] Add a TUI mode for exploring details
- [x] Compile to wasm, create a ui to analyze the binary in the browser

## Contribution

Any contribution is welcome, feel free to open an issue or a pull request.

For development, see the [Development Guide](./DEVELOPMENT.md) for more details.

## LICENSE

Published under the [AGPL-3.0](./LICENSE).

### Supported by

[![JetBrains logo.](https://resources.jetbrains.com/storage/products/company/brand/logos/jetbrains.svg)](https://jb.gg/OpenSourceSupport)

go-size-analyzer

Swagger 2.0 implementation for go. Swagger is a simple yet powerful representation of your RESTful API

# Swagger 2.0


[![Tests][test-badge]][test-url] [![Coverage][cov-badge]][cov-url] [![CI vuln scan][vuln-scan-badge]][vuln-scan-url] [![CodeQL][codeql-badge]][codeql-url]

[![Release][release-badge]][release-url] [![Container Registry on Quay.io][quay-badge]][quay-url] [![Container Registry on Github][ghcr-badge]][ghcr-url]

[![Go Report Card][gocard-badge]][gocard-url] [![CodeFactor Grade][codefactor-badge]][codefactor-url]

[![License][license-badge]][license-url] [![Open SSF Scorecard][ossf-badge]][ossf-url] [![OpenSSF Best Practices][ossf-cci-badge]][ossf-cci-url] [![OpenSSF Baseline][ossf-baseline]][ossf-cci-url] [![OSS licences status][fossa-badge]][fossa-url]


[![Documentation][doc-badge]][doc-url] [![GoDoc][godoc-badge]][godoc-url] [![Discord Channel][discord-badge]][discord-url] [![go version][goversion-badge]][goversion-url] ![Top language][top-badge] ![Commits since latest release][commits-badge]

---

This project contains a golang implementation of Swagger 2.0 (aka [OpenAPI 2.0](https://github.com/OAI/OpenAPI-Specification/blob/old-v3.2.0-dev/versions/2.0.md)).
It provide tools to work with swagger specifications.

[Swagger](https://swagger.io/) is a simple yet powerful representation of your RESTful API.<br>

## Announcements

* **2026-03-16** : v0.33.2 is out
  * upgraded requirement to `go1.25`
  * bug fix release
  * changes in our release workflow:
    * releases and tags are signed
    * all released artifacts are now signed. Signatures may be checked against `.sig` artifacts.
    * deb and rpm packages are available on a new package name `go-swagger` instead of `swagger`
    * docker images now embarks a go installation (required to generate code)
    * binary releases now ship as tarballs. See the [updated installation instructions](https://goswagger.io/go-swagger/install/install-binary)
    * for convenience, plain binaries with the pre-existing OS/arch naming convention has been maintained for now
  * removed dependencies:
    * mongodb driver (**NOT BREAKING**: see also <https://github.com/go-openapi/strfmt#announcements> for support
      of drivers updates)
    * `mailru/easyjson`: not longer imported by default. See <https://github.com/go-openapi/swag?tab=readme-ov-file#dependencies>
      to enact `mailru/easyjson` explicitly.

* **2026-03-16** : new community chat on discord
  * a new discord community channel is available to be notified of changes and support users
  * our venerable Slack channel remains open, and will be eventually discontinued on **2026-06-30**
  * (for go-openapi libraries we'll stop Slack on **2026-03-31**).

You may join the discord community by clicking the invite link on the discord badge (also above). [![Discord Channel][discord-badge]][discord-url].

Or join our Slack channel: [![Slack Channel][slack-logo]![slack-badge]][slack-url].

## Documentation

<https://goswagger.io>

##  Features

`go-swagger` brings to the go community a complete suite of fully-featured, high-performance, API components to  work with a Swagger API: server, client and data model.

* Generates a server from a swagger specification
* Generates a client from a swagger specification
* Generates a CLI (command line tool) from a swagger specification (alpha stage)
* Supports most features offered by jsonschema and swagger, including polymorphism
* Generates a swagger specification from annotated go code
* Additional tools to work with a swagger spec
* Great customization features, with vendor extensions and customizable templates

Our focus with code generation is to produce idiomatic, fast go code, which plays nice with golint, go vet etc.

[More details](https://goswagger.io/go-swagger/features).

##  Project status

This project supports OpenAPI 2.0. **At this moment it does not support OpenAPI 3.x**.

`go-swagger` is now feature complete and has stabilized its API.

Most features and building blocks are now in a stable state, with a rich set of CI tests.

The go-openapi community actively continues bringing fixes and enhancements to this code base.

There is still much room for improvement: contributors and PR's are welcome. You may also get in touch with maintainers on [our slack channel](https://slackin.goswagger.io).

## Installing

```sh
go install github.com/go-swagger/go-swagger/cmd/swagger@latest
```

`go-swagger` is also available as binary or docker releases as well as from source: [more details](https://goswagger.io/go-swagger/install).

## Try it

Try `go-swagger` in a free online workspace using Gitpod:

[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io#https://github.com/go-swagger/go-swagger)

## Licensing

The toolkit itself is licensed under an Apache Software License 2.0:
[SPDX-License-Identifier: Apache-2.0](./LICENSE).

Just like swagger, this does not cover code generated by the toolkit. That code is entirely yours to license however you see fit.

### Licence scan on dependencies 

[![FOSSA Status][fossa-badge-large]][fossa-url-large]


[test-badge]: https://github.com/go-swagger/go-swagger/actions/workflows/test.yaml/badge.svg
[test-url]: https://github.com/go-swagger/go-swagger/actions/workflows/test.yaml
[cov-badge]: https://codecov.io/gh/go-swagger/go-swagger/branch/master/graph/badge.svg
[cov-url]: https://codecov.io/gh/go-swagger/go-swagger
[vuln-scan-badge]: https://github.com/go-swagger/go-swagger/actions/workflows/scanner.yaml/badge.svg
[vuln-scan-url]: https://github.com/go-swagger/go-swagger/actions/workflows/scanner.yaml
[codeql-badge]: https://github.com/go-swagger/go-swagger/actions/workflows/codeql.yaml/badge.svg
[codeql-url]: https://github.com/go-swagger/go-swagger/actions/workflows/codeql.yaml

[release-badge]: https://badge.fury.io/gh/go-swagger%2Fgo-swagger.svg
[release-url]: https://badge.fury.io/gh/go-swagger%2Fgo-swagger
[quay-badge]: https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fquay.io%2Fapi%2Fv1%2Frepository%2Fgoswagger%2Fswagger%2Ftag%2F%3Flimit%3D1%26onlyActiveTags%3Dtrue%26filter_tag_name%3Dlike%3Av&label=Container%20Registry%20on%20quay.io&query=%24.tags[:1].name&logo=redhatopenshift&logoColor=#EE0000?color=green
[quay-url]: https://quay.io/repository/goswagger/swagger?tab=tags
[ghcr-badge]: https://ghcr-badge-ipv2.onrender.com/go-swagger/go-swagger/latest_tag?ignore=sha-*,edge,master&label=Container%20Registry%20on%20Github
[ghcr-url]: https://github.com/orgs/go-swagger/packages/container/go-swagger/versions?filters[version_type]=tagged

[gocard-badge]: https://goreportcard.com/badge/github.com/go-swagger/go-swagger
[gocard-url]: https://goreportcard.com/report/github.com/go-swagger/go-swagger
[codefactor-badge]: https://img.shields.io/codefactor/grade/github/go-swagger/go-swagger
[codefactor-url]: https://www.codefactor.io/repository/github/go-swagger/go-swagger

[doc-badge]: https://img.shields.io/badge/doc-site-blue?link=https%3A%2F%2Fgoswagger.io%2Fgo-swagger%2F
[doc-url]: https://goswagger.io/go-swagger
[godoc-badge]: https://godoc.org/github.com/go-swagger/go-swagger?status.svg
[godoc-url]: http://godoc.org/github.com/go-swagger/go-swagger
[slack-logo]: https://a.slack-edge.com/e6a93c1/img/icons/favicon-32.png
[slack-badge]: https://img.shields.io/badge/slack-blue?link=https%3A%2F%2Fgoswagger.slack.com%2Farchives%2FC04R30YM
[slack-url]: https://goswagger.slack.com/archives/C04R30YMU
[discord-badge]: https://img.shields.io/discord/1446918742398341256?logo=discord&label=discord&color=blue
[discord-url]: https://discord.gg/FfnFYaC3k5

[license-badge]: http://img.shields.io/badge/license-Apache%20v2-orange.svg
[license-url]: https://github.com/go-swagger/go-swagger/?tab=Apache-2.0-1-ov-file#readme
[ossf-badge]: https://api.securityscorecards.dev/projects/github.com/go-swagger/go-swagger/badge
[ossf-url]: https://securityscorecards.dev/viewer/?uri=github.com/go-swagger/go-swagger
[ossf-cci-badge]: https://www.bestpractices.dev/projects/11359/badge
[ossf-cci-url]: https://www.bestpractices.dev/projects/11359
[ossf-baseline]: https://www.bestpractices.dev/projects/11359/baseline
[fossa-badge]: https://app.fossa.io/api/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger.svg?type=shield
[fossa-url]: https://app.fossa.io/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger?ref=badge_shield
[fossa-badge-large]: https://app.fossa.io/api/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger.svg?type=large
[fossa-url-large]: https://app.fossa.io/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger?ref=badge_large
[oai-url]: https://raw.githubusercontent.com/swagger-api/swagger-spec/master/LICENSE

[goversion-badge]: https://img.shields.io/github/go-mod/go-version/go-swagger/go-swagger
[goversion-url]: https://github.com/go-swagger/go-swagger/blob/master/go.mod
[top-badge]: https://img.shields.io/github/languages/top/go-swagger/go-swagger
[commits-badge]: https://img.shields.io/github/commits-since/go-swagger/go-swagger/latest

go-swagger

Wrapper around `go` command for colorized `go build` output.

# colorgo
`colorgo` is a wrapper to `go` command that colorizes output from `go build` and `go test`.
![screenshot 1](http://songgao.github.com/colorgo/images/screenshot1.png)

# Installation
```
go get -u github.com/songgao/colorgo
```

# Usage
```bash
colorgo build
```

# alias
`colorgo` changes nothing to sub-commands other than `go build`. So you can optionally define alias in your shell conf so that `go build` always prints colorized error message:

bash: `~/.bashrc`
```
alias go=colorgo
```

fish-shell: `~/.config/fish/config.fish`
```
alias go colorgo
```

# License
[BSD 3-Clause License](http://opensource.org/licenses/BSD-3-Clause)


colorgo

Find “overspecified” function parameters that could be generalized with interface types

# Decouple - find overspecified function parameters in Go code

[![Go Reference](https://pkg.go.dev/badge/github.com/bobg/decouple.svg)](https://pkg.go.dev/github.com/bobg/decouple)
[![Go Report Card](https://goreportcard.com/badge/github.com/bobg/decouple)](https://goreportcard.com/report/github.com/bobg/decouple)
[![Tests](https://github.com/bobg/decouple/actions/workflows/go.yml/badge.svg)](https://github.com/bobg/decouple/actions/workflows/go.yml)
[![Coverage Status](https://coveralls.io/repos/github/bobg/decouple/badge.svg?branch=main)](https://coveralls.io/github/bobg/decouple?branch=main)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

This is decouple,
a Go package and command that analyzes your Go code
to find “overspecified” function parameters.

A parameter is overspecified,
and eligible for “decoupling,”
if it has a more-specific type than it actually needs.

For example,
if your function takes a `*os.File` parameter,
but it’s only ever used for its `Read` method,
it could be specified as an abstract `io.Reader` instead.

## Why decouple?

When you decouple a function parameter from its too-specific type,
you broaden the set of values on which it can operate.

You also make it easier to test.
For a simple example,
suppose you’re testing this function:

```go
func CountLines(f *os.File) (int, error) {
  var result int
  sc := bufio.NewScanner(f)
  for sc.Scan() {
    result++
  }
  return result, sc.Err()
}
```

Your unit test will need to open a testdata file and pass it to this function to get a result.
But as `decouple` can tell you,
`f` is only ever used as an `io.Reader`
(the type of the argument to [bufio.NewScanner](https://pkg.go.dev/bufio#NewScanner)).

If you were testing `func CountLines(r io.Reader) (int, error)` instead,
the unit test can simply pass it something like `strings.NewReader("a\nb\nc")`.

## Installation

```sh
go install github.com/bobg/decouple/cmd/decouple@latest
```

## Usage

```sh
decouple [-v] [-json] [DIR]
```

This produces a report about the Go packages rooted at DIR
(the current directory by default).
With -v,
very verbose debugging output is printed along the way.
With -json,
the output is in JSON format.

The report will be empty if decouple has no findings.
Otherwise, it will look something like this (without -json):

```
$ decouple
/home/bobg/kodigcs/handle.go:105:18: handleDir
    req: [Context]
    w: io.Writer
/home/bobg/kodigcs/handle.go:167:18: handleNFO
    req: [Context]
    w: [Header Write]
/home/bobg/kodigcs/handle.go:428:6: isStale
    t: [Before]
/home/bobg/kodigcs/imdb.go:59:6: parseIMDbPage
    cl: [Do]
```

This is the output when running decouple on [the current commit](https://github.com/bobg/kodigcs/commit/f4e8cf0e44de0ea98fa7ad4f88705324ff446444)
of [kodigcs](https://github.com/bobg/kodigcs).
It’s saying that:

- In the function [handleDir](https://github.com/bobg/kodigcs/blob/f4e8cf0e44de0ea98fa7ad4f88705324ff446444/handle.go#L105),
  the `req` parameter is being used only for its `Context` method
  and so could be declared as `interface{ Context() context.Context }`,
  allowing objects other than `*http.Request` values to be passed in here
  (or, better still, the function could be rewritten to take a `context.Context` parameter instead);
- Also in [handleDir](https://github.com/bobg/kodigcs/blob/f4e8cf0e44de0ea98fa7ad4f88705324ff446444/handle.go#L105),
  `w` could be an `io.Writer`,
  allowing more types to be used than just `http.ResponseWriter`;
- Similarly in [handleNFO](https://github.com/bobg/kodigcs/blob/f4e8cf0e44de0ea98fa7ad4f88705324ff446444/handle.go#L167),
  `req` is used only for its `Context` method,
  and `w` for its `Write` and `Header` methods
  (more than `io.Writer`, but less than `http.ResponseWriter`);
- Anything with a `Before(time.Time) bool` method
  could be used in [isStale](https://github.com/bobg/kodigcs/blob/f4e8cf0e44de0ea98fa7ad4f88705324ff446444/handle.go#L428),
  it does not need to be limited to `time.Time`;
- The `*http.Client` argument of [parseIMDbPage](https://github.com/bobg/kodigcs/blob/f4e8cf0e44de0ea98fa7ad4f88705324ff446444/imdb.go#L59)
  is being used only for its `Do` method.

Note that,
in the report,
the presence of square brackets means “this is a set of methods,”
while the absence of them means “this is an existing type that already has the right method set”
(as in the `io.Writer` line in the example above).
Decouple can’t always find a suitable existing type even when one exists,
and if two or more types match,
it doesn’t always choose the best one.

The same report with `-json` specified looks like this:

```
{
  "PackageName": "main",
  "FileName": "/home/bobg/kodigcs/handle.go",
  "Line": 105,
  "Column": 18,
  "FuncName": "handleDir",
  "Params": [
    {
      "Name": "req",
      "Methods": [
        "Context"
      ]
    },
    {
      "Name": "w",
      "Methods": [
        "Write"
      ],
      "InterfaceName": "Writer",
      "InterfacePkg": "io"
    }
  ]
}
{
  "PackageName": "main",
  "FileName": "/home/bobg/kodigcs/handle.go",
  "Line": 167,
  "Column": 18,
  "FuncName": "handleNFO",
  "Params": [
    {
      "Name": "req",
      "Methods": [
        "Context"
      ]
    },
    {
      "Name": "w",
      "Methods": [
        "Header",
        "Write"
      ]
    }
  ]
}
{
  "PackageName": "main",
  "FileName": "/home/bobg/kodigcs/handle.go",
  "Line": 428,
  "Column": 6,
  "FuncName": "isStale",
  "Params": [
    {
      "Name": "t",
      "Methods": [
        "Before"
      ]
    }
  ]
}
{
  "PackageName": "main",
  "FileName": "/home/bobg/kodigcs/imdb.go",
  "Line": 59,
  "Column": 6,
  "FuncName": "parseIMDbPage",
  "Params": [
    {
      "Name": "cl",
      "Methods": [
        "Do"
      ]
    }
  ]
}
```

## Performance note

Replacing overspecified function parameters with more-abstract ones,
which this tool helps you to do,
is often but not always the right thing,
and it should not be done blindly.

Using Go interfaces can impose an _abstraction penalty_ compared to using concrete types.
Function arguments that could have been on [the stack](https://en.wikipedia.org/wiki/Stack-based_memory_allocation)
may end up in [the heap](https://en.wikipedia.org/wiki/Heap-based_memory_allocation),
and method calls may involve [a virtual-dispatch step](https://en.wikipedia.org/wiki/Dynamic_dispatch).

In many cases this penalty is small and can be ignored,
especially since the Go compiler may optimize some or all of it away.
But in tight inner loops
and other performance-critical code
it is often preferable to operate only on concrete types when possible.

That said,
avoid the fallacy of [premature optimization](https://wiki.c2.com/?PrematureOptimization).
Write your code for clarity and utility first.
Then sacrifice those for the sake of performance
not in the places where you _think_ they’ll make a difference,
but in the places where you’ve _measured_ that they’re needed.


decouple

Visualize dependency trees of any package by analyzing imports.

# depth 

[![GoDoc](https://godoc.org/github.com/KyleBanks/depth?status.svg)](https://godoc.org/github.com/KyleBanks/depth)&nbsp; 
[![Build Status](https://travis-ci.org/KyleBanks/depth.svg?branch=master)](https://travis-ci.org/KyleBanks/depth)&nbsp;
[![Go Report Card](https://goreportcard.com/badge/github.com/KyleBanks/depth)](https://goreportcard.com/report/github.com/KyleBanks/depth)&nbsp;
[![Coverage Status](https://coveralls.io/repos/github/KyleBanks/depth/badge.svg?branch=master)](https://coveralls.io/github/KyleBanks/depth?branch=master)

`depth` is tool to retrieve and visualize Go source code dependency trees.

## Install

Download the appropriate binary for your platform from the [Releases](https://github.com/KyleBanks/depth/releases) page, or:

```sh
go get github.com/KyleBanks/depth/cmd/depth
```

## Usage

`depth` can be used as a standalone command-line application, or as a package within your own project.

### Command-Line

Simply execute `depth` with one or more package names to visualize. You can use the fully qualified import path of the package, like so:

```sh
$ depth github.com/KyleBanks/depth/cmd/depth
github.com/KyleBanks/depth/cmd/depth
  ├ encoding/json
  ├ flag
  ├ fmt
  ├ io
  ├ log
  ├ os
  ├ strings
  └ github.com/KyleBanks/depth
    ├ fmt
    ├ go/build
    ├ path
    ├ sort
    └ strings
12 dependencies (11 internal, 1 external, 0 testing).
```

Or you can use a relative path, for example:

```sh
$ depth .
$ depth ./cmd/depth
$ depth ../
```

You can also use `depth` on the Go standard library:

```sh
$ depth strings
strings
  ├ errors
  ├ internal/bytealg
  ├ io
  ├ sync
  ├ unicode
  ├ unicode/utf8
  └ unsafe
7 dependencies (7 internal, 0 external, 0 testing).
```

Visualizing multiple packages at a time is supported by simply naming the packages you'd like to visualize:

```sh
$ depth strings github.com/KyleBanks/depth 
strings
  ├ errors
  ├ internal/bytealg
  ├ io
  ├ sync
  ├ unicode
  ├ unicode/utf8
  └ unsafe
7 dependencies (7 internal, 0 external, 0 testing).
github.com/KyleBanks/depth
  ├ bytes
  ├ errors
  ├ go/build
  ├ os
  ├ path
  ├ sort
  └ strings
7 dependencies (7 internal, 0 external, 0 testing).
```

#### `-internal`

By default, `depth` only resolves the top level of dependencies for standard library packages, however you can use the `-internal` flag to visualize all internal dependencies:

```sh
$ depth -internal strings
strings
  ├ errors
  │ └ internal/reflectlite
  │   ├ internal/unsafeheader
  │   │ └ unsafe
  │   ├ runtime
  │   │ ├ internal/abi
  │   │ │ └ unsafe
  │   │ ├ internal/bytealg
  │   │ │ ├ internal/cpu
  │   │ │ └ unsafe
  │   │ ├ internal/cpu
  │   │ ├ internal/goexperiment
  │   │ ├ runtime/internal/atomic
  │   │ │ └ unsafe
  │   │ ├ runtime/internal/math
  │   │ │ └ runtime/internal/sys
  │   │ ├ runtime/internal/sys
  │   │ └ unsafe
  │   └ unsafe
  ├ internal/bytealg
  ├ io
  │ ├ errors
  │ └ sync
  │   ├ internal/race
  │   │ └ unsafe
  │   ├ runtime
  │   ├ sync/atomic
  │   │ └ unsafe
  │   └ unsafe
  ├ sync
  ├ unicode
  ├ unicode/utf8
  └ unsafe
18 dependencies (18 internal, 0 external, 0 testing).
```

#### `-max` 

The `-max` flag limits the dependency tree to the maximum depth provided. For example, if you supply `-max 1` on the `depth` package, your output would look like so:

```
$ depth -max 1 github.com/KyleBanks/depth/cmd/depth
github.com/KyleBanks/depth/cmd/depth
  ├ encoding/json
  ├ flag
  ├ fmt
  ├ io
  ├ log
  ├ os
  ├ strings
  └ github.com/KyleBanks/depth
7 dependencies (6 internal, 1 external, 0 testing).
```

The `-max` flag is particularly useful in conjunction with the `-internal` flag which can lead to very deep dependency trees.

#### `-test`

By default, `depth` ignores dependencies that are only required for testing. However, you can view test dependencies using the `-test` flag:

```sh
$ depth -test strings
strings
  ├ bytes
  ├ errors
  ├ fmt
  ├ internal/bytealg
  ├ internal/testenv
  ├ io
  ├ math/rand
  ├ reflect
  ├ strconv
  ├ sync
  ├ testing
  ├ unicode
  ├ unicode/utf8
  └ unsafe
14 dependencies (14 internal, 0 external, 7 testing).
```

#### `-explain target-package`

The `-explain` flag instructs `depth` to print import chains in which the
`target-package` is found:

```sh
$ depth -explain strings github.com/KyleBanks/depth/cmd/depth
github.com/KyleBanks/depth/cmd/depth -> strings
github.com/KyleBanks/depth/cmd/depth -> github.com/KyleBanks/depth -> strings
```

#### `-json`

The `-json` flag instructs `depth` to output dependencies in JSON format:

```sh
$ depth -json github.com/KyleBanks/depth/cmd/depth
{
  "name": "github.com/KyleBanks/depth/cmd/depth",
  "deps": [
    {
      "name": "encoding/json",
      "internal": true,
      "deps": null
    },
    ...
    {
      "name": "github.com/KyleBanks/depth",
      "internal": false,
      "deps": [
        {
          "name": "go/build",
          "internal": true,
          "deps": null
        },
        ...
      ]
    }
  ]
}
```

### Integrating With Your Project

The `depth` package can easily be used to retrieve the dependency tree for a particular package in your own project. For example, here's how you would retrieve the dependency tree for the `strings` package:

```go
import "github.com/KyleBanks/depth"

var t depth.Tree
err := t.Resolve("strings")
if err != nil {
    log.Fatal(err)
}

// Output: "'strings' has 4 dependencies."
log.Printf("'%v' has %v dependencies.", t.Root.Name, len(t.Root.Deps)) 
```

For additional customization, simply set the appropriate flags on the `Tree` before resolving:

```go
import "github.com/KyleBanks/depth"

t := depth.Tree {
  ResolveInternal: true,
  ResolveTest: true,
  MaxDepth: 10,
}


err := t.Resolve("strings")
```

## Author

`depth` was developed by [Kyle Banks](https://twitter.com/kylewbanks).

## License

`depth` is available under the [MIT](./LICENSE) license.


depth

Automatically generate RESTful API documentation for GO projects - aligned with Open API Specification standard

# docs

### Automatically generate RESTful API documentation for GO projects - aligned with [Open API Specification standard](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md).

<img align="right" width="180px" src="https://raw.githubusercontent.com/kaynetik/dotfiles/master/svg-resources/go-grpc-web.svg">

![GolangCI](https://github.com/go-oas/docs/workflows/golangci/badge.svg?branch=main)
![Build](https://github.com/go-oas/docs/workflows/Build/badge.svg?branch=main)
[![Version](https://img.shields.io/badge/version-v1.0.5-success.svg)](https://github.com/go-oas/docs/releases)
[![Go Report Card](https://goreportcard.com/badge/github.com/go-oas/docs)](https://goreportcard.com/report/github.com/go-oas/docs)
[![Coverage Status](https://coveralls.io/repos/github/go-oas/docs/badge.svg?branch=main)](https://coveralls.io/github/go-oas/docs?branch=main)
[![codebeat badge](https://codebeat.co/badges/32b86556-84e3-4db9-9f11-923d12994f90)](https://codebeat.co/projects/github-com-go-oas-docs-main)
[![Go Reference](https://pkg.go.dev/badge/github.com/go-oas/docs.svg)](https://pkg.go.dev/github.com/go-oas/docs)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://awesome-go.com)

go-OAS Docs converts structured OAS3 (Swagger3) objects into the Open API Specification & automatically serves it on
chosen route and port. It's extremely flexible and simple, so basically it can be integrated into any framework or
existing project.

We invite anyone interested to join our **[GH Discussions board](https://github.com/go-oas/docs/discussions)**. Honest
feedback will enable us to build better product and at the same time not waste valuable time and effort on something
that might not fit intended usage. So if you can, please spare few minutes to give your opinion of what should be done
next, or what should be the priority for our roadmap. :muscle: :tada:

----

## Table of Contents

- [Getting Started](#getting-started)
- [How to use](#how-to-use)
    * [Examples](#examples)
- [Contact](#contact)
- [The current roadmap (planned features)](#roadmap)

## Getting Started

1. Download **_docs_** by using:
   ```sh
   $ go get -u github.com/go-oas/docs
   ``` 
2. Add one line annotation to the handler you wish to use in the following
   format: `// @OAS <FUNC_NAME> <ROUTE> <HTTP_METHOD>`
   Examples:
   ```
   // @OAS handleCreateUser /users POST
   // @OAS handleGetUser /users GET
   ```
3. Declare all required documentation elements that are shared. Or reuse ones that already exist in the examples
   directory.
4. Declare specific docs elements per route.

----

## How to use

For more explicit example, please refer to [docs/examples](https://github.com/go-oas/docs/examples)

Add OAS TAG to your existing handler that handles fetching of a User:

```go
package users

import "net/http"

// @OAS handleGetUser /users GET
func (s *service) handleGetUser() http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
	}
}
```

Create a unique API documentation function for that endpoint:

```go
package main

import "github.com/go-oas/docs"

func handleGetUserRoute(oasPathIndex int, oas *docs.OAS) {
	path := oas.GetPathByIndex(oasPathIndex)

	path.Summary = "Get a User"
	path.OperationID = "getUser"
	path.RequestBody = docs.RequestBody{}
	path.Responses = docs.Responses{
		getResponseOK(),
	}

	path.Tags = append(path.Tags, "pet")
}
```

Bear in mind that creating a unique function per endpoint handler is not required, but simply provides good value in
usability of shared documentation elements.

Once you created the function, simply register it for parsing by using `AttachRoutes()` defined upon `OAS` structure.
E.g.:

```go

package main

import (
	"github.com/go-oas/docs"
)

func main() {
	apiDoc := docs.New()
	apiDoc.AttachRoutes([]interface{}{
		handleGetUserRoute,
	})
```

If this approach is too flexible for you, you are always left with the possibility to create your own attacher - or any
other parts of the system for that matter.

### Examples

To run examples, and checkout hosted documentation via Swagger UI, issue the following command:

```sh
$ go run ./examples/file_output/*.go
# or uncomment line 40 and comment line 38 in internal/dist/index.html before running:
$ go run ./examples/stream_output/*.go
```

And navigate to `http://localhost:3005/docs/api/` in case that you didn't change anything before running the example
above.

----

## Contact

Check out the current [Project board](https://github.com/go-oas/docs/projects/1) or
our **[GH Discussions board](https://github.com/go-oas/docs/discussions)** for more information.

You can join our Telegram group at: [https://t.me/go_oas](https://t.me/go_oas)

## Roadmap

| Feature (GH issues)                                             | Description                                                                              | Release |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------- |
| [Validation](https://github.com/go-oas/docs/issues/17)          | Add validation to all structures based on OAS3.0.3                                       | v1.1.0  |
| [CLI](https://github.com/go-oas/docs/issues/18)                 | Add CLI support - make it CLI friendly                                                   | v1.2.0  |
| [Postman](https://github.com/go-oas/docs/issues/19)             | Add postman support via PM API                                                           | v1.3.0  |
| [ReDoc](https://github.com/go-oas/docs/issues/20)               | Add ReDoc support as an alternative to SwaggerUI                                         | v1.4.0  |
| [E2E Auto-generation](https://github.com/go-oas/docs/issues/21) | Go tests conversion to Cypress/Katalon suites (convert mocked unit tests into e2e tests) | v1.5.0  |



docs

Visualize call graph of your Go program using dot format

<p align="center"><img src="images/gopher.png" alt="gopher"></p>

<h1 align="center">go-callvis</h1>

<p align="center">
  <a href="https://github.com/ondrajz/go-callvis/releases"><img src="https://img.shields.io/github/release/ondrajz/go-callvis.svg?label=latest%20release&logo=github&sort=semver&color=blue" alt="Github release"></a>
  <a href="https://github.com/ondrajz/go-callvis/actions"><img src="https://github.com/ondrajz/go-callvis/actions/workflows/ci.yml/badge.svg" alt="Build status"></a>
  <a href="https://github.com/nikolaydubina/go-recipes"><img src="https://raw.githubusercontent.com/nikolaydubina/go-recipes/main/badge.svg?raw=true" alt="go-recipes"></a>
  <a href="https://gophers.slack.com/archives/go-callvis"><img src="https://img.shields.io/badge/gophers%20slack-%23go--callvis-ff69b4.svg" alt="Slack channel"></a>
</p>

<p align="center"><b>go-callvis</b> is a development tool to help visualize call graph of a Go program using interactive view.</p>

---

## Introduction

The purpose of this tool is to provide developers with a visual overview of a Go program using data from call graph 
and its relations with packages and types. This is especially useful in larger projects where the complexity of 
the code much higher or when you are just simply trying to understand code of somebody else.

### Features

- click on package to quickly switch the focus using [interactive viewer](#interactive-viewer)
- focus specific package in the program
- group functions by package
- group methods by their receiver type
- filter packages to specific import path prefixes
- ignore calls to/from standard library
- omit various types of function calls

### Output preview

[![main](images/main.png)](images/main.png)

> Check out the [source code](examples/main) for the above image.

### How it works

It runs [pointer analysis](https://godoc.org/golang.org/x/tools/go/pointer) to construct the call graph of the program and 
uses the data to generate output in [dot format](http://www.graphviz.org/content/dot-language), which can be rendered with Graphviz tools.

## Quick start

### Installation

#### Requirements

- [Go](https://golang.org/dl/) 1.19+
- [Graphviz](http://www.graphviz.org/download/) (optional, required only with `-graphviz` flag)

To install go-callvis, run:

```sh
# Latest release
go install github.com/ofabry/go-callvis@latest

# Development version
go install github.com/ofabry/go-callvis@master
```

Alternatively, clone the repository and compile the source code:

```sh
# Clone repository
git clone https://github.com/ofabry/go-callvis.git
cd go-callvis

# Compile and install
make install
```

### Usage

#### Interactive viewer

To use the interactive view provided by a web server that serves SVG images of focused packages, you can simply run:

`go-callvis <target package>` 

HTTP server is listening on [http://localhost:7878/](http://localhost:7878/) by default, use option `-http="ADDR:PORT"` to change HTTP server address.

#### Render static output

To generate a single output file use option `-file=<file path>` to choose output file destination.

The output format defaults to `svg`, use option `-format=<svg|png|jpg|...>` to pick a different output format.

#### Options

```
Usage of go-callvis:
  -debug
    	Enable verbose log.
  -file string
    	output filename - omit to use server mode
  -cacheDir string
    	Enable caching to avoid unnecessary re-rendering.
  -focus string
    	Focus specific package using name or import path. (default "main")
  -format string
    	output file format [svg | png | jpg | ...] (default "svg")
  -graphviz
    	Use Graphviz's dot program to render images.
  -group string
    	Grouping functions by packages and/or types [pkg, type] (separated by comma) (default "pkg")
  -http string
    	HTTP service address. (default ":7878")
  -ignore string
    	Ignore package paths containing given prefixes (separated by comma)
  -include string
    	Include package paths with given prefixes (separated by comma)
  -limit string
    	Limit package paths to given prefixes (separated by comma)
  -minlen uint
    	Minimum edge length (for wider output). (default 2)
  -nodesep float
    	Minimum space between two adjacent nodes in the same rank (for taller output). (default 0.35)
  -nointer
    	Omit calls to unexported functions.
  -nostd
    	Omit calls to/from packages in standard library.
  -rankdir
        Direction of graph layout [LR | RL | TB | BT] (default "LR")
  -skipbrowser
    	Skip opening browser.
  -tags build tags
    	a list of build tags to consider satisfied during the build. For more information about build tags, see the description of build constraints in the documentation for the go/build package
  -tests
    	Include test code.
  -algo string
        Use specific algorithm for package analyzer: static, cha, rta or vta (default "static")
  -version
    	Show version and exit.
```

Run `go-callvis -h` to list all supported options.

## Reference guide

Here you can find descriptions for various types of output.

### Packages / Types

|Represents  | Style|
|----------: | :-------------|
|`focused`   | **blue** color|
|`stdlib`    | **green** color|
|`other`     | **yellow** color|

### Functions / Methods

|Represents   | Style|
|-----------: | :--------------|
|`exported`   | **bold** border|
|`unexported` | **normal** border|
|`anonymous`  | **dotted** border|

### Calls

|Represents   | Style|
|-----------: | :-------------|
|`internal`   | **black** color|
|`external`   | **brown** color|
|`static`     | **solid** line|
|`dynamic`    | **dashed** line|
|`regular`    | **simple** arrow|
|`concurrent` | arrow with **circle**|
|`deferred`   | arrow with **diamond**|

## Examples

Here is an example for the project [syncthing](https://github.com/syncthing/syncthing).

[![syncthing example](images/syncthing.png)](https://raw.githubusercontent.com/ondrajz/go-callvis/master/images/syncthing.png)

> Check out [more examples](examples) and used command options.

## Community

Join [#go-callvis](https://gophers.slack.com/archives/go-callvis) channel at [gophers.slack.com](http://gophers.slack.com). (*not a member yet?* [get invitation](https://gophersinvite.herokuapp.com))

### How to help

Did you find any bugs or have some suggestions?
- Feel free to open [new issue](https://github.com/ondrajz/go-callvis/issues/new) or start discussion in the slack channel.

Do you want to contribute to the project?
- Fork the repository and open a pull request. [Here](https://github.com/ondrajz/go-callvis/projects/1) you can find TODO features.

---

#### Roadmap

##### The *interactive tool* described below has been published as a *separate project* called [goexplorer](https://github.com/ondrajz/goexplorer)!

> Ideal goal of this project is to make web app that would locally store the call graph data and then provide quick access of the call graphs for any package of your dependency tree. At first it would show an interactive map of overall dependencies between packages and then by selecting particular package it would show the call graph and provide various options to alter the output dynamically.


go-callvis

Show Go test results as readable sentences

[![Go Reference](https://pkg.go.dev/badge/github.com/bitfield/gotestdox.svg)](https://pkg.go.dev/github.com/bitfield/gotestdox)
[![Go Report Card](https://goreportcard.com/badge/github.com/bitfield/gotestdox)](https://goreportcard.com/report/github.com/bitfield/gotestdox)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge-flat.svg)](https://github.com/avelino/awesome-go)
![CI](https://github.com/bitfield/gotestdox/actions/workflows/ci.yml/badge.svg)
![Audit](https://github.com/bitfield/gotestdox/actions/workflows/audit.yml/badge.svg)

[Subscribe to learn Go with me!](https://bitfieldconsulting.com/subscribe)

![Writing gopher logo](img/gotestdox.png)

`gotestdox` is a command-line tool for formatting Go test results as readable documentation, as recommended in my book [The Power of Go: Tests](https://bitfieldconsulting.com/books/tests).

Here's how to install it:

```
go install github.com/bitfield/gotestdox/cmd/gotestdox@latest
```

In any Go project, run:

```
gotestdox ./...
```

![Animated demo](img/demo.gif)

# What does it do?

`gotestdox` runs your tests and reports the results, but it formats their names in a special way. It converts test names WrittenInCamelCase into ordinary sentences.

For example, suppose we have some tests named like this:

```
TestValidIsTrueForValidInputs
TestValidIsFalseForInvalidInputs
```

We can transform them into readably-spaced sentences that express the desired behaviour, by running `gotestdox`:

**`gotestdox`**

This will run the tests, and print:

```
 ✔ Valid is true for valid inputs (0.00s)
 ✔ Valid is false for invalid inputs (0.00s)
```

# Why?

I read a blog post by Dan North, which says:

> My first “Aha!” moment occurred as I was being shown a deceptively simple utility called `agiledox`, written by my colleague, Chris Stevenson. It takes a JUnit test class and prints out the method names as plain sentences.
>
> The word “test” is stripped from both the class name and the method names, and the camel-case method name is converted into regular text. That’s all it does, but its effect is amazing.
>
> Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences.\
—Dan North, [Introducing BDD](https://dannorth.net/introducing-bdd/)

# How?

The original [`testdox`](https://github.com/astubbs/testdox) tool (part of `agiledox`) was very simple, as Dan describes: it just turned a camel-case JUnit test name like `testFailsForDuplicateCustomers` into a space-separated sentence like `fails for duplicate customers`.

And that's what I find neat about it: it's so simple that it hardly seems like it could be of any value, but it is. I've already used the idea to improve a lot of my test names.

There are implementations of `testdox` for various languages other than Java: for example, [PHP](https://phpunit.readthedocs.io/en/9.5/textui.html#testdox), [Python](https://pypi.org/project/pytest-testdox/), and [.NET](https://testdox.wordpress.com/). I haven't found one for Go, so here it is.

`gotestdox` reads the JSON output generated by the `go test -json` command. This is easier than trying to parse Go source code, for example, and also gives us pass/fail information for the tests. It ignores all events except pass/fail events for individual tests (including subtests).

# Getting fancy

Some more advanced ways to use `gotestdox`:

## Exit status

If there are any test failures, `gotestdox` will print the output messages from the offending test and report status 1 on exit.

## Colour

`gotestdox` indicates a passing test with a `✔` (check mark emoji), and a failing test with an `x`. These are displayed as green and red respectively, using the [`color`](https://github.com/fatih/color) library, which automagically detects if it's talking to a colour-capable terminal.

If not (for example, when you redirect output to a file), or if the [`NO_COLOR`](https://no-color.org/) environment variable is set to any value, colour output will be disabled.

## Test flags and arguments

`gotestdox`, with no arguments, will run the command `go test -json` and process its output.

Any arguments you supply will be passed on to `go test`. For example:

**`gotestdox -run ParseJSON`**

will run the command:

`go test -json -run ParseJSON`

You can supply a list of packages to test, or any other arguments or flags understood by `go test`. However, `gotestdox` only prints events about *tests* (ignoring benchmarks and examples). 

Since fuzz test cases are autogenerated and don't tend to have useful names, these are not included in `gotestdox` output unless they are failing.

## Multiple packages

To test all the packages in the current tree, run:

**`gotestdox ./...`**

Each package's test results will be prefixed by the fully-qualified name of the package. For example:

```
github.com/octocat/mymodule/api:
 ✔ NewServer errors on invalid config options (0.00s)
 ✔ NewServer returns a correctly configured server (0.00s)

github.com/octocat/mymodule/util:
 x LeftPad adds the correct number of leading spaces (0.00s)
    util_test.go:133: want "  dummy", got " dummy"
 ```

## Multi-word function names

There's an ambiguity about test names involving functions whose names contain more than one word. For example, suppose we're testing a function `HandleInput`, and we write a test like this:

```
TestHandleInputClosesInputAfterReading
```

Unless we do something, this will be rendered as:

```
 ✔ Handle input closes input after reading
```

To let us give `gotestdox` a hint about this, there's one extra transformation rule: the first underscore marks the end of the function name. So we can name our test like this:

```
TestHandleInput_ClosesInputAfterReading
```

and this becomes:

```
 ✔ HandleInput closes input after reading
```

I think this is an acceptable compromise: the `gotestdox` output is much more readable, while the extra underscore in the test name doesn't seriously interfere with its readability.

The intent is not to *perfectly* render all sensible test names as sentences, in any case, but to do *something* useful with them, primarily to encourage developers to write test names that are informative descriptions of the unit's behaviour, and thus (as a side effect) read well when formatted by `gotestdox`.

In other words, `gotestdox` is not the thing. It's the thing that gets us to the thing, the end goal being meaningful test names (I like the term _literate_ test names).

## Filtering standard input

If you want to run `go test -json` yourself, for example as part of a shell pipeline, and pipe its output into `gotestdox`, you can do that too:

**`go test -json | gotestdox`**

In this case, any flags or arguments to `gotestdox` will be ignored, and it won't *run* the tests; instead, it will act purely as a text filter. However, just as when it runs the tests itself, it will report exit status 1 if there are any test failures.

## As a package

See [pkg.go.dev/github.com/bitfield/gotestdox](https://pkg.go.dev/github.com/bitfield/gotestdox) for the full documentation on using `gotestdox` as a package in your own programs.

# So what?

Why should you care, then? What's interesting about `gotestdox`, or any `testdox`-like tool, I find, is the way its output makes you think about your tests, how you name them, and what they do.

As Dan says in his blog post, turning test names into sentences is a very simple idea, but it has a powerful effect. Test names *should* be sentences.

## Test names should be sentences

I don't know about you, but I've wasted a lot of time and energy over the years trying to choose good names for tests. I didn't really have a way to evaluate whether the name I chose was good or not. Now I do!

In fact, I wrote a whole blog post about it:

* [Test names should be sentences](https://bitfieldconsulting.com/golang/test-names)

It might be interesting to show your `gotestdox` output to users, customers, or business folks, and see if it makes sense to them. If so, you're on the right lines. And it's quite likely to generate some interesting conversations (“Is that really what it does? But that's not what we asked for!”)

It seems that I'm not the only one who finds this idea useful. I hear that `gotestdox` is already being used in some fairly major Go projects and companies, helping their developers to get more value out of their existing tests, and encouraging them to think in interesting new ways about what tests are really for. How nice!

# Links

- [Bitfield Consulting](https://bitfieldconsulting.com/subscribe)
- [Test names should be sentences](https://bitfieldconsulting.com/golang/test-names)
- [The Power of Go: Tests](https://bitfieldconsulting.com/books/tests)

<small>Gopher image by [MariaLetta](https://github.com/MariaLetta/free-gophers-pack)</small>


gotestdox

An igo to go transpiler (new language features for Go language!)

# Improved Go (igo) [![GoDoc](http://godoc.org/github.com/rocketlaunchr/igo/stack?status.svg)](https://godoc.org/github.com/rocketlaunchr/igo/stack)



Everyone knows that Go is a very verbose language. It takes numerous lines of code to do what a few lines of code can do in other languages. This is a deliberate design decision by the Go Authors.

The igo project provides various syntactical sugar to make your code simpler and easier to read. It works by allowing you to program in `*.igo` files with the fancy new syntax. You then run `igo build` to transpile your `igo` files to standard `go` files which you can then build as per normal.

1. Address Operator (&)
    - Constants and Functions
2. Defers for for-loops
    - `fordefer` guarantees to run prior to the loop's current iteration exiting.
3. Defer go
    - Run defer statements in a goroutine
4. must function
    - Converts a multi-return value function into a single-return function.
    - See [#32219](https://github.com/golang/go/issues/32219)
5. Negative slice indices

**NOTE: igo is pronounced ee-gohr**

⭐ the project to show your appreciation.

## What is included

-   igofmt (auto format code)
-   igo transpiler (generate standard go code)

## Installation

**Transpiler**

```
go get -u github.com/rocketlaunchr/igo
```

Use `go install` to install the executable.

**Formatter**

```
go get -u github.com/rocketlaunchr/igo/igofmt
```

## Inspiration

Most professional front-end developers are fed up with standard JavaScript. They program using Typescript and then transpile the code to standard ES5 JavaScript. igo adds the same step to the build process.

## Examples

### Address Operator

The Address Operator allows you to use more visually pleasing syntax. There is no need for a temporary variable. It can be used with `string`, `bool`, `int`, `float64` and function calls where the function returns 1 return value.

```go

func main() {

	message := &"igo is so convenient"
	display(message)

	display(&`inline string`)

	display(&defaultMessage())

}

func display(m *string) {
	if m == nil {
		fmt.Print("no message")
	} else {
		fmt.Print(*m)
	}

}

func defaultMessage() string {
	return "default message"
}

```

### Fordefer

See [Blog post](https://blog.learngoprogramming.com/gotchas-of-defer-in-go-1-8d070894cb01) on why this is an improvement. It can be especially helpful in unit tests.

```go

for {
	row, err := db.Query("SELECT ...")
	if err != nil {
		panic(err)
	}

	fordefer row.Close()
}

```

### Defer go

This feature makes Go's language syntax more internally consistent. There is no reason why `defer` and `go` should not work together.

```go

mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
	start := time.Now()
	// Transmit how long the request took to serve without delaying response to client.
	defer go transmitRequestStats(start)

	fmt.Fprintf(w, "Welcome to the home page!")
})

```

### Must builtin function

`must` is a "builtin" function that converts a multi-return value function (`"fn"`) into a single-return value function. `fn's` final return value is expected to be of type `error`. `must` will panic upon `fn` returning an error.

It is useful in scenarios where you know that no error will actually be returned by `fn` and you just want to use the function inline. Alternatively, you may want to catch the error during local development because no error should be produced in production.

`must` also accepts an optional second argument of type `func(error) error`.

See [#32219](https://github.com/golang/go/issues/32219)

```go
import "database/sql"

db := must(sql.Open("mysql", "host"))

```

**LIMITATIONS**

-   Currently, it only works when `fn` returns **two** return values.
-   It doesn't work when used outside of functions (i.e. initializing package variables).
-   It works perfectly in simple cases. For more complex cases, peruse the generated code.
-   A PR would be appreciated by an expert in the `go/types` package. It is possible to create a truly generics-compatible `must` that resolves the limitations above.
-   Unlike real "builtin" functions, `must` is a reserved keyword.

### Negative slice indices

You can use negative indices to refer to items in a slice starting from the back. It only works with constants and not variables.

```go
x := []int{0, 1, 2, 3, 4}

x[-3] // x[len(x)-3]

x[-3:-1] // x[len(x)-3:len(x)-1]

```

## How to use

### Transpile

`igo` can accept numerous directories or igo files. The generated go files are saved alongside the igo files.

```
igo build [igo files...]
```

### Format Code

`igofmt` will format your code to the standard form. It understands igo syntax.

```
igofmt [-s] [igo files...]
```

Configure your IDE to run `igofmt` upon saving a `*.igo` file.
`-s` will attempt to simplify the code by running `gofmt -s`.

## Design Decisions and Limitations

Pull-Requests are requested for the below deficiencies.

-   For `fordefer`: `goto` statements inside a for-loop that jump outside the for-loop is not implemented. Use `github.com/rocketlaunchr/igo/stack` package manually in such cases.
-   `goimports` equivalent has not been made.
-   Address Operator for constants currently only supports `string`, `bool`, `float64` and `int`. The other int types are not supported. This can be fixed by using [go/types](https://github.com/golang/example/tree/master/gotypes) package.
-   Address Operator feature assumes you have not attempted to redefine `true` and `false` to something/anything else.

## Tips & Advice

-   Store the `igo` and generated `go` files in your git repository.
-   Configure your IDE to run `igofmt` upon saving a `*.igo` file.

#

### Legal Information

The license is a modified MIT license. Refer to the `LICENSE` file for more details.

**© 2018-20 PJ Engineering and Business Solutions Pty. Ltd.**

### Final Notes

Feel free to enhance features by issuing pull-requests.


Compare two versions of a Go module to check the version-number change required (major, minor, or patchlevel), according to [semver](https://semver.org/) rules

# Modver

[![Go Reference](https://pkg.go.dev/badge/github.com/bobg/modver/v2.svg)](https://pkg.go.dev/github.com/bobg/modver/v2)
[![Go Report Card](https://goreportcard.com/badge/github.com/bobg/modver/v2)](https://goreportcard.com/report/github.com/bobg/modver/v2)
[![Tests](https://github.com/bobg/modver/actions/workflows/go.yml/badge.svg)](https://github.com/bobg/modver/actions/workflows/go.yml)
[![Coverage Status](https://coveralls.io/repos/github/bobg/modver/badge.svg?branch=master)](https://coveralls.io/github/bobg/modver?branch=master)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

This is modver,
a tool that helps you obey [semantic versioning rules](https://semver.org/) in your Go module.

It can read and compare two different versions of the same module,
from two different directories,
or two different Git commits,
or the base and head of a Git pull request.
It then reports whether the changes require an increase in the major-version number,
the minor-version number,
or the patchlevel.

## Installation and usage

Modver can be used from the command line,
or in your Go program,
or with [GitHub Actions](https://github.com/features/actions).

### Command-line interface

Install the `modver` command like this:

```sh
go install github.com/bobg/modver/v2/cmd/modver@latest
```

Assuming the current directory is the root of a cloned Git repository,
you can run it like this:

```sh
$ modver -git .git HEAD~1 HEAD
```

to tell what kind of version-number change is needed for the latest commit.
The `-git .git` gives the path to the repository’s info;
it can also be something like `https://github.com/bobg/modver`.
The arguments `HEAD~1` and `HEAD` specify two Git revisions to compare;
in this case, the latest two commits on the current branch.
These could also be tags or commit hashes.

### GitHub Action

You can arrange for Modver to inspect the changes on your pull-request branch
as part of a GitHub Actions-based continuous-integration step.
It will add a comment to the pull request with its findings,
and will update the comment as new commits are pushed to the branch.

To do this, you’ll need a directory in your GitHub repository named `.github/workflows`,
and a Yaml file containing (at least) the following:

```yaml
name: Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Set up Go
        uses: actions/setup-go@v4
        with:
          go-version: 1.19

      - name: Modver
        if: ${{ github.event_name == 'pull_request' }}
        uses: bobg/modver@v2.5.0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          pull_request_url: https://github.com/${{ github.repository }}/pull/${{ github.event.number }}
```

This can be combined with other steps that run unit tests, etc.
You can change `Tests` to whatever name you like,
and should change `main` to the name of your repository’s default branch.
If your pull request is on a GitHub server other than `github.com`,
change the hostname in the `pull_request_url` parameter to match.

Note the `fetch-depth: 0` parameter for the `Checkout` step.
This causes GitHub Actions to create a clone of your repo with its full history,
as opposed to the default,
which is a shallow clone.
Modver requires enough history to be present in the clone
for it to access the “base” and “head” revisions of your pull-request branch.

For more information about configuring GitHub Actions,
see [the GitHub Actions documentation](https://docs.github.com/actions).

### Go library

Modver also has a simple API for use from within Go programs.
Add it to your project with `go get github.com/bobg/modver/v2@latest`.
See [the Go doc page](https://pkg.go.dev/github.com/bobg/modver/v2) for information about how to use it.

## Semantic versioning

Briefly, a major-version bump is needed for incompatible changes in the public API,
such as when a type is removed or renamed,
or parameters or results are added to or removed from a function.
Old callers cannot expect to use the new version without being updated.

A minor-version bump is needed when new features are added to the public API,
like a new entrypoint or new fields in an existing struct.
Old callers _can_ continue using the new version without being updated,
but callers depending on the new features cannot use the old version.

A patchlevel bump is needed for most other changes.

The result produced by modver is the _minimal_ change required.
The actual change required may be greater.
For example,
if a new method is added to a type,
this function will return `Minor`.
However, if something also changed about an existing method that breaks the old contract -
it accepts a narrower range of inputs, for example,
or returns errors in some new cases -
that may well require a major-version bump,
and this function can't detect those cases.

You can be assured, however,
that if this function returns `Major`,
a minor-version bump won't suffice,
and if this function returns `Minor`,
a patchlevel bump won't suffice,
etc.

The `modver` command
(in the `cmd/modver` subdirectory)
can be used,
among other ways,
to test that each commit to a Git repository increments the module’s version number appropriately.
This is done for modver itself using GitHub Actions,
[here](https://github.com/bobg/modver/blob/dd93eccb5674b13161a91bf6a6666889c21adb5b/.github/workflows/go.yml#L25-L26).

(Note that the standard `actions/checkout@v2` action,
for cloning a repository during GitHub Actions,
creates a shallow clone with just one commit’s worth of history.
For the usage here to work,
you’ll need more history:
at least two commit’s worth and maybe more to pull in the latest tag for the previous revision.
The clone depth can be overridden with the `fetch-depth` parameter,
which modver does [here](https://github.com/bobg/modver/blob/dd93eccb5674b13161a91bf6a6666889c21adb5b/.github/workflows/go.yml#L14-L15).)


modver

A performance monitoring library for Go applications. It provides real-time insights into application performance! 🚀

<p align="center">
  <img src="./static/assets/monigo-icon.png" width="200" title="Monigo Icon" alt="monigo-icon"/>
</p>

# MoniGo - Runtime Observability for Go Applications

[![Go Report Card](https://goreportcard.com/badge/github.com/iyashjayesh/monigo)](https://goreportcard.com/report/github.com/iyashjayesh/monigo)
[![GoDoc](https://godoc.org/github.com/iyashjayesh/monigo?status.svg)](https://pkg.go.dev/github.com/iyashjayesh/monigo)
[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
![GitHub last commit](https://img.shields.io/github/last-commit/iyashjayesh/monigo)
![Tests](https://github.com/iyashjayesh/monigo/actions/workflows/test.yml/badge.svg)
![Visitors](https://api.visitorbadge.io/api/visitors?path=iyashjayesh%2Fmonigo%20&countColor=%23263759&style=flat)

**MoniGo** is a lightweight, embeddable observability library for Go services. It collects runtime metrics (CPU, memory, goroutines, disk/network I/O), traces function execution with pprof profiling, stores time-series data, and serves a real-time dashboard - all from a single `go get`.

<div align="center">
  <img src="monigo.gif" width="100%" alt="monigo-gif">
</div>

## Features

- **Function-Level Tracing** - Profile any function with CPU/memory pprof, adaptive sampling, and reflection-based argument capture
- **Pluggable Storage** - Persistent disk (tstorage) or volatile in-memory backends
- **Real-Time Dashboard** - Embedded web UI with system metrics, health scoring, goroutine inspection, and downloadable reports
- **Prometheus & OpenTelemetry** - Built-in `/metrics` endpoint and OTLP/gRPC export
- **Router Integration** - Works with `net/http`, Gin, Echo, Chi, Fiber, Gorilla Mux
- **Dashboard Security** - Basic Auth, API Key, IP Whitelist, Rate Limiting middleware
- **Headless Mode** - Run as a background telemetry agent without the dashboard
- **Builder API** - Type-safe, chainable configuration with validation

## Installation

```bash
go get github.com/iyashjayesh/monigo@latest
```

Requires **Go 1.22+**.

## Quick Start

```go
package main

import (
    "log"
    "math"
    "net/http"

    "github.com/iyashjayesh/monigo"
)

func main() {
    m := monigo.NewBuilder().
        WithServiceName("my-api").
        WithPort(8080).
        WithStorageType("memory").
        WithSamplingRate(100).
        Build()

    go func() {
        if err := m.Start(); err != nil {
            log.Fatalf("monigo: %v", err)
        }
    }()

    http.HandleFunc("/compute", func(w http.ResponseWriter, r *http.Request) {
        monigo.TraceFunction(r.Context(), heavyWork)
        w.Write([]byte("done"))
    })

    log.Fatal(http.ListenAndServe(":9000", nil))
}

func heavyWork() {
    var sum float64
    for i := 0; i < 1e8; i++ {
        sum += math.Sqrt(float64(i))
    }
}
```

Dashboard: `http://localhost:8080` - Your app: `http://localhost:9000`

## Configuration

All configuration is done via the builder pattern:

```go
m := monigo.NewBuilder().
    WithServiceName("order-service").       // Required
    WithPort(8080).                         // Dashboard port (default: 8080)
    WithStorageType("disk").                // "disk" or "memory" (default: "disk")
    WithRetentionPeriod("7d").              // Data retention (default: "7d")
    WithDataPointsSyncFrequency("5m").      // Metric flush interval (default: "5m")
    WithSamplingRate(100).                  // Trace 1 in N calls (default: 100)
    WithMaxCPUUsage(90).                    // Health threshold (default: 95%)
    WithMaxMemoryUsage(90).                 // Health threshold (default: 95%)
    WithMaxGoRoutines(500).                 // Health threshold (default: 100)
    WithHeadless(false).                    // true = no dashboard (default: false)
    WithTimeZone("UTC").                    // Timezone (default: "Local")
    WithLogLevel(slog.LevelInfo).           // Log level
    WithOTelEndpoint("localhost:4317").      // OTLP gRPC endpoint
    WithOTelHeaders(map[string]string{      // OTel auth headers
        "Authorization": "Bearer <token>",
    }).
    Build()
```

## Function Tracing

```go
// Simple function
monigo.TraceFunction(ctx, myFunc)

// Function with arguments
monigo.TraceFunctionWithArgs(ctx, processOrder, orderID, userID)

// Function with single return
result := monigo.TraceFunctionWithReturn(ctx, calculateTotal, items).(float64)

// Function with multiple returns
results := monigo.TraceFunctionWithReturns(ctx, validateInput, data)
val := results[0].(string)
err := results[1].(error)
```

Each traced call captures: execution time, memory delta, goroutine delta, and (at sampling rate) CPU/memory pprof profiles.

## Dashboard Security

```go
mw, stop := monigo.RateLimitMiddleware(100, time.Minute)
defer stop()

m := monigo.NewBuilder().
    WithServiceName("secure-api").
    WithPort(8080).
    WithDashboardMiddleware(
        monigo.BasicAuthMiddleware("admin", "s3cret"),
        mw,
    ).
    WithAPIMiddleware(
        monigo.APIKeyMiddleware("my-api-key"),
    ).
    Build()
```

## Router Integration

MoniGo integrates with any Go HTTP router:

```go
// Standard net/http
mux := http.NewServeMux()
monigo.RegisterDashboardHandlers(mux)

// Fiber
app.All("/monigo/*", adaptor.HTTPHandler(monigo.GetUnifiedHandler()))

// Gin / Echo / Chi - use GetAPIHandlers() map
for path, handler := range monigo.GetAPIHandlers() {
    router.GET(path, gin.WrapF(handler))
}
```

See [`example/router-integration/`](example/router-integration/) for complete examples.

## API Endpoints

| Method | Path | Description |
|--------|------|-------------|
| GET | `/monigo/api/v1/metrics` | Current service statistics |
| GET | `/monigo/api/v1/service-info` | Service metadata |
| POST | `/monigo/api/v1/service-metrics` | Query time-series data |
| GET | `/monigo/api/v1/go-routines-stats` | Goroutine stack analysis |
| GET | `/monigo/api/v1/function` | Function trace summary |
| GET | `/monigo/api/v1/function-details` | pprof reports for a function |
| POST | `/monigo/api/v1/reports` | Aggregated report data |
| GET | `/metrics` | Prometheus scrape endpoint |

## Architecture

```
┌─────────────────────────────────────────────────┐
│                  Your Application                │
│                                                  │
│  monigo.TraceFunction(ctx, fn)                   │
│  monigo.Start() / monigo.Initialize()            │
└───────────┬─────────────────────┬────────────────┘
            │                     │
    ┌───────▼───────┐    ┌───────▼────────┐
    │   core/       │    │   monigo.go    │
    │  Metrics      │    │  Dashboard     │
    │  Collection   │    │  HTTP Server   │
    │  Health Score │    │  Middleware     │
    │  Profiling    │    │  Router Integ. │
    └───────┬───────┘    └───────┬────────┘
            │                     │
    ┌───────▼─────────────────────▼────────┐
    │           timeseries/                 │
    │  tstorage (disk) │ InMemoryStorage   │
    └───────┬──────────────────────────────┘
            │
    ┌───────▼───────────────────────────────┐
    │           exporters/                   │
    │  Prometheus Collector │ OTel Exporter  │
    └───────────────────────────────────────┘
            │
    ┌───────▼───────────────────────────────┐
    │           internal/                    │
    │  registry │ pipeline │ exporter │ log  │
    └───────────────────────────────────────┘
```

**Package responsibilities:**

| Package | Role |
|---------|------|
| `monigo` (root) | Public API, dashboard server, middleware, builder |
| `core` | System metric collection, function tracing, health scoring |
| `common` | Utilities, unit conversion, process info |
| `timeseries` | Storage abstraction (disk + in-memory) |
| `exporters` | Prometheus collector, OTel OTLP exporter |
| `internal/registry` | Thread-safe metric registry |
| `internal/pipeline` | Async metric export pipeline |
| `internal/exporter` | Exporter interface + fan-out |
| `internal/logger` | Race-safe structured logger (slog) |
| `models` | Shared data structures |
| `api` | HTTP handlers for all endpoints |

### What Works Well

- **Zero-dependency embedding** - Single `go get`, no sidecar, no agent
- **Goroutine-safe metrics** - Atomic sampling, mutex-protected maps, `sync.Once` singletons
- **Adaptive profiling** - Sampling prevents pprof overhead in hot paths
- **Clean builder API** - Validation at build time catches misconfiguration early
- **Race-free logger** - `atomic.Pointer` eliminates the common `slog` data race

## Examples

| Example | Path |
|---------|------|
| Basic usage | [`example/main.go`](example/main.go) |
| Function tracing | [`example/function-trace-example/`](example/function-trace-example/) |
| Gin integration | [`example/router-integration/gin-integration/`](example/router-integration/gin-integration/) |
| Echo integration | [`example/router-integration/echo-integration/`](example/router-integration/echo-integration/) |
| Fiber integration | [`example/router-integration/fiber-integration/`](example/router-integration/fiber-integration/) |
| Standard mux | [`example/router-integration/standard-mux-integration/`](example/router-integration/standard-mux-integration/) |
| Gorilla mux | [`example/router-integration/gorilla-mux-integration/`](example/router-integration/gorilla-mux-integration/) |
| Basic auth | [`example/security-examples/basic-auth/`](example/security-examples/basic-auth/) |
| API key auth | [`example/security-examples/api-key/`](example/security-examples/api-key/) |
| IP whitelist | [`example/security-examples/ip-whitelist-example/`](example/security-examples/ip-whitelist-example/) |
| Custom auth | [`example/security-examples/custom-auth/`](example/security-examples/custom-auth/) |

## Documentation

Full guides and API reference: **[iyashjayesh.github.io/monigo-website](https://iyashjayesh.github.io/monigo-website)**

| Topic | Link |
|-------|------|
| Introduction & Features | [Docs](https://iyashjayesh.github.io/monigo-website/guides/introduction/) |
| Configuration (Builder API) | [Docs](https://iyashjayesh.github.io/monigo-website/guides/configuration/) |
| Function Tracing | [Docs](https://iyashjayesh.github.io/monigo-website/guides/function-tracing/) |
| Router Integration | [Docs](https://iyashjayesh.github.io/monigo-website/guides/router-integration/) |
| Dashboard Security | [Docs](https://iyashjayesh.github.io/monigo-website/guides/security/) |
| Migration (v1 → v2) | [Docs](https://iyashjayesh.github.io/monigo-website/reference/migration-v1-to-v2/) |

## Contributing

We welcome contributions. Please see [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

If you find MoniGo useful, consider giving it a star.

## License

Apache 2.0 - see [LICENSE](LICENSE).

## Contact

For questions or feedback: [open an issue](https://github.com/iyashjayesh/monigo/issues) or reach out at `iyashjayesh@gmail.com` / [LinkedIn](https://www.linkedin.com/in/iyashjayesh/).

## Star History

[![Star History Chart](https://api.star-history.com/svg?repos=iyashjayesh/monigo&type=Date)](https://star-history.com/#iyashjayesh/monigo&Date)


MoniGO

Navigate through go files efficiently with the OctoLinker browser extension for GitHub

<p align="center">
<a href="https://chrome.google.com/webstore/detail/octo-linker/jlmafbaeoofdegohdhinkhilhclaklkp"><img src="https://cloud.githubusercontent.com/assets/1393946/15162649/647ca490-1704-11e6-8ed8-ef0674e40fc3.png" width="375"/></a
</p>

## What is OctoLinker?

OctoLinker is a browser extension for GitHub, that turns language-specific statements like `include` `require` or `import` into links.

<img src="./demo.png" width="890" />

## Install

<a href="https://chrome.google.com/webstore/detail/octolinker/jlmafbaeoofdegohdhinkhilhclaklkp"><img src="https://raw.githubusercontent.com/alrra/browser-logos/master/src/chrome/chrome_128x128.png" width="48" /></a>
<a href="https://addons.mozilla.org/en-US/firefox/addon/octolinker/"><img src="https://raw.githubusercontent.com/alrra/browser-logos/master/src/firefox/firefox_128x128.png" width="48" /></a>
<a href="https://apps.apple.com/app/octolinker/id1549308269"><img src="https://raw.githubusercontent.com/alrra/browser-logos/master/src/safari/safari_128x128.png" width="48" /></a>
<a href="https://microsoftedge.microsoft.com/addons/detail/lbbanfffjfmfdahnfbklminikafhcjjb"><img src="https://raw.githubusercontent.com/alrra/browser-logos/master/src/edge/edge_128x128.png" width="48" /></a>
<a href="https://addons.opera.com/en/extensions/details/octolinker/"><img src="https://raw.githubusercontent.com/alrra/browser-logos/master/src/opera/opera_128x128.png" width="48" /></a>

Trusted by over 30,000 developers! Install OctoLinker from [Chrome Web Store](https://chrome.google.com/webstore/detail/octo-linker/jlmafbaeoofdegohdhinkhilhclaklkp), [Mozilla Add-ons Store](https://addons.mozilla.org/en-US/firefox/addon/octolinker/), [Mac App Store](https://apps.apple.com/app/octolinker/id1549308269), [Microsoft Store](https://microsoftedge.microsoft.com/addons/detail/lbbanfffjfmfdahnfbklminikafhcjjb) and [Opera Add-ons Store](https://addons.opera.com/en/extensions/details/octolinker/).

## Special thanks to

- [Art Noir](https://www.art-noir.net/) for our amazing logo!
- Everyone who supported, [contributed](https://github.com/OctoLinker/OctoLinker/graphs/contributors), or promoted the project.

## Sponsors

[![▲ Vercel](https://user-images.githubusercontent.com/1393946/111010284-576c9900-8396-11eb-9fd9-399cc7dae8bc.png)](https://vercel.com/?utm_source=octolinker&utm_campaign=oss) 
[![Memetria](https://user-images.githubusercontent.com/1393946/188732093-16aa8b25-7c91-4f3b-a56a-8285a2f3ef47.png)](https://www.memetria.com) 
[![complex](https://user-images.githubusercontent.com/1393946/111010138-e0cf9b80-8395-11eb-9086-e3f19645b399.png)](https://www.complex-it.de/jobs/offene-stellen?utm_source=oss-referal&utm_medium=logo&utm_campaign=growwithus)

I am truly grateful to all the wonderful humans and companies supporting the development of OctoLinker. Please consider donations through [GitHub Sponsors](https://github.com/sponsors/stefanbuck/) or [Open Collective](https://opencollective.com/octolinker) – Thank you 🙇‍♂️

## Privacy Policy

Our [Privacy Policy](https://octolinker.now.sh/privacy/) describes our practices related to the use, storage and disclosure of information we collect when you're using our service.

## Related

- [Awesome browser extensions for GitHub](https://github.com/stefanbuck/awesome-browser-extensions-for-github) - Awesome list
- [Refined GitHub](https://github.com/sindresorhus/refined-github/) - Tons of useful features for GitHub
- [Notifier for GitHub](https://github.com/sindresorhus/notifier-for-github-chrome) - Shows your notification unread count
- [OctoPermalinker](https://github.com/josephfrazier/octopermalinker) - Fix outdated/broken GitHub links to branches

## Disclaimer

OctoLinker is not affiliated with, sponsored by, or endorsed by GitHub Inc.

Copyright (c) 2014–present [Stefan Buck](https://stefanbuck.com/) and [other contributors](https://github.com/OctoLinker/OctoLinker/graphs/contributors).


OctoLinker

Enrich `go test` outputs with text decorations

# richgo

Rich-Go will enrich `go test` outputs with text decorations

[![PkgGoDev](https://pkg.go.dev/badge/kyoh86/richgo)](https://pkg.go.dev/kyoh86/richgo)
[![Go Report Card](https://goreportcard.com/badge/github.com/kyoh86/richgo)](https://goreportcard.com/report/github.com/kyoh86/richgo)
[![Release](https://github.com/kyoh86/richgo/workflows/Release/badge.svg)](https://github.com/kyoh86/richgo/releases)

[![asciicast](https://asciinema.org/a/99810.png)](https://asciinema.org/a/99810)

# NOTICE (what I think about `richgo`)

For some years, I've not been using `richgo`.
Now I don't feel much effect that a little bit of tweaking to the appearance of the test output.
And It is poor method that `richgo` parses and adjusts the standard output of `go test`.
So now I recommend you that you do NOT use `richgo`, get use to pure `go test`, train an ability to find the error from the output and contribute to improve official `go test` if you needed.
Some may think that I have too much faith in pure Go, but this is my honest feeling.

If you want a good suggestion for alternative tools for this one, you may find it in the [issue #57](https://github.com/kyoh86/richgo/issues/57).


# Installation

(go get):

```
go get -u github.com/kyoh86/richgo
```

(homebrew):

```
brew install kyoh86/tap/richgo
```

(asdf):

```
asdf plugin add richgo
asdf install richgo 0.3.6
```

# Usage

## Basic

```sh
richgo test ./...
```

## In an existing pipeline

If your build scripts expect to interact with the standard output format of `go
test` (for instance, if you're using
[go-junit-report](https://github.com/jstemmer/go-junit-report)), you'll need to
use the `testfilter` subcommand of `richgo`.

For example:

```sh
go test ./... | tee >(richgo testfilter) | go-junit-report
```

This will "tee" the output of the standard `go test` run into a `richgo
testfilter` process as well as passing the original output to
`go-junit-report`.

Note that at some point this recommendation may change, as the "go test" tool
may learn how to produce a standard output format
[golang/go#2981](https://github.com/golang/go/issues/2981) that both this tool
and others could rely on.

## alias

You can define alias so that `go test` prints rich outputs:

* bash: `~/.bashrc`
* zsh: `~/.zshrc`

```
alias go=richgo
```

## Configure

### Configuration file paths

It's possible to change styles with the preference file.
Rich-Go loads preferences from the files in the following order.

* `${CWD}/.richstyle`
* `${CWD}/.richstyle.yaml`
* `${CWD}/.richstyle.yml`
* `${GOPATH}/.richstyle`
* `${GOPATH}/.richstyle.yaml`
* `${GOPATH}/.richstyle.yml`
* `${GOROOT}/.richstyle`
* `${GOROOT}/.richstyle.yaml`
* `${GOROOT}/.richstyle.yml`
* `${HOME}/.richstyle`
* `${HOME}/.richstyle.yaml`
* `${HOME}/.richstyle.yml`

Setting the environment variable `RICHGO_LOCAL` to 1, Rich-Go loads only `${CWD}/.richstyle*`.

### Configuration file format

**Now Rich-Go supports only YAML formatted.**

```yaml
# Type of the label that notes a kind of each lines.
labelType: (long | short | none)

# Style of "Build" lines.
buildStyle:
  # Hide lines
  hide: (true | false)
  # Bold or increased intensity.
  bold: (true | false)
  faint: (true | false)
  italic: (true | false)
  underline: (true | false)
  blinkSlow: (true | false)
  blinkRapid: (true | false)
  # Swap the foreground color and background color.
  inverse: (true | false)
  conceal: (true | false)
  crossOut: (true | false)
  frame: (true | false)
  encircle: (true | false)
  overline: (true | false)
  # Fore-color of text
  foreground: ("#xxxxxx" | rgb(0-256,0-256,0-256) | rgb(0x00-0xFF,0x00-0xFF,0x00-0xFF) | (name of colors))
  # Back-color of text
  background: # Same format as `foreground`

# Style of the "Start" lines.
startStyle:
  # Same format as `buildStyle`

# Style of the "Pass" lines.
passStyle:
  # Same format as `buildStyle`

# Style of the "Fail" lines.
failStyle:
  # Same format as `buildStyle`

# Style of the "Skip" lines.
skipStyle:
  # Same format as `buildStyle`

# Style of the "File" lines.
fileStyle:
  # Same format as `buildStyle`

# Style of the "Line" lines.
lineStyle:
  # Same format as `buildStyle`

# Style of the "Pass" package lines.
passPackageStyle:
  # Same format as `buildStyle`

# Style of the "Fail" package lines.
failPackageStyle:
  # Same format as `buildStyle`

# A threashold of the coverage
coverThreshold: (0-100)

# Style of the "Cover" lines with the coverage that is higher than coverThreshold.
coveredStyle:
  # Same format as `buildStyle`

# Style of the "Cover" lines with the coverage that is lower than coverThreshold.
uncoveredStyle:
  # Same format as `buildStyle`

# If you want to delete lines, write the regular expressions.
removals:
  - (regexp)
# If you want to leave `Test` prefixes, set it "true".
leaveTestPrefix: (true | false)
```

### Line categories

Rich-Go separate the output-lines in following categories.

* Build:  
  When the Go fails to build, it prints errors like this:

  <pre><code># github.com/kyoh86/richgo/sample/buildfail
  sample/buildfail/buildfail_test.go:6: t.Foo undefined (type testing.T has no field or method Foo)</code></pre>

* Start:  
  In the top of test, Go prints that name like this:

  <pre><code>=== RUN   TestSampleOK/SubtestOK</code></pre>

* Pass:  
  When a test is successed, Go prints that name like this:

  <pre><code>    ---PASS: TestSampleOK/SubtestOK</code></pre>

* Fail:  
  When a test is failed, Go prints that name like this:

  <pre><code>--- FAIL: TestSampleNG (0.00s)
  sample_ng_test.go:9: It's not OK... :(</code></pre>

* Skip:  
  If there is no test files in directory or a test is skipped, Go prints that path or the name like this:

  <pre><code>--- SKIP: TestSampleSkip (0.00s)
  sample_skip_test.go:6:
?     github.com/kyoh86/richgo/sample/notest  [no test files]</code></pre>

* PassPackage:  
  When tests in package are successed, Go prints just:

  <pre><code>PASS</code></pre>

* Fail:  
  When a test in package are failed, Go prints just:

  <pre><code>FAIL</code></pre>

* Cover:  
  If the coverage analysis is enabled, Go prints the coverage like this:

  <pre><code>=== RUN   TestCover05
--- PASS: TestCover05 (0.00s)
PASS
coverage: 50.0% of statements
ok  	github.com/kyoh86/richgo/sample/cover05	0.012s	coverage: 50.0% of statements</code></pre>

Each categories can be styled seperately.

### Label types

* Long:
  * Build: "BUILD"
  * Start: "START"
  * Pass: "PASS"
  * Fail: "FAIL"
  * Skip: "SKIP"
  * Cover: "COVER"

* Short:
  * Build: "!!"
  * Start: ">"
  * Pass: "o"
  * Fail: "x"
  * Skip: "-"
  * Cover: "%"

* None:
  Rich-Go will never output labels.

### Default

```yaml
labelType: long
buildStyle:
  bold: true
  foreground: yellow
startStyle:
  foreground: lightBlack
passStyle:
  foreground: green
failStyle:
  bold: true
  foreground: red
skipStyle:
  foreground: lightBlack
passPackageStyle:
  foreground: green
  hide: true
failPackageStyle:
  bold: true
  foreground: red
  hide: true
coverThreshold: 50
coveredStyle:
  foreground: green
uncoveredStyle:
  bold: true
  foreground: yellow
fileStyle:
  foreground: cyan
lineStyle:
  foreground: magenta
```

## Overriding colorization detection

By default, `richgo` determines whether or not to colorize its output based
on whether it's connected to a TTY or not. This works for most use cases, but
may not behave as expected if you use `richgo` in a pipeline of commands, where
STDOUT is being piped to another command.

To force colorization, add `RICHGO_FORCE_COLOR=1` to the environment you're
running in. For example:

```sh
RICHGO_FORCE_COLOR=1 richgo test ./... | tee test.log
```

## Configure to resolve a conflict with "Solarized dark" theme

The bright-black is used for background color in Solarized dark theme.
Richgo uses that color for "startStyle" and "skipStyle", so "START" and "SKIP" lines can not be seen on the screen with Solarized dark theme.

To resolve that conflict, you can set another color for "startStyle" and "skipStyle" in [.richstyle](#configuration-file-paths) like below.

```
startStyle:
  foreground: yellow

skipStyle:
  foreground: lightYellow
```

## Getting a version of the richgo

If you want to get a version of the `richgo`, this information is embedded in the binary (since Go 1.18).
You can view it with go version -m, e.g. for richgo 0.3.10:

```console
$ go version -m $(command -v richgo)
./richgo: go1.18
	path	github.com/kyoh86/richgo
	mod	github.com/kyoh86/richgo	v0.3.10	h1:iSGvcjhtQN2IVrBDhPk0if0R/RMQnCN1E/9OyAW4UUs=
	[...]
```

And just a little more advanced way (with POSIX `awk`):

```console
$ go version -m $(command -v richgo) | awk '$1 == "mod" && $2 == "github.com/kyoh86/richgo" {print $3;}'
v0.3.10
```

# License

[![MIT License](http://img.shields.io/badge/license-MIT-blue.svg)](http://www.opensource.org/licenses/MIT)

This is distributed under the [MIT License](http://www.opensource.org/licenses/MIT).



richgo

RTS: response to struct. Generates Go structs from server responses

# RTS: Request to Struct

[![GoDoc](https://godoc.org/github.com/galeone/rts?status.svg)](https://godoc.org/github.com/galeone/rts)
[![Build Status](https://travis-ci.org/galeone/rts.svg?branch=master)](https://travis-ci.org/galeone/rts)

Generate Go structs definitions from JSON server responses.

RTS defines type names using the specified lines in the route file and skipping numbers.
e.g: a request to a route like `/users/1/posts` generates `type UsersPosts`

It supports *parameters*: a line like `/users/:user/posts/:pid 1 200` generates `type UsersUserPostsPid` from the response to the request `GET /users/1/posts/200`.

RTS supports headers personalization as well, thus it can be used to generate types from responses protected by some authorization method

## Install

### CLI Application

`go get -u github.com/galeone/rts/cmd/rts`

#### CLI Usage

```
rts [options]
  -headers string
    	Headers to add in every request
  -help
    	prints this help
  -insecure
    	Disables TLS Certificate check for HTTPS, use in case HTTPS Server Certificate is signed by an unknown authority
  -out string
    	Output file. Stdout is used if not specified
  -pkg string
    	Package name (default "main")
  -routes string
    	Routes to request. One per line (default "routes.txt")
  -server string
    	sets the server address (default "http://localhost:9090")
  -substruct
    	Creates types for sub-structs
```

#### Examples

You can invoke `rts` piping from stdin a single JSON (anonymous) and get it converted to a go structure

```
echo '  {
    "Book Id": 30558257,
    "Title": "Unsouled (Cradle, #1)",
    "Author": "Will Wight",
    "Author l-f": "Wight, Will",
    "Additional Authors": "",
    "BCID": ""
  }' | ./rts
```

obtaining

```go
package main

type Foo1 struct {
        Additional_Authors string `json:"Additional Authors"`
        Author             string `json:"Author"`
        Author_l_f         string `json:"Author l-f"`
        Bcid               string `json:"BCID"`
        Book_Id            int64  `json:"Book Id"`
        Title              string `json:"Title"`
}
```

Or you can define a more complex scenario, definining the `routes.txt` file with a line for each (parametric) request and use it as shown below.

*routes.txt*:

```txt
/
/repos/:user/:repo galeone igor
```

Run:

```
rts -server https://api.github.com -pkg example
```

Returns:

```go
package example

type Foo1 struct {
	AuthorizationsURL                string `json:"authorizations_url"`
	CodeSearchURL                    string `json:"code_search_url"`
	CommitSearchURL                  string `json:"commit_search_url"`
	CurrentUserAuthorizationsHTMLURL string `json:"current_user_authorizations_html_url"`
	CurrentUserRepositoriesURL       string `json:"current_user_repositories_url"`
	CurrentUserURL                   string `json:"current_user_url"`
	EmailsURL                        string `json:"emails_url"`
	EmojisURL                        string `json:"emojis_url"`
	EventsURL                        string `json:"events_url"`
	FeedsURL                         string `json:"feeds_url"`
	FollowersURL                     string `json:"followers_url"`
	FollowingURL                     string `json:"following_url"`
	GistsURL                         string `json:"gists_url"`
	HubURL                           string `json:"hub_url"`
	IssueSearchURL                   string `json:"issue_search_url"`
	IssuesURL                        string `json:"issues_url"`
	KeysURL                          string `json:"keys_url"`
	LabelSearchURL                   string `json:"label_search_url"`
	NotificationsURL                 string `json:"notifications_url"`
	OrganizationRepositoriesURL      string `json:"organization_repositories_url"`
	OrganizationTeamsURL             string `json:"organization_teams_url"`
	OrganizationURL                  string `json:"organization_url"`
	PublicGistsURL                   string `json:"public_gists_url"`
	RateLimitURL                     string `json:"rate_limit_url"`
	RepositorySearchURL              string `json:"repository_search_url"`
	RepositoryURL                    string `json:"repository_url"`
	StarredGistsURL                  string `json:"starred_gists_url"`
	StarredURL                       string `json:"starred_url"`
	TopicSearchURL                   string `json:"topic_search_url"`
	UserOrganizationsURL             string `json:"user_organizations_url"`
	UserRepositoriesURL              string `json:"user_repositories_url"`
	UserSearchURL                    string `json:"user_search_url"`
	UserURL                          string `json:"user_url"`
}

type ReposUserRepo struct {
	AllowForking             bool               `json:"allow_forking"`
	ArchiveURL               string             `json:"archive_url"`
	Archived                 bool               `json:"archived"`
	AssigneesURL             string             `json:"assignees_url"`
	BlobsURL                 string             `json:"blobs_url"`
	BranchesURL              string             `json:"branches_url"`
	CloneURL                 string             `json:"clone_url"`
	CollaboratorsURL         string             `json:"collaborators_url"`
	CommentsURL              string             `json:"comments_url"`
	CommitsURL               string             `json:"commits_url"`
	CompareURL               string             `json:"compare_url"`
	ContentsURL              string             `json:"contents_url"`
	ContributorsURL          string             `json:"contributors_url"`
	CreatedAt                string             `json:"created_at"`
	DefaultBranch            string             `json:"default_branch"`
	DeploymentsURL           string             `json:"deployments_url"`
	Description              string             `json:"description"`
	Disabled                 bool               `json:"disabled"`
	DownloadsURL             string             `json:"downloads_url"`
	EventsURL                string             `json:"events_url"`
	Fork                     bool               `json:"fork"`
	Forks                    int64              `json:"forks"`
	ForksCount               int64              `json:"forks_count"`
	ForksURL                 string             `json:"forks_url"`
	FullName                 string             `json:"full_name"`
	GitCommitsURL            string             `json:"git_commits_url"`
	GitRefsURL               string             `json:"git_refs_url"`
	GitTagsURL               string             `json:"git_tags_url"`
	GitURL                   string             `json:"git_url"`
	HasDownloads             bool               `json:"has_downloads"`
	HasIssues                bool               `json:"has_issues"`
	HasPages                 bool               `json:"has_pages"`
	HasProjects              bool               `json:"has_projects"`
	HasWiki                  bool               `json:"has_wiki"`
	Homepage                 string             `json:"homepage"`
	HooksURL                 string             `json:"hooks_url"`
	HTMLURL                  string             `json:"html_url"`
	ID                       int64              `json:"id"`
	IsTemplate               bool               `json:"is_template"`
	IssueCommentURL          string             `json:"issue_comment_url"`
	IssueEventsURL           string             `json:"issue_events_url"`
	IssuesURL                string             `json:"issues_url"`
	KeysURL                  string             `json:"keys_url"`
	LabelsURL                string             `json:"labels_url"`
	Language                 string             `json:"language"`
	LanguagesURL             string             `json:"languages_url"`
	License                  ReposUserRepo_sub1 `json:"license"`
	MergesURL                string             `json:"merges_url"`
	MilestonesURL            string             `json:"milestones_url"`
	MirrorURL                interface{}        `json:"mirror_url"`
	Name                     string             `json:"name"`
	NetworkCount             int64              `json:"network_count"`
	NodeID                   string             `json:"node_id"`
	NotificationsURL         string             `json:"notifications_url"`
	OpenIssues               int64              `json:"open_issues"`
	OpenIssuesCount          int64              `json:"open_issues_count"`
	Owner                    ReposUserRepo_sub2 `json:"owner"`
	Private                  bool               `json:"private"`
	PullsURL                 string             `json:"pulls_url"`
	PushedAt                 string             `json:"pushed_at"`
	ReleasesURL              string             `json:"releases_url"`
	Size                     int64              `json:"size"`
	SSHURL                   string             `json:"ssh_url"`
	StargazersCount          int64              `json:"stargazers_count"`
	StargazersURL            string             `json:"stargazers_url"`
	StatusesURL              string             `json:"statuses_url"`
	SubscribersCount         int64              `json:"subscribers_count"`
	SubscribersURL           string             `json:"subscribers_url"`
	SubscriptionURL          string             `json:"subscription_url"`
	SvnURL                   string             `json:"svn_url"`
	TagsURL                  string             `json:"tags_url"`
	TeamsURL                 string             `json:"teams_url"`
	TempCloneToken           interface{}        `json:"temp_clone_token"`
	Topics                   []string           `json:"topics"`
	TreesURL                 string             `json:"trees_url"`
	UpdatedAt                string             `json:"updated_at"`
	URL                      string             `json:"url"`
	Visibility               string             `json:"visibility"`
	Watchers                 int64              `json:"watchers"`
	WatchersCount            int64              `json:"watchers_count"`
	WebCommitSignoffRequired bool               `json:"web_commit_signoff_required"`
}

type ReposUserRepo_sub2 struct {
	AvatarURL         string `json:"avatar_url"`
	EventsURL         string `json:"events_url"`
	FollowersURL      string `json:"followers_url"`
	FollowingURL      string `json:"following_url"`
	GistsURL          string `json:"gists_url"`
	GravatarID        string `json:"gravatar_id"`
	HTMLURL           string `json:"html_url"`
	ID                int64  `json:"id"`
	Login             string `json:"login"`
	NodeID            string `json:"node_id"`
	OrganizationsURL  string `json:"organizations_url"`
	ReceivedEventsURL string `json:"received_events_url"`
	ReposURL          string `json:"repos_url"`
	SiteAdmin         bool   `json:"site_admin"`
	StarredURL        string `json:"starred_url"`
	SubscriptionsURL  string `json:"subscriptions_url"`
	Type              string `json:"type"`
	URL               string `json:"url"`
}

type ReposUserRepo_sub1 struct {
	Key    string `json:"key"`
	Name   string `json:"name"`
	NodeID string `json:"node_id"`
	SpdxID string `json:"spdx_id"`
	URL    string `json:"url"`
}
```

### Library

```go
import "github.com/galeone/rts"

byteFile, err := rts.Do(pkg, server, lines, headerMap)
```

# License

RTS: Request to Struct. Generates Go structs from a server response.
Copyright (C) 2016-2022 Paolo Galeone <nessuno@nerdz.eu>

This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
Exhibit B is not attached; this software is compatible with the
licenses expressed under Section 1.12 of the MPL v2.


Extract Go struct field names, types and tags for filtering and exporting

# Textra

[![Go Reference](https://pkg.go.dev/badge/github.com/ravsii/textra.svg)](https://pkg.go.dev/github.com/ravsii/textra) [![codecov](https://codecov.io/gh/ravsii/textra/branch/main/graph/badge.svg?token=C8WA38GNFV)](https://codecov.io/gh/ravsii/textra) [![Go Report Card](https://goreportcard.com/badge/github.com/ravsii/textra)](https://goreportcard.com/report/github.com/ravsii/textra) [![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go) 

Textra is a zero-dependency, simple and fast struct tags parser library. It also has json tags for all structs, in case of JSON output.

Initially I built it for another private project, but decided to try to open source it, since it could be useful for someone. Because of that, it has some features that feel redundant, like having field type as a part of returned data

## Installation

```shell
go get github.com/ravsii/textra
```

## Examples

Basic usage:

```go
type Tester struct {
 NoTags   bool
 WithTag  string `json:"with_tag,omitempty"`
 WithTags string `json:"with_tags"          sql:"with_tag"`
 SqlOnly  string `sql:"sql_only"`
}

func main() {
 basic := textra.Extract((*Tester)(nil))
 for _, field := range basic {
  fmt.Println(field)
 }
}

```

```text
NoTags(bool):[]
WithTag(string):[json:"with_tag,omitempty"]
WithTags(string):[json:"with_tags" sql:"with_tag"]
SqlOnly(string):[sql:"sql_only"]
```

You can look at return types at [pkg.go.dev](https://pkg.go.dev/github.com/Ravcii/textra), but basically it returns a slice of fields with its types (as strings) and a slice of Tags for each field.

Now let's apply some functions:

```go
 removed := basic.RemoveEmpty()
 for _, field := range removed {
  fmt.Println(field)
 }
```

```text
SqlOnly(*[]string):[pg:"sql_only" sql:"sql_only"]
WithTag(string):[json:"with_tag,omitempty"]
WithTags(*string):[json:"with_tags" sql:"with_tag"]
```

What if we care only about SQL tags?

```go
 onlySQL := removed.OnlyTag("sql")
 for _, field := range onlySQL {
  fmt.Println(field)
 }
```

```text
SqlOnly(*[]string):sql:"sql_only"
WithTags(*string):sql:"with_tag"
```

_Only() is a bit special as it returns a Field of a different type, with `Tag` rather than `Tags`(=`[]Tag`)_

API is built like standard's `time` package, where chaining function will create new values, instead of modifying them.

Although it may be redundant, it also parses types a their string representation (for easier comparison or output, if you need it)

```go
type Types struct {
 intType        int
 intPType       *int
 byteType       byte
 bytePType      *byte
 byteArrType    []byte
 byteArrPType   []*byte
 bytePArrPType  *[]*byte
 runeType       rune
 runePType      *rune
 stringType     string
 stringPType    *string
 booleanType    bool
 booleanPType   *bool
 mapType        map[string]string
 mapPType       map[*string]*string
 mapPImportType map[*string]*time.Time
 chanType       chan int
 funcType       func() error
 funcParamsType func(arg1 int, arg2 string, arg3 map[*string]*time.Time) (int, error)
 importType     time.Time
 pointerType    *string
}

func main() {
 fields := textra.Extract((*Types)(nil))
 for _, field := range fields {
  fmt.Println(field.Name, field.Type)
 }
}
```

```text
intType int
intPType *int
byteType uint8
bytePType *uint8
byteArrType []uint8
byteArrPType []*uint8
bytePArrPType *[]*uint8
runeType int32
runePType *int32
stringType string
stringPType *string
booleanType bool
booleanPType *bool
mapType map[string]string
mapPType map[*string]*string
mapPImportType map[*string]*time.Time
chanType chan
funcType func() error
funcParamsType func(int, string, map[*string]*time.Time) int, error
importType time.Time
pointerType *string
```

### TODO

- [ ] Examples for go.dev
- [ ] ...?


textra

Examine Go types and their transitive dependencies, alternatively export results as TypeScript value objects (or types) declaration

[![Open Issues](https://img.shields.io/github/issues/dtgorski/typex.svg)](https://github.com/dtgorski/typex/issues)
[![Report Card](https://goreportcard.com/badge/github.com/dtgorski/typex)](https://goreportcard.com/report/github.com/dtgorski/typex)
[![Awesome Go](https://awesome.re/badge.svg)](https://github.com/avelino/awesome-go#user-content-go-tools)

## typex

Examine [Go](https://golang.org/) types and their transitive dependencies. Export results as TypeScript value objects (or types) declaration.

### Installation
```
go install github.com/dtgorski/typex@latest
```

### Synopsis
The CLI command ```typex``` filters and displays [Go](https://golang.org/) type structures, interfaces and their relationships across package boundaries.
It generates a type hierarchy tree with additional references to transitive dependencies vital for the filtered types.
As an additional feature, ```typex``` exports the result tree as a [TypeScript](https://www.typescriptlang.org/) projection representing value objects or bare types.

### Examples
**Go type hierarchy layout**
  ```
  $ typex -f=Rune io/...

  ├── error interface {
  │       Error() string
  │   }
  └── io
      ├── RuneReader interface {
      │       ReadRune() (r rune, size int, err error)
      │   }
      └── RuneScanner interface {
              io.RuneReader
              ReadRune() (r rune, size int, err error)
              UnreadRune() error
          }
  ```
  ```
  $ typex -f=Render github.com/dtgorski/typex/...

  └── github.com
      └── dtgorski
          └── typex
              └── internal
                  ├── PathReplaceFunc func(string) string
                  ├── go
                  │   └── TypeRender struct {
                  │           PathReplaceFunc internal.PathReplaceFunc
                  │           IncludeUnexported bool
                  │       }
                  └── ts
                      └── TypeRender struct {
                              PathReplaceFunc internal.PathReplaceFunc
                              IncludeUnexported bool
                          }
  ```

**TypeScript value object layout**
  ```
  $ typex -f=File -l=ts-class mime/multipart

  export module mime {
      export module multipart {
          export class FileHeader {
              constructor(
                  readonly Filename: string,
                  readonly Header: net.textproto.MIMEHeader,
                  readonly Size: number,
              ) {}
          }
      }
  }
  export module net {
      export module textproto {
          export type MIMEHeader = Record<string, string[]>
      }
  }
  ```

**TypeScript bare type layout**
  ```
  $ typex -f=File -l=ts-type mime/multipart

  export module mime {
      export module multipart {
          export type FileHeader = {
              Filename: string,
              Header: net.textproto.MIMEHeader,
              Size: number,
          }
      }
  }
  export module net {
      export module textproto {
          export type MIMEHeader = Record<string, string[]>
      }
  }
  ```

### TypeScript and reserved keywords
Basically, the names of types and fields will be exported from Go without modification.
Collisions with reserved keywords or standard type names in the target language may occur.
To avoid conflicts, you may use the JSON tag annotation for the exported fields of a struct as described in the [json.Marshal(...)](https://golang.org/pkg/encoding/json/#Marshal) documentation.

### TypeScript and exportable types
Due to fundamental language differences, ```typex``` is not capable of exporting all type declarations one-to-one. Refer to the type mapping table below. 
Go channel, interface and function declarations will be omitted, references to these declarations will be typed with ```any```.

### TypeScript type mapping
TypeScript (resp. JavaScript aka ECMAScript) lacks a native integer number type.
The numeric type provided there is inherently a 64 bit float.
You should keep this in mind when working with exported numeric types - this includes `byte` and `rune` type aliases as well.    

|Go native type|TypeScript type
| --- | ---
|```bool```|```boolean```
|```string```|```string```
|```map```|```Record<K, V>```
|```struct``` ```(named)```|```T```
|```struct``` ```(anonymous)```|```{}```
|```array``` ```(slice)```|```T[]```
|```complex```[```64```&vert;```128```]|```any```
|```chan```, ```func```, ```interface```|```any```
|```int```[```8```&vert;```16```&vert;```32```&vert;```64```]|```number```
|```uint```[```8```&vert;```16```&vert;```32```&vert;```64```]|```number```
|```byte```(=```uint8```)|```number```
|```rune```(=```int32```)|```number```
|```float```[```32```&vert;```64```]|```number```
|```uintptr```|```number```

### Usage

```
$ typex -h
```
```
Usage: typex [options] package...
Examine Go types and their transitive dependencies. Export
results as TypeScript value objects (or types) declaration.

Options:
    -f <name>
        Type name filter expression. Repeating the -f option
        is allowed, all expressions aggregate to an OR query.

        The <name> filter can be a type name, a path part or
        a regular expression. Especially in the latter case,
        <name> should be quoted or escaped correctly to avoid
        errors during shell interpolation. Filters are case
        sensitive, see examples below.

        The result tree will contain additional references to
        transitive dependencies vital for the filtered types.

    -l <layout>
        Modify the export layout. Available layouts are:
          * "go":       the default Go type dependency tree
          * "ts-type":  TypeScript type declaration projection
          * "ts-class": TypeScript value object projection

    -r <old-path>:<new-path>
        Replace matching portions of <old-path> in a fully
        qualified type name with <new-path> string. Repeating
        the -r option is allowed, substitutions will perform
        successively. <old-path> can be a regular expression.
        
        The path replacement/relocation can be used to modify
        locations of type hierarchies, e.g. prune off the
        "github.com" reference from qualified type name path
        by omitting the <new-path> part after the colon. 

    -t  Go tests (files suffixed _test.go) will be included
        in the result tree available for a filter expression

    -u  Unexported types (lowercase names) will be included
        in the result tree available for a filter expression.

    -x <name> 
        Exclude type names from export. Repeating this option
        is allowed, all expressions aggregate to an OR query.
        The exclusion filter can be a type name, a path part
        or a regular expression.

More options:
    -h  Display this usage help and exit.
    -v  Print program version and exit.

The 'package' argument denotes one or more package import path
patterns to be inspected. Patterns must be separated by space.
A pattern containing '...' specifies the active modules whose
modules paths match the pattern.

Examples:
    $ typex -u go/...
    $ typex -u -f=URL net/url
    $ typex github.com/your/repository/...
    $ typex -l=ts-type github.com/your/repository/...
    $ typex -r=github.com:a/b/c github.com/your/repository/...

This tool relies heavily on Go's package managing subsystem and
is bound to its features and environmental execution context.
```

### Known issues
* Occasional(?) ```internal error``` from Go's package managing subsystem [has been reported](https://github.com/dtgorski/typex/issues/4) on Go 1.14.6 darwin/amd64. Newer Go versions >= 1.15 seem to be not affected.

### Disclaimer
The implementation and features of ```typex``` follow the [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) principle.
There is no claim for completeness or reliability.

### @dev
Try ```make```:
```
$ make

 make help       Displays this list
 make clean      Removes build/test artifacts
 make build      Builds a static binary to ./bin/typex
 make debug      Starts debugger [:2345] with ./bin/typex
 make install    Compiles and installs typex in Go environment
 make test       Runs tests, reports coverage
 make tidy       Formats source files, cleans go.mod
 make sniff      Checks format and runs linter (void on success)
```

### License
[MIT](https://opensource.org/licenses/MIT) - © dtg [at] lengo [dot] org


typex

[![Ceasefire Now](https://badge.techforpalestine.org/default)](https://techforpalestine.org/learn-more)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)
# GoTutor

GoTutor is a project aimed at capturing the execution steps of a Go program by interacting with the Delve debugger server. It retrieves variable values and stack information of all running Goroutines at each Go statement.

https://gotutor.dev/

## Features

- Capture running Goroutines and its stack frames state at each Go statement of the main Goroutine.
- Interactive online Debugging tool: https://gotutor.dev/.

## Architecture
The project is split into three components:
- CLI tool: that takes a go program and produces `output/steps.json` file which represent the execution steps of the program (exists under `.`)
- backend: run the CLI tool for the given program and return the execution steps (exists under `backend/`)
- frontend: the frontend of https://gotutor.dev/ which is build using [elm-lang](https://elm-lang.org/) (exists under `frontend/`)

## Limitations
Currently, the project has limitations when handling multiple goroutines. When using `next` or `step` on a single goroutine, all goroutines progress, making it difficult to capture the state of other goroutines. This issue is documented in [Delve Issue #1529](https://github.com/go-delve/delve/issues/1529).
Attempts to create a client for each goroutine and step through them individually have been unsuccessful and have caused runtime errors in the Delve server.

## Usage
the commands follow `dlv` cli terminology

### exec
```
gotutor exec binary_path
```
run delve server with the binary that `gotutor` will interact with to get execution steps

### debug
```
gotutor debug
```
build the go module in the current directory then contine the same as exec

### connect
```
gotutor connect delve_server_address
```
connect to already running delve server

the execution steps will be written to `steps.json` file in the current direcotry

### Prerequisites

- Go (latest version)
- Delve debugger

### Installation

```
go install github.com/ahmedakef/gotutor@latest
```

## docker

```
docker build -t gotutor . # or directly use ahmedakef/gotutor image to download it from docker hub
docker run --rm -v $(pwd)/example/main.go:/data/main.go -v $(pwd)/output/:/root/output gotutor debug /data/main.go
```

## Contributing

Contributions are welcome! Please open an issue or submit a pull request.

## License

This project is licensed under the MIT License.


## Give a Star! ⭐

If you like this project or are using it to learn or start your own solution, give it a star to get updates on new releases. Your support matters!

## Buy me a coffee

<a href='https://ko-fi.com/M4M319RW5Y' target='_blank'><img height='36' style='border:0px;height:36px;' src='https://storage.ko-fi.com/cdn/kofi6.png?v=6' border='0' alt='Buy Me a Coffee at ko-fi.com' /></a>


gotutor

Zero-config, pure-Go HTTP request visualizer & debugger for local Go web development

# GoVisual

A lightweight, zero-configuration HTTP request visualizer and debugger for Go web applications during local development.

### Featured In

- [**Applied Go Weekly**](https://newsletter.appliedgo.net/archive/2025-05-11-tuppers-formula/) — May 2025
- [**GDG Berlin Golang Meetup**](https://www.youtube.com/watch?v=5ZbpWDnYxLM) — Talk: "Building GoVisual: Zero-Config HTTP Debugging in Go" (Jan 2026)
- [**Hacker News**](https://news.ycombinator.com/front?day=2025-05-04) — Show HN front page
- [**Golang Weekly (X)**](https://x.com/golangch/status/1918925327843422248) — 9,100+ impressions

## Features

- **Real-time Request Monitoring**: Visualize HTTP requests passing through your application
- **Request Inspection**: Deep inspection of headers, body, status codes, and timing information
- **Middleware Tracing**: Visualize middleware execution flow and identify performance bottlenecks
- **Zero Configuration**: Drop-in integration with standard Go HTTP handlers
- **OpenTelemetry Integration**: Optional export of telemetry data to OpenTelemetry collectors

## Installation

```bash
go get github.com/doganarif/govisual
```

## Quick Start

```go
package main

import (
    "net/http"
    "github.com/doganarif/govisual"
)

func main() {
    mux := http.NewServeMux()

    // Add your routes
    mux.HandleFunc("/api/users", userHandler)

    // Wrap with GoVisual
    handler := govisual.Wrap(
        mux,
        govisual.WithRequestBodyLogging(true),
        govisual.WithResponseBodyLogging(true),
    )

    http.ListenAndServe(":8080", handler)
}
```

Access the dashboard at `http://localhost:8080/__viz`

## Documentation

For detailed documentation, please refer to the [DOCS](docs/README.md).

## Configuration Options

```go
handler := govisual.Wrap(
    mux,
    govisual.WithMaxRequests(100),              // Number of requests to store
    govisual.WithDashboardPath("/__dashboard"), // Custom dashboard path
    govisual.WithRequestBodyLogging(true),      // Log request bodies
    govisual.WithResponseBodyLogging(true),     // Log response bodies
    govisual.WithIgnorePaths("/health"),        // Paths to ignore
    govisual.WithOpenTelemetry(true),           // Enable OpenTelemetry
    govisual.WithServiceName("my-service"),     // Service name for OTel
    govisual.WithServiceVersion("1.0.0"),       // Service version
    govisual.WithOTelEndpoint("localhost:4317"), // OTLP endpoint

    // Storage options (choose one)
    govisual.WithMemoryStorage(),                // In-memory storage (default)
    govisual.WithPostgresStorage(               // PostgreSQL storage
        "postgres://user:password@localhost:5432/database?sslmode=disable",
        "govisual_requests"                     // Table name
    ),
    govisual.WithRedisStorage(                  // Redis storage
        "redis://localhost:6379/0",             // Redis connection string
        86400                                   // TTL in seconds (24 hours)
    ),
)
```

## Storage Backends

GoVisual supports multiple storage backends for storing request logs:

### In-Memory Storage (Default)

The default storage keeps all request logs in memory. This is the simplest option but logs will be lost when the application restarts.

```go
handler := govisual.Wrap(
    mux,
    govisual.WithMemoryStorage(), // Optional, this is the default
)
```

### PostgreSQL Storage

For persistent storage, you can use PostgreSQL. This requires the `github.com/lib/pq` package.

```go
handler := govisual.Wrap(
    mux,
    govisual.WithPostgresStorage(
        "postgres://user:password@localhost:5432/dbname?sslmode=disable", // Connection string
        "govisual_requests"  // Table name (created automatically if it doesn't exist)
    ),
)
```

### Redis Storage

For high-performance storage with automatic expiration, you can use Redis. This requires the `github.com/go-redis/redis/v8` package.

```go
handler := govisual.Wrap(
    mux,
    govisual.WithRedisStorage(
        "redis://localhost:6379/0", // Redis connection string
        86400                       // TTL in seconds (24 hours)
    ),
)
```

## SQLite Driver Conflict

If you're already using a SQLite driver in your application (such as `github.com/mattn/go-sqlite3`), you may experience a conflict when using govisual with SQLite storage:

```
panic: sql: Register called twice for driver sqlite3
```

This occurs because both your application and govisual try to register the SQLite driver with the same name.

To resolve this issue, you can pass your existing database connection to govisual:

```go
import (
    "database/sql"

    "github.com/doganarif/govisual"
    _ "github.com/mattn/go-sqlite3" // Your preferred SQLite driver
)

func main() {
    // Create your own database connection
    db, err := sql.Open("sqlite3", "path/to/your/database.db")
    if err != nil {
        // Handle error
    }
    defer db.Close()

    // Pass the existing connection to govisual
    app := gin.New()
    visualHandler := govisual.Wrap(
        app,
        govisual.WithSQLiteStorageDB(db, "govisual_requests"),
    )

    // Use visualHandler as your main handler
    http.ListenAndServe(":8080", visualHandler)
}
```

This approach allows you to:

1. Use your preferred SQLite driver
2. Avoid driver registration conflicts
3. Reuse your existing connection

## Examples

### Basic Example

Simple example showing core functionalities:

```bash
cd cmd/examples/basic
go run main.go
```

### OpenTelemetry Example

Example showing integration with OpenTelemetry:

```bash
cd cmd/examples/otel
docker-compose up -d  # Start Jaeger
go run main.go
```

### Multi-Storage Example

Example showing different storage backends:

```bash
cd cmd/examples/multistorage
docker-compose up -d  # Start PostgreSQL and Redis
```

Modify the environment variables in `docker-compose.yml` to switch between storage backends.

Visit [Multi-Storage Example](cmd/examples/multistorage/README.md) for detailed instructions.

## Dashboard Features

![GoVisual Dashboard](docs/dashboard.png)

- **Request Table**: View all captured HTTP requests with method, path, status code, and response time
- **Request Details**: One-click access to headers, body content, and timing information
- **Middleware Trace**: Interactive visualization of middleware execution flow
- **Request Filtering**: Filter by HTTP method, status code, path pattern, or duration
- **Real-time Updates**: See new requests appear instantly as they happen

## License

MIT License

## Contributing

Contributions are welcome! Please feel free to submit a Pull Request.


govisual

# lensm

A tool for viewing assembly and source.

![Screenshot](./screenshot.gif)

Install with the usual Go commands:

```
go install loov.dev/lensm@main
```

_For Linux you may need to add some [additional dependencies](https://gioui.org/doc/install/linux). You can use `go install --tags nowayland loov.dev/lensm@main` or `go install --tags nox11 loov.dev/lensm@main` respectively to skip building Wayland or X11 version._

To run the program provide a regular expression filter for the
function you want to inspect. `-watch` allows to automatically
reload the executable and information when it changes.

```
lensm -watch -filter Fibonacci lensm
```

Note: The program requires a binary that is built on your computer, otherwise the source code for the functions cannot be loaded.

## Why?

I wrote a blog post at https://www.storj.io/blog/lensm on why and how the core functionality works.


lensm

Go tool that executes and caches binaries included in go.mod files

![gomodrun](assets/banner.jpg)

[![Build Status](https://img.shields.io/github/workflow/status/dustinblackman/gomodrun/Test?branch=master)](https://github.com/dustinblackman/gomodrun/actions)
[![Release](https://img.shields.io/github/v/release/dustinblackman/gomodrun)](https://github.com/dustinblackman/gomodrun/releases)
[![Coverage Status](https://coveralls.io/repos/github/dustinblackman/gomodrun/badge.svg?branch=master)](https://coveralls.io/github/dustinblackman/gomodrun?branch=master)
[![Go Report Card](http://goreportcard.com/badge/dustinblackman/gomodrun)](http://goreportcard.com/report/dustinblackman/gomodrun)
[![Godocs](https://godoc.org/github.com/dustinblackman/gomodrun?status.svg)](https://pkg.go.dev/github.com/dustinblackman/gomodrun?tab=doc)

The forgotten go tool that executes and caches binaries included in go.mod files. This makes it easy to version cli tools in your projects such as `golangci-lint` and `ginkgo` that are versioned locked to what you specify in `go.mod`. Binaries are cached by go version and package version.

## Example

```sh
  # Run a linter
  gomodrun golangci-lint run

  # Convert a JSON object to a Go struct, properly passing in stdin.
  echo example.json | gomodrun gojson > example.go

  # Specifiy alternative root directory containing a go.mod and tools file.
  gomodrun -r ./alternative-tools-dir golangci-lint run

  # Clean your .gomodrun folder of unused binaries.
  gomodrun --tidy
```

## Install

### Source

```sh
curl -L "https://github.com/dustinblackman/gomodrun/archive/refs/heads/master.tar.gz" | tar zxvf - -C /tmp
cd /tmp/gomodrun-master/cmd/gomodrun
go install .
```

## Usage

gomodrun works by using a `tools.go` (or any other name) file that sits in the root of your project that contains all the CLI dependencies you want bundled in to your `go.mod`. Note the `// +build tools` at the top of the file is required, and allows you to name your tools file anything you like.

__tools.go__

```go
// +build tools

package myapp

import (
	_ "github.com/golangci/golangci-lint/cmd/golangci-lint"
	_ "github.com/onsi/ginkgo/ginkgo"
)
```

Run `go build tools.go` to add the dependencies to your `go.mod`. The build is expected to fail.

### CLI

You can run your tools by prefixing `gomodrun`. A binary will be built and cached in `.gomodrun` in the root of your project, allowing all runs after the first to be nice and fast.

```sh
  gomodrun golangci-lint run
```

### Programmatically

You can also use `gomodrun` as a library.

```go
package main

import (
	"os"

	"github.com/dustinblackman/gomodrun"
)

func main() {
	exitCode, err := gomodrun.Run("golangci-lint", []string{"run"}, &gomodrun.Options{
		Stdin:   os.Stdin,
		Stdout:  os.Stdout,
		Stderr:  os.Stderr,
		Env:     os.Environ(),
		PkgRoot: "",
	})
}
```


## [License](./LICENSE)

MIT


gomodrun

GoThanks automatically stars your go.mod github dependencies, sending this way some love to their maintainers

<p align="center"><img width="500" src="gothanks.png"></p>

![Build Status](https://github.com/psampaz/gothanks/workflows/CI%20Workflow/badge.svg)
[![Go Report Card](https://goreportcard.com/badge/github.com/psampaz/gothanks)](https://goreportcard.com/report/github.com/psampaz/gothanks)
[![GoDoc](https://godoc.org/github.com/psampaz/gothanks?status.svg)](https://godoc.org/github.com/psampaz/gothanks)

Give thanks (in the form of a GitHub ★) to your fellow Go modules maintainers. 

# About

GoThanks performs the following operations

- Sends a star to Go's repo (github.com/golang.go)
- Reads your go.mod file and sends a star to every Github repository that your app/library depends on

This is a simple way to say thanks to the maintainers of the modules you use and the contributors of Go itself.

# Credits

GoThanks is a Go port of symfony/thanks implemented by Nicolas Grekas (nicolas-grekas) for PHP.

Original idea by Doug Tangren (softprops) for Rust.

# Installation

```go
$ go get -u github.com/psampaz/gothanks
```

# Usage

In order to run GoThanks you need to have a valid [Github Access Token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line) with `public_repo` scope. 

You can pass the token as an argument to GoThanks or store it in an environmental variable named GITHUB_TOKEN.

Inside the folder where your go.mod lives run:

```go
$ ./gothanks -github-token=xxxxxx
```

or 

```go
$ export GITHUB_TOKEN=xxxxx
$ ./gothanks
```
## Docker

Run

```
docker run -it --rm -v $(pwd):/home psampaz/gothanks:latest -github-token=xxxxxx
```

or 

```
docker run -it --rm -v $(pwd):/home --env GITHUB_TOKEN=xxxxxx psampaz/gothanks:latest
```

# Example

```go
$ ./gothanks
Welcome to GoThanks :)

You are about to star you beloved dependencies.

Press y to continue or n to abort
y

Sending your love..

Repository github.com/golang/go is already starred!
Repository github.com/golang/net is already starred!
Sending a star to github.com/google/go-github
Sending a star to github.com/stretchr/testify
Sending a star to github.com/sirupsen/logrus

Thank you!
```

You can also run it on non-interactive environments using `-y` flag.

```go
$ ./gothanks -y
Welcome to GoThanks :)

Sending your love..

Repository github.com/golang/go is already starred!
Repository github.com/google/go-github is already starred!
Repository github.com/sirkon/goproxy is already starred!
Repository github.com/golang/crypto is already starred!
Repository github.com/golang/net is already starred!
Repository github.com/golang/oauth2 is already starred!

Thank you!
```


gothanks

Monitor current state of all active goroutines via a command line interface

# roumon

![Build Status](https://github.com/becheran/roumon/workflows/CI/badge.svg)
[![Go Report Card][go-report-image]][go-report-url]
[![PRs Welcome][pr-welcome-image]][pr-welcome-url]
[![License][license-image]][license-url]
[![Go Reference](https://pkg.go.dev/badge/github.com/becheran/roumon.svg)](https://pkg.go.dev/github.com/becheran/roumon)
[![Coverage Status](https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_86.svg)](https://coveralls.io/github/becheran/roumon?branch=main)

[license-url]: https://github.com/becheran/roumon/blob/main/LICENSE
[license-image]: https://img.shields.io/badge/License-MIT-brightgreen.svg
[go-report-image]: https://img.shields.io/badge/go%20report-A+-brightgreen.svg?style=flat
[go-report-url]: https://goreportcard.com/report/github.com/becheran/roumon
[pr-welcome-image]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg
[pr-welcome-url]: https://github.com/becheran/roumon/blob/main/CONTRIBUTING.md

A go**rou**tine **mon**itor to keep track of active routines from within your favorite shell.

![screenshot](doc/Screenshot.png)

## Features

* Track live state of all active goroutines
* Terminal user interface written with [termui](https://github.com/gizak/termui) 🤓
* Simple to integrate [pprof server](https://pkg.go.dev/net/http/pprof) for live monitoring
* Dynamic history of goroutine count
* Full-text filtering
* Overview of routine states

## Installation

```sh
go install github.com/becheran/roumon@latest
```

Or download the pre-compiled binaries from the [releases page](https://github.com/becheran/roumon/releases).

## Usage

Before starting roumon, the go app which shall be monitored needs to be prepared to export pprof infos via http.

### pprof

The program which shall be monitored needs to run a [pprof server](https://pkg.go.dev/net/http/pprof).

Import pprof into you program:

``` go
import _ "net/http/pprof"
```

Run a webserver which will listen on a specific port:

``` go
go func() {
    log.Println(http.ListenAndServe("localhost:6060", nil))
}()
```

Start your program and check that the `pprof` site is available in you web-browser:  `http://localhost:6060/debug/pprof`

### roumon

Start *roumon* in from your command line interface. Use optional arguments if needed.

For example `roumon -debug=logfile -host=192.168.10.1 -port=8081` will start the routine monitor for the *pprof profiles* exposed to `192.168.10.1:8081` and write a debug logfile to `./logfile`.

Run *roumon* with `-h` or `--help` to see all commandline argument options:

``` txt
Usage of roumon:
  -debug string
        Path to debug file 
  -host string
        The pprof server IP or hostname (default "localhost")
  -port int
        The pprof server port (default 6060)
```

From within the *Terminal User Interface (TUI)* hit `F1` for help `F10` or `ctrl-c` to stop the application.

## Contributing

Pull requests and issues [are welcome](./CONTRIBUTING.md)!


The Best Go Libraries For Go Tools (23)