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`, and `PE` 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
Usage: 
	gsa <file> [flags]
	gsa <old file> <new file> [flags]

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

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

```

> [!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).


go-size-analyzer

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

# Swagger 2.0 [![Run CI](https://github.com/go-swagger/go-swagger/actions/workflows/test.yaml/badge.svg)](https://github.com/go-swagger/go-swagger/actions/workflows/test.yaml) [![codecov](https://codecov.io/gh/go-swagger/go-swagger/branch/master/graph/badge.svg)](https://codecov.io/gh/go-swagger/go-swagger)[![Go Report Card](https://goreportcard.com/badge/github.com/go-swagger/go-swagger)](https://goreportcard.com/report/github.com/go-swagger/go-swagger)

[![GitHub version](https://badge.fury.io/gh/go-swagger%2Fgo-swagger.svg)](https://badge.fury.io/gh/go-swagger%2Fgo-swagger) [![Docker Repository on Quay](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=Docker%20Repository%20on%20Quay&query=%24.tags[:1].name)](https://quay.io/repository/goswagger/swagger?tab=tags) [![Docker Repository on Github](https://ghcr-badge.egpl.dev/go-swagger/go-swagger/latest_tag?trim=major&ignore=sha-*&label=Docker%20Repository%20on%20Github)](https://github.com/orgs/go-swagger/packages/container/go-swagger/versions) ![GitHub commits since latest release](https://img.shields.io/github/commits-since/go-swagger/go-swagger/latest)

[![Slack Status](https://slackin.goswagger.io/badge.svg)](https://slackin.goswagger.io)
[![license](http://img.shields.io/badge/license-Apache%20v2-orange.svg)](https://raw.githubusercontent.com/swagger-api/swagger-spec/master/LICENSE)
[![GoDoc](https://godoc.org/github.com/go-swagger/go-swagger?status.svg)](http://godoc.org/github.com/go-swagger/go-swagger)

[![Open SSF Scorecard](https://api.securityscorecards.dev/projects/github.com/go-swagger/go-swagger/badge)](https://securityscorecards.dev/viewer/?uri=github.com/go-swagger/go-swagger)
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger?ref=badge_shield)

---

This project contains a golang implementation of Swagger 2.0 (aka [OpenAPI 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/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>

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

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](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fgo-swagger%2Fgo-swagger?ref=badge_large)


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": "io.Writer"
    }
  ]
}
{
  "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/ofabry/go-callvis/releases"><img src="https://img.shields.io/github/release/ofabry/go-callvis.svg" alt="Github release"></a>
  <a href="https://github.com/ofabry/go-callvis/actions"><img src="https://github.com/ofabry/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)](https://raw.githubusercontent.com/ofabry/go-callvis/master/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.
  -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/ofabry/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/ofabry/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/ofabry/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/ofabry/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

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

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)

![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/)
- [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

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

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 - Performance Monitoring 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)
![Visitors](https://api.visitorbadge.io/api/visitors?path=iyashjayesh%2Fmonigo%20&countColor=%23263759&style=flat)
![GitHub last commit](https://img.shields.io/github/last-commit/iyashjayesh/monigo)
<a href="https://www.producthunt.com/posts/monigo?embed=true&utm_source=badge-featured&utm_medium=badge&utm_souce=badge-monigo" target="_blank"><img src="https://api.producthunt.com/widgets/embed-image/v1/featured.svg?post_id=487815&theme=light" alt="MoniGO - Go&#0032;App&#0032;Performance&#0032;Dashboard&#0032;in&#0032;10&#0032;Seconds&#0032;with&#0032;R&#0045;T&#0032;Insight&#0033; | Product Hunt" style="width: 250px; height: 54px;" width="250" height="54" /></a>



**MoniGo** is a performance monitoring library for Go applications. It provides real-time insights into application performance with an intuitive user interface, enabling developers to track and optimize both service-level and function-level metrics.

<div align="center" style="display: flex; flex-wrap: wrap; gap: 10px; border: 2px solid #ccc; padding: 10px;">
  <img src="./static/assets/ss/d1.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d10.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d2.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d7.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d8.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d3.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d4.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d5.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d6.png" alt="Dashboard" width="300">
  <img src="./static/assets/ss/d9.png" alt="Dashboard" width="300">
</div>

## Features

- **Real-Time Monitoring**: Access up-to-date performance metrics for your Go applications.
- **Detailed Insights**: Track and analyze both service and function-level performance.
- **Customizable Dashboard**: Manage performance data with an easy-to-use UI.
- **Visualizations**: Utilize graphs and charts to interpret performance trends.
- **Custom Thresholds**: Configure custom thresholds for your application's performance and resource usage.

## Installation

To install MoniGo, use the following command:

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

## Example:

```go
package main

import (
    "github.com/iyashjayesh/monigo"
)

func main() {

	monigoInstance := &monigo.Monigo{
		ServiceName:             "data-api", // Mandatory field
		DashboardPort:           8080,       // Default is 8080
		DataPointsSyncFrequency: "5s",       // Default is 5 Minutes
		DataRetentionPeriod:     "4d",       // Default is 7 days. Supported values: "1h", "1d", "1w", "1m"
		TimeZone:                "Local",    // Default is Local timezone. Supported values: "Local", "UTC", "Asia/Kolkata", "America/New_York" etc. (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)
		// MaxCPUUsage:             90,         // Default is 95%
		// MaxMemoryUsage:          90,         // Default is 95%
		// MaxGoRoutines:           100,        // Default is 100
	}

   	monigo.TraceFunction(highCPUUsage) // Trace function, when the function is called, it will be traced and the metrics will be displayed on the dashboard

	go monigoInstance.Start() // Starting monigo dashboard
	log.Println("Monigo dashboard started at port 8080")

  	// Optional
	// routinesStats := monigoInstance.GetGoRoutinesStats() // Get go routines stats
	// log.Println(routinesStats)

  	select {} // To keep the program running
}

// highCPUUsage is a function that simulates high CPU usage
func highCPUUsage() {
	// Simulate high CPU usage by performing heavy computations
	var sum float64
	for i := 0; i < 1e8; i++ { // 100 million iterations
		sum += math.Sqrt(float64(i))
	}
}
```

For more detailed usage instructions, refer to the documentation.
By default, the dashboard will be available at `http://localhost:8080/` else at the port you have provided.

### Note:

The `monigo.TraceFunction(func())` method accept `func(){}` as a type.

### Example Usage:

```go
func apiHandler(w http.ResponseWriter, r *http.Request) {
    // Trace function: when the highMemoryUsage function is called, it will be traced.
    monigo.TraceFunction(highMemoryUsage)
    w.Write([]byte("API1 response: memexpensiveFunc"))
}

func highMemoryUsage() {
    // Simulate high memory usage by allocating a large slice
    largeSlice := make([]float64, 1e8) // 100 million elements
    for i := 0; i < len(largeSlice); i++ {
        largeSlice[i] = float64(i)
    }
}
```

## Bellow Reports are available

#### Note: You can download the reports in excel format.

1. **Load Statistics**: Provides an overview of the overall load of the service, CPU load, memory load, and system load.

| Field Name                | Value (Datatype) |
| ------------------------- | ---------------- |
| `overall_load_of_service` | `float64`        |
| `service_cpu_load`        | `float64`        |
| `service_memory_load`     | `float64`        |
| `system_cpu_load`         | `float64`        |
| `system_memory_load`      | `float64`        |

2. **CPU Statistics**: Displays the total number of cores, cores used by the service, and cores used by the system.

| Field Name              | Value (Datatype) |
| ----------------------- | ---------------- |
| `total_cores`           | `int`            |
| `cores_used_by_service` | `int`            |
| `cores_used_by_system`  | `int`            |

3. **Memory Statistics**: Shows the total system memory, memory used by the system, memory used by the service, available memory, GC pause duration, and stack memory usage.

| Field Name               | Value (Datatype) |
| ------------------------ | ---------------- |
| `total_system_memory`    | `float64`        |
| `memory_used_by_system`  | `float64`        |
| `memory_used_by_service` | `float64`        |
| `available_memory`       | `float64`        |
| `gc_pause_duration`      | `float64`        |
| `stack_memory_usage`     | `float64`        |

4. **Memory Profile**: Provides information on heap allocation by the service, heap allocation by the system, total allocation by the service, and total memory by the OS.

| Field Name               | Value (Datatype) |
| ------------------------ | ---------------- |
| `heap_alloc_by_service`  | `float64`        |
| `heap_alloc_by_system`   | `float64`        |
| `total_alloc_by_service` | `float64`        |
| `total_memory_by_os`     | `float64`        |

5. **Network IO**: Displays the number of bytes sent and received.

| Field Name       | Value (Datatype) |
| ---------------- | ---------------- |
| `bytes_sent`     | `float64`        |
| `bytes_received` | `float64`        |

6. **Health Metrics**: Provides an overall health percentage for the service.

| Field Name               | Value (Datatype) |
| ------------------------ | ---------------- |
| `service_health_percent` | `float64`        |
| `system_health_percent`  | `float64`        |

## API Reference

- You can access the MoniGo API by visiting the following URL: http://localhost:8080/monigo/api/v1/<endpoint> (replace `<endpoint>` with the desired endpoint).
- API endpoints are available for the following:

| Endpoint                           | Description           | Method | Request                                               | Response | Example                                            |
| ---------------------------------- | --------------------- | ------ | ----------------------------------------------------- | -------- | -------------------------------------------------- |
| `/monigo/api/v1/metrics`           | Get all metrics       | GET    | None                                                  | JSON     | [Example](./static/API/Res/metrics.json)           |
| `/monigo/api/v1/go-routines-stats` | Get go routines stats | GET    | None                                                  | JSON     | [Example](./static/API/Res/go-routines-stats.json) |
| `/monigo/api/v1/service-info`      | Get service info      | GET    | None                                                  | JSON     | [Example](./static/API/Res/service-info.json)      |
| `/monigo/api/v1/service-metrics`   | Get service metrics   | POST   | JSON [Example](./static/API/Req/service-metrics.json) | JSON     | [Example](./static/API/Res/service-metrics.json)   |
| `/monigo/api/v1/reports`           | Get history data      | POST   | JSON [Example](./static/API/Req/reports.json)         | JSON     | [Example](./static/API/Res/reports.json)           |

## Contributing

We welcome contributions! If you encounter any issues or have suggestions, please submit a pull request or open an issue.

**If you find MoniGo useful, consider giving it a star! ⭐**

## Contact

For questions or feedback, please open an issue or contact me at `iyashjayesh@gmail.com` or at [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)

## License

This project is licensed under the Apache 2.0 License - see the [LICENSE file](https://github.com/iyashjayesh/monigo?tab=Apache-2.0-1-ov-file) for details.

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)
[![Coverage Status](https://img.shields.io/codecov/c/github/kyoh86/richgo.svg)](https://codecov.io/gh/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

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://coveralls.io/repos/github/becheran/roumon/badge.svg?branch=main)](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://goreportcard.com/badge/github.com/becheran/roumon
[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://golang.org/pkg/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://golang.org/pkg/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)!


roumon

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


The Best Go Libraries For Go Tools (19)