Checks recent changes to a Go project for backwards incompatible changes

# Introduction

[![Build Status](https://travis-ci.org/bradleyfalzon/apicompat.svg?branch=master)](https://travis-ci.org/bradleyfalzon/apicompat) [![Coverage Status](https://coveralls.io/repos/github/bradleyfalzon/apicompat/badge.svg?branch=master)](https://coveralls.io/github/bradleyfalzon/apicompat?branch=master) [![GoDoc](https://godoc.org/github.com/bradleyfalzon/apicompat?status.svg)](https://godoc.org/github.com/bradleyfalzon/apicompat)

`apicompat` is a tool to check for the introduction of backwards incompatible changes.

`apicompat`:
- Guarantees that all consumers of a library will still build without failure
- Only checks exported declarations
- There are no false positives (if there are, it's a bug)
- Not every backwards incompatible change can be detected, swapping argument parameters and other changes still need to
    be considered by the library author
- Can be simply consumed as a library
- Is in its infancy, see [Status](#status), feedback and review appreciated
- Was originally named `abicheck` during early development

Secondary tasks could include:
- Detecting current semver and suggesting an appropriate increase
- Listing all changes for help in writing release notes/commit messages.

Try at [abicheck.bradleyf.id.au](https://abicheck.bradleyf.id.au/) or via CLI:

```
go get -u github.com/bradleyfalzon/apicompat/cmd/apicompat
cd /your/project/dir/with/committed/changes
apicompat
```

# Proposed Arguments

`apicompat` also comes with a command line tool, as well as being used as a library, the following are the proposed flags
and arguments for the command line tool.

```
-vcs    (auto|git|svn|etc) - Version control system to use (default: auto)
-before revision           - Revisions to check as before  (default: if unstaged changes, check those, else check last two commits)
-after  revision           - Revisions to check as after   (default: if unstaged changes, check those, else check last two commits)
-vcsDir path               - Path to root VCS directory    (default: let VCS tool search)
-all                       - Show non-breaking changes as well as breaking (default: false)

apicompat        # current package only
apicompat ./...  # check subdirectory packages
```

Another tool, called `abichanges` may also be included which will list all detected changes to assist in producing
release notes.

# Status

`apicompat` is currently under heavy development and refactoring. This initial version was a proof of concept and shortcuts were taken. The current tasks are focused on (but not limited to):

- Adding Mercurial, SVN and potentially other VCS systems
- Improve VCS options such as:
    - Detection of VCS and flag to overwrite
    - Choosing base VCS path to allow running for a different directory
    - Filtering `vendor/` directories (if this is the best place to do it, or leave it to go/type ast packages)
    - Check subdirectories if ran from a subdirectory of the VCS (currently checks all committed code)
- Add docs, flow diagram and fixing of existing docs
- Improve output formats (such as vim quickfix)
- Move these tasks to GitHub issues
- Once all other steps have been completed, performance will be investigated

# Testing

This uses golden masters for the tests, currently (and only due to time constraints) `testdata/` directory contains `before.go`
and `after.go`, which are before and after versions of a test package, each time `go test` is ran, the output is compared to
`testdata/exp.txt`, which should not change.

If adding new test cases, you should expect the test to fail as the code changes should create a difference with `exp.txt`.
Then, you'll need to update the golden master (see below), and commit those changes. If you add a new test case to `before.go` and
`after.go`, and the tests still pass, you've uncovered a bug within `apicompat` which will need a code change to fix, once
code has change, the tests should fail, so update the master, review all your changes and commit.

- This uses golden master `testdata/exp.txt` for the tests
- Run tests with: `go test`
- Update master with: `go test -args update`
- Alternatively to do a test run: `go install && ( cd testgit; ./make.sh && apicompat )`


apicompat

Converts golang AST to JSON and JSON to AST

# asty

![GitHub go.mod Go version](https://img.shields.io/github/go-mod/go-version/asty-org/asty)
[![Go Reference](https://pkg.go.dev/badge/github.com/asty-org/asty.svg)](https://pkg.go.dev/github.com/asty-org/asty)
[![Go Report Card](https://goreportcard.com/badge/github.com/asty-org/asty)](https://goreportcard.com/report/github.com/asty-org/asty)
![Codecov](https://img.shields.io/codecov/c/github/asty-org/asty)
[![GitHub last commit](https://img.shields.io/github/last-commit/asty-org/asty)](https://github.com/asty-org/asty)
[![Docker Pulls](https://img.shields.io/docker/pulls/astyorg/asty)](https://hub.docker.com/r/astyorg/asty)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go#code-analysis)

_Not another JSON parser!_

**AST &#8594; JSON** | **JSON &#8594; AST**

Marshals golang [AST](https://pkg.go.dev/go/ast) into JSON and unmarshals it back from JSON.

It allows building pattern matching, statistical analysis, language transformation, search/data-mine/anything algorithms
for golang with any other language (I like to do it with python. Check out [asty-python](https://github.com/asty-org/asty-python))

## Example

[Try it!](https://asty-org.github.io/)

Input golang source

```golang
package main

import "fmt"

func main() {
    fmt.Println("hello world")
}
```

Ouput AST in JSON

```json
{
  "NodeType": "File",
  "Name": {
    "NodeType": "Ident",
    "Name": "main"
  },
  "Decls": [
    {
      "NodeType": "GenDecl",
      "Tok": "import",
      "Specs": [
        {
          "NodeType": "ImportSpec",
          "Name": null,
          "Path": {
            "NodeType": "BasicLit",
            "Kind": "STRING",
            "Value": "\"fmt\""
          }
        }
      ]
    },
    {
      "NodeType": "FuncDecl",
      "Recv": null,
      "Name": {
        "NodeType": "Ident",
        "Name": "main"
      },
      "Type": {
        "NodeType": "FuncType",
        "TypeParams": null,
        "Params": {
          "NodeType": "FieldList",
          "List": null
        },
        "Results": null
      },
      "Body": {
        "NodeType": "BlockStmt",
        "List": [
          {
            "NodeType": "ExprStmt",
            "X": {
              "NodeType": "CallExpr",
              "Fun": {
                "NodeType": "SelectorExpr",
                "X": {
                  "NodeType": "Ident",
                  "Name": "fmt"
                },
                "Sel": {
                  "NodeType": "Ident",
                  "Name": "Println"
                }
              },
              "Args": [
                {
                  "NodeType": "BasicLit",
                  "Kind": "STRING",
                  "Value": "\"hello world\""
                }
              ]
            }
          }
        ]
      }
    }
  ]
}
```

## Install

Install `asty` under `$GOPATH/bin`

```bash
go install github.com/asty-org/asty

asty -h
```

## Building

Just `make`
If you want to do it differently use `go build`

## Usage

Convert AST to JSON

```bash
asty go2json -input <input.go> -output <output.json>
```

Convert JSON to AST

```bash
asty json2go -input <input.json> -output <output.go>
```

Use `asty help` for more information

Using with docker

```bash
docker run astyorg/asty go2json -input <input.go> -output <output.json>
```

## Development principles

- Make json output as close to real golang structures as possible. There is no additional logic introduced.
  No normalization. No reinterpretation. The only things that were introduced are the names of some enum values.
- Make it very explicit. No reflection. No listing of fields. This is done to facilitate future maintenance.
  If something will be changed in future versions of golang this code will probably break compile-time.
- Keep polymorphism in JSON structure. If some field references _expression_ then particular type will be
  discriminated from object type name stored in separate field.

## Other solutions

- https://github.com/ReconfigureIO/goblin reinterpret some structures (trying to simplify).
  Out of maintenance for a long time. Still works in some forks.
- https://github.com/CreativeInquiry/go2json tries to parse golang code with parser written in javascript.
  Also lacks maintenance. Developed for particular use case of HaXe traspiler.

## Article

I wrote [an article](https://dev.to/evgenus/analyzing-ast-in-go-with-json-tools-36dg) about this project.


asty

blanket is a tool that helps you catch functions which don't have direct unit tests in your Go packages.

# blanket

`blanket` is a tool that helps you catch functions which don't have direct unit tests in your Go packages.

## Installation

    go get -u gitlab.com/verygoodsoftwarenotvirus/blanket

## Docker Image

If you don't want to install blanket locally, you can use the pre-built Docker image like so:

    docker run -it --rm -v "$(pwd):/src/<pkg>" verygoodsoftwarenotvirus/blanket:latest analyze --package <pkg>

Where `<pkg>` could be something like `gitlab.com/verygoodsoftwarenotvirus/blanket/analysis`. :)

## Purpose

Say, for example, you had the following Go file:

```go
package simple

func A() string {
    return "A"
}

func B() string {
    return "B"
}

func C() string {
    return "C"
}

func wrapper() {
   A()
   B()
   C()
}
```

and you had the following test for that file:

```go
package simple

import (
    "testing"
)

func TestA(t *testing.T) {
    A()
}

func TestC(t *testing.T) {
    C()
}

func TestWrapper(t *testing.T) {
    wrapper()
}
```

Running `go test -cover` on that package yields the following output:

```bash
PASS
coverage: 100.0% of statements
ok      gitlab.com/verygoodsoftwarenotvirus/blanket/example_packages/simple    0.006s
```

However, note that `B` doesn't have a direct test the way that `A` and `C` do. `B` is only "tested" in `TestWrapper`. Because all the functions are called, `-cover` yields a 100% coverage value. If you ever decide that `wrapper` doesn't need to call `B` anymore, and don't delete the function entirely, you'll have a drop in coverage. Running `blanket analyze` on that same package yields the following output:

```bash
Functions without direct unit tests:
in /Users/vgsnv/golang/src/gitlab.com/verygoodsoftwarenotvirus/blanket/example_packages/simple/main.go:
    B on line 7

Grade: 75% (3/4 functions)
```

Additionally, you can use the `cover` command to visualize those functions by passing in a cover profile. So if you run something like `go test -coverprofile=coverage.out && blanket cover --html=coverage.out`, a browser window will open that shows untested functions in red, functions without direct tests in yellow, and functions that are directly tested in green, like so:

![example output](example_files/cover_screenshot.png)

## Use Cases

What `blanket` seeks to do is catch these sorts of things so that package maintainers can decide what the appropriate course of action is. If you're fine with it, that's cool. If you're not cool with it, then you know what needs to have tests added.

You can also use `blanket` in your CI pipeline to decline PRs that would add functions that don't have direct unit tests. As a matter of fact, `blanket` does just that for itself! [Here](https://gitlab.com/verygoodsoftwarenotvirus/blanket/merge_requests/22) is an example of such a scenario working on this very repository!

I think `blanket` could also be helpful for new developers looking to contribute towards a project. They can run `blanket` on the package and see if there are some functions they could easily add unit tests for, just to get their feet wet in a project.

## Issues

If you've tried blanket on something and found that it didn't accurately handle some code, or panicked, please feel free to [file an issue](https://gitlab.com/verygoodsoftwarenotvirus/blanket/issues/new). Having an example of the code you experienced issues with is pretty crucial, so keep that in mind.

## Known Issues

`blanket` doesn't adequately handle deeply nested method calls. So if you had something like this:

```go
package main

import (
    "testing"
)

/*
// in another file:
type Example struct{}
func methodCall() {
    return
}
*/

func TestMethod(t *testing.T) {
    x := struct{
        First: struct{
            Second: struct{
                Third: Example{},
            },
        },
    }
    x.First.Second.Third.methodCall()
}
```

That should technically satisfy blanket's strict testing requirement, but it doesn't. Blanket can handle single-level selector expressions with great ease, but it doesn't recursively dive into those selectors for a number of reasons.

blanket

# Chronos

<p align="center">
    <img src="https://i.imgur.com/AhLyxVh.jpeg" width="150" height="225">
</p>

[![made-with-Go](https://github.com/go-critic/go-critic/workflows/Go/badge.svg)](http://golang.org)
[![made-with-Go](https://img.shields.io/badge/Made%20with-Go-1f425f.svg)](http://golang.org)
[![MIT license](https://img.shields.io/badge/License-MIT-blue.svg)](https://lbesson.mit-license.org/)
[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
[![amit-davidson](https://circleci.com/gh/amit-davidson/Chronos.svg?style=svg)](https://app.circleci.com/pipelines/github/amit-davidson/Chronos)

Chronos is a static race detector for the Go language written in Go.

## Quick Start:

Download the package

```
go get -v github.com/amit-davidson/Chronos/cmd/chronos
```

Pass the entry point

```
chronos --file <path_to_main> --mod <path_to_module>
```

Help

```
Usage of ./chronos:
  --file string
    	The file containing the entry point of the program
  --mod string
    	Absolute or relative path to the module where the search should be performed. Should end in the format:{VCS}/{organization}/{package}. Packages outside this path are excluded rom the search.
```

## Example:

<p float="left">
    <img src="https://i.imgur.com/LJMP9c2.png" width="245" height="300">
    <img src="https://i.imgur.com/X89VVfr.png" width="700" height="300">
</p>

## Features:

Support:

- Detects races on pointers passed around the program.
- Analysis of conditional branches, nested functions, interfaces, select, gotos, defers, for loops and recursions.
- Synchronization using mutex and goroutines starts.

Limitations:

- Big programs and external packages. (Due to stack overflow)
- Synchronization using channels, waitgroups, once, cond and atomic.

## Chronos vs go race:

Chronos successfully reports cases where go race fails thanks to it's static nature. Mostly because data races appear in unexpected production workloads, which are hard to produce in dev.
In addition, go race is having trouble with short programs where without contrived synchronization the program may exit too quickly.

In contrast, Chronos managed to report only 244/403 = 60.5% of go race test cases. This can be explained by Chronos partial support with Go's features so this number will increase in the future.
Also, it lacked due to his static nature where context/path sensitivity was required.

Therefore, I suggest using both according the strengths and weaknesses of each of the race detectors.

## Credits:

Jan Wen, J., Jhala, R., &amp; Lerner, S. (n.d.). [RELAY: Static Race Detection on Millions of Lines of Code](https://cseweb.ucsd.edu/~lerner/papers/relay.pdf)  
Colin J. Fidge (February 1988). [Timestamps in Message-Passing Systems That Preserve the Partial Ordering"](http://zoo.cs.yale.edu/classes/cs426/2012/lab/bib/fidge88timestamps.pdf)

## More examples:

<p float="left">
    <img src="https://i.imgur.com/NvVWFRf.png" width="230" height="440">
    <img src="https://i.imgur.com/eCNFAX7.png" width=600" height="300">
</p>
<hr style="border:2px solid gray"> </hr>


Chronos

# dupl

**dupl** is a tool written in Go for finding code clones. It can find clones only
in the Go source files. The method uses a suffix tree for serialized ASTs. It ignores
values of AST nodes. It just operates with their types (e.g. `if a == 13 {}` and
`if x == 100 {}` are considered the same provided it exceeds the minimal token
sequence size).

Due to the used method dupl can report so called "false positives" on the output.
These are the ones we do not consider clones (whether they are too small, or the
values of the matched tokens are completely different).

## Installation

```bash
go install github.com/mibk/dupl@latest
```

## Usage

```
Usage: dupl [flags] [paths]

Paths:
  If the given path is a file, dupl will use it regardless of
  the file extension. If it is a directory, it will recursively
  search for *.go files in that directory.

  If no path is given, dupl will recursively search for *.go
  files in the current directory.

Flags:
  -files
        read file names from stdin one at each line
  -html
        output the results as HTML, including duplicate code fragments
  -plumbing
        plumbing (easy-to-parse) output for consumption by scripts or tools
  -t, -threshold size
        minimum token sequence size as a clone (default 100)
  -vendor
        check files in vendor directory
  -v, -verbose
        explain what is being done

Examples:
  dupl -t 200
        Search clones in the current directory of size at least
        200 tokens.
  dupl $(find app/ -name '*_test.go')
        Search for clones in tests in the app directory.
  find app/ -name '*_test.go' |dupl -files
        The same as above.
```

## Example

The reduced output of this command with the following parameters for the
[Docker](https://www.docker.com) source code looks like
[this](http://htmlpreview.github.io/?https://github.com/mibk/dupl/blob/master/_output_example/docker.html).

```bash
$ dupl -t 200 -html >docker.html
```


dupl

Errcheck is a program for checking for unchecked errors in Go programs

# errcheck

errcheck finds silently ignored errors in Go code.

![errcheck](https://github.com/kisielk/errcheck/workflows/errcheck/badge.svg)

For all callables that are not in the excluded list, all returned errors must
be either assigned to a variable or explicitly discarded by being assigned to `_`.

Please note that errcheck does not do any further analysis on assigned errors.

For example, it will not complain about this:

```go
err := foo()

// First error is discarded
err = bar()
if err != nil {
    ...
}
```

For such analysis and more, please see [staticcheck](https://staticcheck.dev/).

## Install

    go install github.com/kisielk/errcheck@latest

errcheck requires Go 1.22 or newer.

## Use

For basic usage, just give the package path of interest as the first argument:

    errcheck github.com/kisielk/errcheck/testdata

To check all packages beneath the current directory:

    errcheck ./...

Or check all packages in your `$GOPATH` and `$GOROOT`:

    errcheck all

errcheck also recognizes the following command-line options:

The `-tags` flag takes a space-separated list of build tags, just like `go
build`. If you are using any custom build tags in your code base, you may need
to specify the relevant tags here.

The `-asserts` flag enables checking for ignored type assertion results. It
takes no arguments.

The `-blank` flag enables checking for assignments of errors to the
blank identifier. It takes no arguments.

The `-abspath` flag prints the absolute paths to files with unchecked errors.

The `-mod` flag sets the module download mode to use: `readonly` or `vendor`.

### go/analysis

The package provides `Analyzer` instance that can be used with
[go/analysis](https://pkg.go.dev/golang.org/x/tools/go/analysis) API.

Currently supported flags are `blank`, `assert`, `exclude`, and `excludeonly`.
Just as the API itself, the analyzer is experimental and may change in the
future.

## Excluding functions

Use the `-exclude` flag to specify a path to a file containing a list of functions to
be excluded.

    errcheck -exclude errcheck_excludes.txt path/to/package

The file should contain one function signature per line. The format for function signatures is
`package.FunctionName` while for methods it's `(package.Receiver).MethodName` for value receivers
and `(*package.Receiver).MethodName` for pointer receivers. If the function name is followed by string of form `(TYPE)`, then
the the function call is excluded only if the type of the first argument is `TYPE`. It also accepts a special suffix
`(os.Stdout)` and `(os.Stderr)`, which excludes the function only when the first argument is a literal `os.Stdout` or `os.Stderr`.

An example of an exclude file is:

    io.Copy(*bytes.Buffer)
    io.Copy(os.Stdout)
    os.ReadFile

    // Sometimes we don't care if a HTTP request fails.
    (*net/http.Client).Do

By default, the exclude list is combined with an internal list for functions in
the Go standard library that have an error return type but are documented to never
return an error. To disable the built-in exclude list, pass the `-excludeonly` flag.

Run errcheck in `-verbose` mode to see the resulting list of added excludes.

When using vendored dependencies, specify the full import path. For example:
* Your project's import path is `example.com/yourpkg`
* You've vendored `example.net/fmt2` as `vendor/example.net/fmt2`
* You want to exclude `fmt2.Println` from error checking

In this case, add this line to your exclude file:
```
example.com/yourpkg/vendor/example.net/fmt2.Println
```

Empty lines and lines starting with `//` are ignored.

### The deprecated method

The `-ignore` flag takes a comma-separated list of pairs of the form package:regex.
For each package, the regex describes which functions to ignore within that package.
The package may be omitted to have the regex apply to all packages.

For example, you may wish to ignore common operations like Read and Write:

    errcheck -ignore '[rR]ead|[wW]rite' path/to/package

or you may wish to ignore common functions like the `print` variants in `fmt`:

    errcheck -ignore 'fmt:[FS]?[Pp]rint*' path/to/package

The `-ignorepkg` flag takes a comma-separated list of package import paths
to ignore:

    errcheck -ignorepkg 'fmt,encoding/binary' path/to/package

Note that this is equivalent to:

    errcheck -ignore 'fmt:.*,encoding/binary:.*' path/to/package

If a regex is provided for a package `pkg` via `-ignore`, and `pkg` also appears
in the list of packages passed to `-ignorepkg`, the latter takes precedence;
that is, all functions within `pkg` will be ignored.

Note that by default the `fmt` package is ignored entirely, unless a regex is
specified for it. To disable this, specify a regex that matches nothing:

    errcheck -ignore 'fmt:a^' path/to/package

The `-ignoretests` flag disables checking of `_test.go` files. It takes
no arguments.

The `-ignoregenerated` flag disables checking of generated source code. It takes no arguments.

## Exit Codes

errcheck returns 1 if any problems were found in the checked files.
It returns 2 if there were any other failures.

# Editor Integration

## Emacs

[go-errcheck.el](https://github.com/dominikh/go-errcheck.el)
integrates errcheck with Emacs by providing a `go-errcheck` command
and customizable variables to automatically pass flags to errcheck.

## Vim

[vim-go](https://github.com/fatih/vim-go) can run errcheck via both its `:GoErrCheck`
and `:GoMetaLinter` commands.


errcheck

go-cleanarch was created to validate Clean Architecture rules, like a The Dependency Rule and interaction between packages in your Go projects

# Clean Architecture checker for Golang

[![Go Report Card](https://goreportcard.com/badge/github.com/roblaszczak/go-cleanarch)](https://goreportcard.com/report/github.com/roblaszczak/go-cleanarch)

go-cleanarch was created to keep Clean Architecture rules,
like a _The Dependency Rule_ and _interaction between modules_ in your Go projects.
For more information you should read [our article about Clean Architecture](https://threedots.tech/post/introducing-clean-architecture/?utm_source=go-cleanarch).


Some benefits of using Clean Architecture:

> 1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
> 2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
> 3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
> 4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
> 5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

_Source: The Clean Architecture_

![Clean Architecture](docs/go-cleanarch.png)

### Project schema requirements

go-cleanarch assumes this files structure:

    [GOPATH]/[PACKAGE_NAME]/[LAYER_NAME]

or

    [GOPATH]/[PACKAGE_NAME]/[MODULE_NAME]/[LAYER_NAME]

For example

* go/src/github.com/roblaszczak/awesome-app
    * auth
        * domain
        * application
        * interfaces
    * content
        * domain
            * submodule1
            * submodule2
            * *etc.*
        * application
        * interfaces
    * frontend
        * domain
        * application
        * interfaces

### Allowed `LAYER_NAME`:

The default layer names are as followed. It is possible to set different names
by command line parameters see -domain/-application/-interfaces/-infrastructure
bellow.

    var LayersAliases = map[string]Layer{
        // Domain
        "domain":   LayerDomain,
        "entities": LayerDomain,

        // Application
        "app":         LayerApplication,
        "application": LayerApplication,
        "usecases":    LayerApplication,
        "usecase":     LayerApplication,
        "use_cases":   LayerApplication,

        // Interfaces
        "interfaces": LayerInterfaces,
        "interface":  LayerInterfaces,
        "adapters":   LayerInterfaces,
        "adapter":    LayerInterfaces,

        // Infrastructure
        "infrastructure": LayerInfrastructure,
        "infra":          LayerInfrastructure,
    }

For examples please go to [examples](examples/) directory,
with contains examples of valid and invalid architectures.

For more information you should read [our article about Clean Architecture](https://threedots.tech/post/introducing-clean-architecture/?utm_source=go-cleanarch).

## Installing

    go install github.com/roblaszczak/go-cleanarch@latest

_go-cleanarch was only tested on Linux and also should work on OS X.
Probably it doesn't work well on Windows._

## Running

To run in the current directory:

    go-cleanarch

To run in provided directory

    go-cleanarch go/src/github.com/roblaszczak/awesome-cms

Process will exit with code `1` if architecture is not valid, otherwise it will exit with `0`.

### -ignore-tests

If you need to ignore `*_test.go` files in `go-cleanarch` check you can pass `-ignore-tests`

    go-cleanarch -ignore-tests

It is useful when you have memory implementation in infrastructure layer
and you need to test application service which depends of it.

### -ignore-package

If for some reason you need to allow to make forbidden import, for example

`github.com/roblaszczak/go-cleanarch/examples/ignore-package/app` to `github.com/roblaszczak/go-cleanarch/examples/ignore-package/domain`.

you can use

    go-cleanarch -ignore-package=github.com/roblaszczak/go-cleanarch/examples/ignore-package/app 

### Layer names

The layer names can be set to a specific value with the following parameters. Each
parameter stands for on layer.

    go-cleanarch -domain dom -application appli -interfaces int -infrastructure outer

This would only allow the domain name to be dom, application hast to be appli,
interafces must be int and infrastructure must be outer.

## Running the tests

    make test

## And coding style tests

    make qa

## Contributing

Please read [CONTRIBUTING.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) for details on our code of conduct, and the process for submitting pull requests to us.

## Versioning

We use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/your/project/tags).

## Credits

Made without love by Robert Laszczak </3

## License

This project is licensed under the MIT License.


go-cleanarch

source code linter that brings checks that are currently not implemented in other linters

# go-critic

![Build Status](https://github.com/go-critic/go-critic/workflows/Go/badge.svg)
[![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/avelino/awesome-go#code-analysis)
[![Go Report Card][go-report-image]][go-report-url]
[![coverage][coverage-image]][coverage-url]
[![PRs Welcome][pr-welcome-image]][pr-welcome-url]

[go-report-image]: https://goreportcard.com/badge/github.com/go-critic/go-critic
[go-report-url]: https://goreportcard.com/report/github.com/go-critic/go-critic
[coverage-image]: https://coveralls.io/repos/github/go-critic/go-critic/badge.svg?branch=master
[coverage-url]: https://coveralls.io/github/go-critic/go-critic?branch=master
[pr-welcome-image]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg
[pr-welcome-url]: https://github.com/go-critic/go-critic/blob/master/CONTRIBUTING.md

Highly extensible Go source code linter providing checks currently missing from other linters.

![Logo](https://avatars1.githubusercontent.com/u/40007520?s=300&u=b44287d8845a63fb0102d5259710c11ea367bb13&v=4)

There is never too much static code analysis. Try it out.

## Features

* Almost 100 diagnostics that check for [bugs](https://go-critic.github.io/overview#checkers-from-the-diagnostic-group), [performance](https://go-critic.github.io/overview#checkers-from-the-performance-group) and [style](https://go-critic.github.io/overview#checkers-from-the-style-group) issues
* Extensible without re-compilation with [dynamic rules](https://quasilyte.dev/blog/post/ruleguard/)
* Includes `#opinionated` checks with very strict and specific requirements
* Self-documented: `go-critic doc <checkname>` gives a checker description

## Documentation

The latest documentation is available at [go-critic.com](https://go-critic.com/overview).

## Installation

For most users, using `go-critic` under [golangci-lint](https://github.com/golangci/golangci-lint) is enough.

Precompiled `go-critic` binaries can be found at [releases](https://github.com/go-critic/go-critic/releases) page.

It can be installed in the usual Go way by running:

```bash
go install -v github.com/go-critic/go-critic/cmd/go-critic@latest
```

To build `go-critic` from sources, clone this repository and run `make go-critic`.

On macOS, you can also install `go-critic` using either Homebrew or MacPorts:

[Homebrew](https://brew.sh)

```zsh
brew install go-critic
```

[MacPorts](https://www.macports.org)

```zsh
sudo port install go-critic
```

## Usage

Be sure `go-critic` executable is under your `$PATH`.

Usage of **go-critic**: `go-critic [sub-command] [sub-command args...]`
Run `go-critic` without arguments to get help output.

```
Supported sub-commands:
	check - run linter over specified targets
		$ go-critic check -help
		$ go-critic check -v -enable='paramTypeCombine,unslice' strings bytes
		$ go-critic check -v -enable='#diagnostic' -disable='#experimental,#opinionated' ./...
	version - print linter version
		$ go-critic version
	doc - get installed checkers documentation
		$ go-critic doc -help
		$ go-critic doc
		$ go-critic doc checkerName
```

`check` sub-command examples:

```bash
# Runs all stable checkers on `fmt` package:
go-critic check fmt

# Run all stable checkers on `pkg1` and `pkg2`
go-critic check pkg1 pkg2

# Run all stable checkers on `fmt` package and configure rangeExprCopy checker
go-critic check -@rangeExprCopy.sizeThreshold 128 fmt

# Runs specified checkers on `fmt` package:
go-critic check -enable elseif,paramName fmt

# Run all stable checkers on current dir and all its children recursively:
go-critic check ./...

# Like above, but without `appendAssign` check:
go-critic check -disable=appendAssign ./...

# Run all stable checkers on `foo.go` file:
go-critic check foo.go

# Run stable diagnostics over `strings` package:
go-critic check -enable='#diagnostic' -disable='#experimental' strings

# Run all stable and non-opinionated checks:
go-critic check -enableAll -disable='#experimental,#opinionated' ./src/...
```

> To get a list of available checker parameters, run `go-critic doc <checkerName>`.

In place of a single name, **tag** can be used. Tag is a named checkers group.

Tags:

* `#diagnostic` - kind of checks that detect various errors in code
* `#style` - kind of checks that find style issues in code
* `#performance` - kind of checks that detect potential performance issues in code
* `#experimental` - check is under testing and development. Disabled by default
* `#opinionated` - check can be unwanted for some people. Disabled by default
* `#security` -  kind of checks that find security issues in code. Disabled by default and empty, so will fail if enabled.

## Contributing

This project aims to be contribution-friendly.

Our chats: [English](https://t.me/go_critic_eng) or
[Russian](https://t.me/go_critic_ru)
([Telegram website](https://telegram.org/))

We're using an optimistic merging strategy most of the time.
In short, this means that if your contribution has some flaws, we can still merge it and then
fix them by ourselves. Experimental and work-in-progress checkers are isolated, so nothing bad will happen.

Code style is the same as in Go project, see [CodeReviewComments](https://go.dev/wiki/CodeReviewComments).

See [CONTRIBUTING.md](CONTRIBUTING.md) for more details.
It also describes how to develop a new checker for the linter.


go-critic

Console application that displays outdated packages.

# This project is not supported anymore

Go-outdated is minimalistic library that helps to find outdated packages hosted on github.com in your golang project.

![Dashboard](https://raw.githubusercontent.com/firstrow/go-outdated/master/sample.png)

## Installation
Install the library with:
``` bash
go get -u github.com/firstrow/go-outdated
```

## Usage
Note: To use this library without limitations, you should create GitHub access token.
``` bash
cd $GOPATH/path/to/your/project
go-outdated
```

## GitHub access token
GitHub API has requests limit. You should create access token and pass it to `go-outdated`
``` bash
go-outdated -token=YOUR_PRIVATE_GITHUB_TOKEN
```

## Re-entering API token
Yes, typing each time access token in command-line is not easy. Use git config to re-use token:
``` bash
git config --global github.token YOUR_PRIVATE_GITHUB_TOKEN
go-outdated # token will be taken from git config
```
Github doc: https://github.com/blog/180-local-github-config

## Aliases
If you for some reason do not want to configure you local git config, You can create command-line alias in your `.zshrc` or `.bashrc` files. Example:
``` bash
alias go-outdated='go-outdated -token=YOUR_PRIVATE_GITHUB_TOKEN'
```

## Todo
- Cache
- Refactor

## Links
How-to create API tokens: https://help.github.com/articles/creating-an-access-token-for-command-line-use/  

## Alternatives:
https://github.com/shurcooL/Go-Package-Store  
https://github.com/divan/gofresh

## License:
The MIT License (MIT) 
http://opensource.org/licenses/MIT


go-outdated

Formatter that automatically shortens long lines in Go code

[![golines test](https://github.com/segmentio/golines/actions/workflows/test.yml/badge.svg)](https://github.com/segmentio/golines/actions/workflows/test.yml)
[![Go Report Card](https://goreportcard.com/badge/github.com/segmentio/golines)](https://goreportcard.com/report/github.com/segmentio/golines)
[![GoDoc](https://godoc.org/github.com/segmentio/golines?status.svg)](https://godoc.org/github.com/segmentio/golines)

# golines

Golines is a Go code formatter that shortens long lines, in addition to all
of the formatting fixes done by [`gofmt`](https://golang.org/cmd/gofmt/).

## Maintenance & Archiving

> [!IMPORTANT]
> As of late 2024, [segmentio/golines](https://github.com/segmentio/golines/) has
> functionally been in maintenance mode and several dependencies appear to be
> similarly unmaintained.
> 
> As of 2025-12-19, this repository
> [has been archived](https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories).
> At the time this repo was archived, the maintainers of golangci-lint
> [maintain a fork](https://github.com/golangci/golines/) that incorporates several
> patches and fixes. This project is unaffiliated with Twilio Segment.
> 
> The original code will remain available and the terms of the license will not be changed.

## Motivation

The standard Go formatting tools (`gofmt`, `goimports`, etc.) are great, but
[deliberately don't shorten long lines](https://github.com/golang/go/issues/11915);
instead, this is an activity left to developers.

While there are different tastes when it comes to line lengths in go, we've generally found
that very long lines are more difficult to read than their shortened alternatives. As an example:

```go
myMap := map[string]string{"first key": "first value", "second key": "second value", "third key": "third value", "fourth key": "fourth value", "fifth key": "fifth value"}
```

vs.

```go
myMap := map[string]string{
	"first key": "first value",
	"second key": "second value",
	"third key": "third value",
	"fourth key": "fourth value",
	"fifth key": "fifth value",
}
```

We built `golines` to give Go developers the option to automatically shorten long lines, like
the one above, according to their preferences.

More background and technical details are available in
[this blog post](https://yolken.net/blog/cleaner-go-code-golines).

## Examples

See this [before](_fixtures/end_to_end.go) and [after](_fixtures/end_to_end__exp.go)
view of a file with very long lines. More example pairs can be found in the
[`_fixtures`](_fixtures) directory.

## Version support

Since v0.10.0, releases of `golines` have required at least Go 1.18 due to
generics-related dependencies. As of v0.13.0, `golines` requires a minimum of
Go 1.23 due to transitive requirements introduced by dependencies.

Generally, the [minimum version](https://go.dev/ref/mod#go-mod-file-go) in [`go.mod`](./go.mod)
is the absolute minimum required version of Go for any given version of `golines.`

If you need to use `golines` with an older version of go, install the tool from
the `v0.9.x` or `v0.12.x` releases.

## Usage

First, install the tool. If you're using Go 1.21 or newer, run:

```text
go install github.com/segmentio/golines@latest
```

Otherwise, for older Go versions, run:

```text
go install github.com/segmentio/golines@v0.9.0
```

Then, run:

```text
golines [paths to format]
```

The paths can be either directories or individual files. If no paths are
provided, then input is taken from `stdin` (as with `gofmt`).

By default, the results are printed to `stdout`. To overwrite the existing
files in place, use the `-w` flag.

## Options

Some other options are described in the sections below. Run `golines --help` to
see all available flags and settings.

### Line length settings

By default, the tool tries to shorten lines that are longer than 100 columns
and assumes that 1 tab = 4 columns. The latter can be changed via the
`-m` and `-t` flags respectively.

#### Dry-run mode

Running the tool with the `--dry-run` flag will show pretty, git-style diffs.

#### Comment shortening

Shortening long comment lines is harder than shortening code because comments can
have arbitrary structure and format. `golines` includes some basic
logic for shortening single-line (i.e., `//`-prefixed) comments, but this is turned
off by default since the quality isn't great. To enable this feature anyway, run
with the `--shorten-comments` flag.

#### Custom formatters

By default, the tool will use [`goimports`](https://godoc.org/golang.org/x/tools/cmd/goimports)
as the base formatter (if found), otherwise it will revert to `gofmt`. An explicit
formatter can be set via the `--base-formatter` flag; the command provided here
should accept its input via `stdin` and write its output to `stdout`.

#### Generated files

By default, the tool will not format any files that look like they're generated.
If you want to reformat these too, run with the flag `--ignore-generated=false`.

#### Chained method splitting

There are several possible ways to split lines that are part of
[method chains](https://en.wikipedia.org/wiki/Method_chaining). The original
approach taken by `golines` was to split on the args, e.g.:

```go
myObj.Method(
	arg1,
	arg2,
	arg3,
).AnotherMethod(
	arg1,
	arg2,
).AThirdMethod(
	arg1,
	arg2,
)
```

Starting in version 0.3.0, the tool now splits on the dots by default, e.g.:

```go
myObj.Method(arg1, arg2, arg3).
	AnotherMethod(arg1, arg2).
	AThirdMethod(arg1, arg2)
```

The original behavior can be used by running the tool with the
`--no-chain-split-dots` flag.

#### Struct tag reformatting

In addition to shortening long lines, the tool also aligns struct tag keys; see the
associated [before](_fixtures/struct_tags.go) and [after](_fixtures/struct_tags__exp.go)
examples in the `_fixtures` directory. To turn this behavior off, run with `--no-reformat-tags`.

## Developer Tooling Integration

### vim-go

Add the following lines to your vimrc, substituting `128` with your preferred line length:

```vim
let g:go_fmt_command = "golines"
let g:go_fmt_options = {
    \ 'golines': '-m 128',
    \ }
```

### Visual Studio Code

1. Install the [Run on Save](https://marketplace.visualstudio.com/items?itemName=emeraldwalk.RunOnSave) extension
2. Go into the VSCode settings menu, scroll down to the section for the "Run on Save"
  extension, click the "Edit in settings.json" link
3. Set the `emeraldwalk.runonsave` key as follows
   (adding other flags to the `golines` command as desired):
```
    "emeraldwalk.runonsave": {
        "commands": [
            {
                "match": "\\.go$",
                "cmd": "golines ${file} -w"
            }
        ]
    }
```

1. Save the settings and restart VSCode

### Goland

1. Go into the Goland settings and click "Tools" -> "File Watchers" then click the plus to create a new file watcher
2. Set the following properties:
   - __Name:__ `golines`
   - __File type:__ `Go files`
   - __Scope:__ `Project Files`
   - __Program:__ `golines`
   - __Arguments:__ `$FilePath$ -w`
   - __Output paths to refresh:__ `$FilePath$`
3. In the "Advanced Options" section uncheck the __Auto-save edited files to trigger the watcher__ setting
4. Confirm by clicking OK
5. Activate your newly created file watcher in the Goland settings under "Tools" -> "Actions on save"

### Others

Coming soon.

## How It Works

For each input source file, `golines` runs through the following process:

1. Read the file, break it into lines
2. Add a specially-formatted annotation (comment) to each line that's longer
  than the configured maximum
3. Use [Dave Brophy's](https://github.com/dave) excellent
  [decorated syntax tree](https://github.com/dave/dst) library to parse the code
  plus added annotations
4. Do a depth-first traversal of the resulting tree, looking for nodes
  that have an annotation on them
5. If a node is part of a line that's too long, shorten it by altering
  the newlines around the node and/or its children
6. Repeat steps 2-5 until no more shortening can be done
7. Run the base formatter (e.g., `gofmt`) over the results, write these to either
  `stdout` or the source file

See [this blog post](https://yolken.net/blog/cleaner-go-code-golines) for more technical details.

## Limitations

The tool has been tested on a variety of inputs, but it's not perfect. Among
other examples, the handling of long lines in comments could be improved. If you see
anything particularly egregious, please report via an issue.


golines

Library and CLI that generates text plantump class diagram containing information about structures and interfaces with the relationship among them

[![godoc reference](https://img.shields.io/badge/godoc-reference-blue.svg)](https://godoc.org/github.com/jfeliu007/goplantuml/parser) [![Go Report Card](https://goreportcard.com/badge/github.com/jfeliu007/goplantuml)](https://goreportcard.com/report/github.com/jfeliu007/goplantuml) [![codecov](https://codecov.io/gh/jfeliu007/goplantuml/branch/master/graph/badge.svg)](https://codecov.io/gh/jfeliu007/goplantuml) [![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](https://opensource.org/licenses/MIT)
[![GitHub release](https://img.shields.io/github/release/jfeliu007/goplantuml.svg)](https://github.com/jfeliu007/goplantuml/releases/)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go) 
[![DUMELS Diagram](https://server.dumels.com/api/v1/badge/23ff0222-e93b-4e9f-a4ef-4d5d9b7a5c7d)](https://www.dumels.com/shdv/p/0497cfda-9623-4c02-8aea-ac040817c128) 
# GoPlantUML V2

GoPlantUML is an open-source tool developed to streamline the process of generating PlantUML diagrams from Go source code. With GoPlantUML, developers can effortlessly visualize the structure and relationships within their Go projects, aiding in code comprehension and documentation. By parsing Go source code and producing PlantUML diagrams, GoPlantUML empowers developers to create clear and concise visual representations of their codebase architecture, package dependencies, and function interactions. This tool simplifies the documentation process and enhances collaboration among team members by providing a visual overview of complex Go projects. GoPlantUML is actively maintained and welcomes contributions from the Go community.

## Want to try it on your code? 
Take a look at [www.dumels.com](https://www.dumels.com). We have created dumels using this library. 

## Code of Conduct
Please, review the code of conduct [here](https://github.com/jfeliu007/goplantuml/blob/master/CODE_OF_CONDUCT.md "here").

### Prerequisites
golang 1.17 or above

### Installing

```
go get github.com/jfeliu007/goplantuml/parser
go install github.com/jfeliu007/goplantuml/cmd/goplantuml@latest
```

This will install the command goplantuml in your GOPATH bin folder.

### Usage

```
goplantuml [-recursive] path/to/gofiles path/to/gofiles2
```
```
goplantuml [-recursive] path/to/gofiles path/to/gofiles2 > diagram_file_name.puml
```
```
Usage of goplantuml:
  -aggregate-private-members
        Show aggregations for private members. Ignored if -show-aggregations is not used.
  -hide-connections
        hides all connections in the diagram
  -hide-fields
        hides fields
  -hide-methods
        hides methods
  -ignore string
        comma separated list of folders to ignore
  -notes string
        Comma separated list of notes to be added to the diagram
  -output string
        output file path. If omitted, then this will default to standard output
  -recursive
        walk all directories recursively
  -show-aggregations
        renders public aggregations even when -hide-connections is used (do not render by default)
  -show-aliases
        Shows aliases even when -hide-connections is used
  -show-compositions
        Shows compositions even when -hide-connections is used
  -show-connection-labels
        Shows labels in the connections to identify the connections types (e.g. extends, implements, aggregates, alias of
  -show-implementations
        Shows implementations even when -hide-connections is used
  -show-options-as-note
        Show a note in the diagram with the none evident options ran with this CLI
  -title string
        Title of the generated diagram
  -hide-private-members
        Hides all private members (fields and methods)
```

#### Example
```
goplantuml $GOPATH/src/github.com/jfeliu007/goplantuml/parser
```
```
// echoes

@startuml
namespace parser {
    class Struct {
        + Functions []*Function
        + Fields []*Parameter
        + Type string
        + Composition []string
        + Extends []string

    }
    class LineStringBuilder {
        + WriteLineWithDepth(depth int, str string) 

    }
    class ClassParser {
        - structure <font color=blue>map</font>[string]<font color=blue>map</font>[string]*Struct
        - currentPackageName string
        - allInterfaces <font color=blue>map</font>[string]<font color=blue>struct</font>{}
        - allStructs <font color=blue>map</font>[string]<font color=blue>struct</font>{}

        - structImplementsInterface(st *Struct, inter *Struct) 
        - parsePackage(node ast.Node) 
        - parseFileDeclarations(node ast.Decl) 
        - addMethodToStruct(s *Struct, method *ast.Field) 
        - getFunction(f *ast.FuncType, name string) 
        - addFieldToStruct(s *Struct, field *ast.Field) 
        - addToComposition(s *Struct, fType string) 
        - addToExtends(s *Struct, fType string) 
        - getOrCreateStruct(name string) 
        - getStruct(structName string) 
        - getFieldType(exp ast.Expr, includePackageName bool) 

        + Render() 

    }
    class Parameter {
        + Name string
        + Type string

    }
    class Function {
        + Name string
        + Parameters []*Parameter
        + ReturnValues []string

    }
}
strings.Builder *-- parser.LineStringBuilder


@enduml
```
```
goplantuml $GOPATH/src/github.com/jfeliu007/goplantuml/parser > ClassDiagram.puml
// Generates a file ClassDiagram.puml with the previous specifications
```

There are two different relationships considered in goplantuml:
- Interface implementation
- Type Composition

The following example contains interface implementations and composition. Notice how the signature of the functions
```golang
package testingsupport

//MyInterface only has one method, notice the signature return value
type MyInterface interface {
	foo() bool
}

//MyStruct1 will implement the foo() bool function so it will have an "extends" association with MyInterface
type MyStruct1 struct {
}

func (s1 *MyStruct1) foo() bool {
	return true
}

//MyStruct2 will be directly composed of MyStruct1 so it will have a composition relationship with it
type MyStruct2 struct {
	MyStruct1
}

//MyStruct3 will have a foo() function but the return value is not a bool, so it will not have any relationship with MyInterface
type MyStruct3 struct {
    Foo MyStruct1
}

func (s3 *MyStruct3) foo() {

}
```
This will be generated from the previous code
```
@startuml
namespace testingsupport {
    interface MyInterface  {
        - foo() bool

    }
    class MyStruct1 << (S,Aquamarine) >> {
        - foo() bool

    }
    class MyStruct2 << (S,Aquamarine) >> {
    }
    class MyStruct3 << (S,Aquamarine) >> {
        - foo() 

        + Foo MyStruct1

    }
}
testingsupport.MyStruct1 *-- testingsupport.MyStruct2

testingsupport.MyInterface <|-- testingsupport.MyStruct1

testingsupport.MyStruct3 o-- testingsupport.MyStruct1

@enduml
```

![alt text](https://raw.githubusercontent.com/jfeliu007/goplantuml/master/example/example.png)

### Diagram using www.dumels.com
[UML Diagram](https://www.dumels.com/diagram/23ff0222-e93b-4e9f-a4ef-4d5d9b7a5c7d)

### Diagram rendered in plantuml online server
[UML Diagram](https://www.plantuml.com/plantuml/uml/SoWkIImgAStDuSfBp4qjBaXCJbKeIIqkoSnBBoujACWlAb6evb80WioyajIYD92qRwKdd0sIX09TXRJyV0rDXQJy_1mki6Wjc4pEIImk1ceABYagJIunLB2nKT08rd4iB4tCJIpAp4lLLB2p8zaO8np6uDHWJAozN70HRGMt_7o4ms6EgUL23HyzXDUqT7KLS4WQSM5gGmIZJGrkdOOOEX5-oiUhpI4rBmKOim00)

For instructions on how to render these diagrams locally using plantuml please visit [https://plantuml.com](https://plantuml.com)


GoPlantUML

Adds zero-value return statements to match the func return types

This tool adds zero-value return values to incomplete Go return
statements, to save you time when writing Go. It is inspired by
and based on goimports.

![short screencast](screencast.gif)

full 30-second screencast: http://youtu.be/hyEMO9vtKZ8

For example, the following incomplete return statement:

	func F() (*MyType, int, error) { return errors.New("foo") }

is made complete by adding nil and 0 returns (the zero values for
*MyType and int):

	func F() (*MyType, int, error) { return nil, 0, errors.New("foo") }

To install:

	go get -u github.com/sqs/goreturns

To run:

	goreturns file.go

To view a diff showing what it'd do on a sample file:

	goreturns -d $GOPATH/github.com/sqs/goreturns/_sample/a.go

Editor integration: replace gofmt or goimports in your post-save hook
with goreturns. By default goreturns calls goimports on files before
performing its own processing.

It acts the same as gofmt (same flags, etc) but in addition to code
formatting, also fixes returns.


goreturns

Command line tool, shows the status of repositories that contain Go packages

gostatus
========

[![Go Reference](https://pkg.go.dev/badge/github.com/shurcooL/gostatus.svg)](https://pkg.go.dev/github.com/shurcooL/gostatus)

gostatus is a command line tool that shows the status of Go repositories.

Installation
------------

```sh
go install github.com/shurcooL/gostatus@latest
```

Usage
-----

```sh
Usage: gostatus [flags] [packages]
       [newline separated packages] | gostatus -stdin [flags]
  -c	Compact output with inline notation.
  -debug
    	Cause the repository data to be printed in verbose debug format.
  -f	Force not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original.
  -stdin
    	Read the list of newline separated Go packages from stdin.
  -v	Verbose mode. Show all Go packages, not just ones with notable status.

Examples:
  # Show status of all packages.
  gostatus all

  # Show status of package in current directory.
  gostatus

  # Show status of all dependencies (recursive) of package in current dir.
  go list -deps | gostatus -stdin -v

Legend:
  ? - Not under version control or unreachable remote
  b - Non-default branch checked out
  * - Uncommited changes in working dir
  + - Update available
  - - Local revision is ahead of remote revision
  ± - Update available; local revision is ahead of remote revision
  ! - No remote
  / - Remote repository not found (was it deleted? made private?)
  # - Remote path doesn't match import path
  $ - Stash exists
```

Examples
--------

```sh
# Show status of all packages.
$ gostatus all

# Show status of package in current directory.
$ gostatus

# Show status of specified package.
$ gostatus import/path

# Show status of all dependencies (recursive) of package in current dir.
$ go list -deps | gostatus -stdin -v

# Show status of all dependencies (recursive) of specified package.
$ go list -deps import/path | gostatus -stdin -v
```

Sample Output
-------------

```sh
$ gostatus all
  +  github.com/dchest/uniuri/...
	+ Update available
  +  github.com/syndtr/goleveldb/...
	+ Update available
b    github.com/shurcooL/go-goon/...
	b Non-default branch checked out
 *   github.com/shurcooL/Conception-go/...
	* Uncommited changes in working dir
  #  github.com/russross/blackfriday/...
	# Remote path doesn't match import path
   $ github.com/microcosm-cc/bluemonday/...
	$ Stash exists
  /  github.com/go-forks/go-pkg-xmlx/...
	/ Remote repository not found (was it deleted? made private?):
		remote repository not found:
		exit status 128: remote: Repository not found.
		fatal: repository 'https://github.com/go-forks/go-pkg-xmlx/' not found
```

There are a few observations that can be made from that sample output.

-	`uniuri` and `goleveldb` repos are ***out of date***, I should update them via `go get -u`.
-	`go-goon` repo has a ***non-default*** branch checked out, I should be aware of that.
-	`Conception-go` repo has ***uncommited changes***. I should remember to commit or discard the changes.
-	`blackfriday` repo has a ***remote that doesn't match its import path***. It's likely my fork in place of the original repo for temporary development purposes.
-	`bluemonday` repo has a ***stash***. Perhaps I have some unfinished and uncommited work that I should take care of.
-	`go-pkg-xmlx` repo was ***not found***. Perhaps the repository was deleted or made private.
-	All other repos are ***up to date*** and looking good (they're not displayed unless `-v` is used).

Directories
-----------

| Path                                                             | Synopsis                                                                                          |
|------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| [status](https://pkg.go.dev/github.com/shurcooL/gostatus/status) | Package status provides a func to check if two repo URLs are equal in the context of Go packages. |

License
-------

-	[MIT License](LICENSE)


gostatus

Static code analyser which links TODO comments in code with issues in your issue tracker

todocheck

A linter that detect the possibility to use variables/constants from the Go standard library

<img align="right" alt="usestdlibvars" src="./assets/uslv_logo.svg">

# usestdlibvars

A linter that detect the possibility to use variables/constants from the Go standard library.

## Install

### `go install`

```bash
go install github.com/sashamelentyev/usestdlibvars@latest
```

### `golangci-lint`

`usestdlibvars` is already integrated with
[golangci-lint](https://github.com/golangci/golangci-lint).

## Usage

### Binary

```console
$ usestdlibvars -h
usestdlibvars: A linter that detect the possibility to use variables/constants from the Go standard library.

Usage: usestdlibvars [-flag] [package]


Flags:
  -V    print version and exit
  -all
        no effect (deprecated)
  -c int
        display offending line with this many lines of context (default -1)
  -constant-kind
        suggest the use of constant.Kind.String()
  -cpuprofile string
        write CPU profile to this file
  -crypto-hash
        suggest the use of crypto.Hash.String()
  -debug string
        debug flags, any subset of "fpstv"
  -fix
        apply all suggested fixes
  -flags
        print analyzer flags in JSON
  -http-method
        suggest the use of http.MethodXX (default true)
  -http-status-code
        suggest the use of http.StatusXX (default true)
  -json
        emit JSON output
  -memprofile string
        write memory profile to this file
  -os-dev-null
        suggest the use of os.DevNull
  -rpc-default-path
        suggest the use of rpc.DefaultXXPath
  -source
        no effect (deprecated)
  -sql-isolation-level
        suggest the use of sql.LevelXX.String()
  -tags string
        no effect (deprecated)
  -test
        indicates whether test files should be analyzed, too (default true)
  -time-layout
        suggest the use of time.Layout
  -time-month
        suggest the use of time.Month.String()
  -time-weekday
        suggest the use of time.Weekday.String()
  -tls-signature-scheme
        suggest the use of tls.SignatureScheme.String()
  -trace string
        write trace log to this file
  -v    no effect (deprecated)
```

### `golangci-lint`

```console
golangci-lint run --disable-all --enable usestdlibvars
```

## Examples

```go
package response

import (
	"bytes"
	"encoding/json"
	"net/http"
)

// JSON marshals v to JSON, automatically escaping HTML,
// setting the Content-Type header as "application/json; charset=utf-8",
// sends an HTTP response header with the provided statusCode and
// writes the marshaled v as bytes to the connection as part of an HTTP reply.
func JSON(w http.ResponseWriter, statusCode int, v any) {
	var buf bytes.Buffer
	enc := json.NewEncoder(&buf)
	enc.SetEscapeHTML(true)
	if err := enc.Encode(v); err != nil {
		http.Error(w, err.Error(), 500)
		return
	}
	w.Header().Set("Content-Type", "application/json; charset=utf-8")
	w.WriteHeader(statusCode)
	if _, err := w.Write(buf.Bytes()); err != nil {
		http.Error(w, err.Error(), 500)
		return
	}
}
```

```bash
usestdlibvars ./...
```

```console
response.go:18:30: "500" can be replaced by http.StatusInternalServerError
response.go:24:30: "500" can be replaced by http.StatusInternalServerError
```

## Sponsors

[<img src="https://evrone.com/logo/evrone-sponsored-logo.png">](https://evrone.com/?utm_source=usestdlibvars)


usestdlibvars

An ultra-super-fast, lightweight OpenAPI linter and quality checking tool

vacuum

A linter to check that errors from external packages are wrapped

# Wrapcheck

[![Go Report Card](https://goreportcard.com/badge/github.com/tomarrell/wrapcheck)](https://goreportcard.com/report/github.com/tomarrell/wrapcheck)
[![Tests](https://github.com/tomarrell/wrapcheck/actions/workflows/test.yaml/badge.svg)](https://github.com/tomarrell/wrapcheck/actions/workflows/test.yaml)

A simple Go linter to check that errors from external packages are wrapped
during return to help identify the error source during debugging.

> More detail in [this article](https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go)

## Install

Go `>= v1.22.0`
```bash
$ go install github.com/tomarrell/wrapcheck/v2/cmd/wrapcheck@v2
```

Wrapcheck is also available as part of the golangci-lint meta linter. Docs and
usage instructions are available
[here](https://github.com/golangci/golangci-lint). When used with golangci-lint,
configuration is integrated with the `.golangci.yaml` file.

## Configuration

You can configure wrapcheck by using a `.wrapcheck.yaml` file in either the
local directory, or in your home directory.

```yaml
# An array of strings which specify substrings of signatures to ignore. If this
# set, it will override the default set of ignored signatures. You can find the
# default set at the top of ./wrapcheck/wrapcheck.go.
ignoreSigs:
- .Errorf(
- errors.New(
- errors.Unwrap(
- errors.Join(
- .Wrap(
- .Wrapf(
- .WithMessage(
- .WithMessagef(
- .WithStack(

# An array of strings specifying additional substrings of signatures to ignore.
# Unlike ignoreSigs, this option extends the default set (or the set specified
# in ignoreSigs) without replacing it entirely. This allows you to add specific
# signatures to the ignore list while retaining the defaults or any items in
# ignoreSigs.
extraIgnoreSigs:
- .CustomError(
- .SpecificWrap(

# An array of strings which specify regular expressions of signatures to ignore.
# This is similar to the ignoreSigs configuration above, but gives slightly more
# flexibility.
ignoreSigRegexps:
- \.New.*Error\(

# An array of glob patterns which, if any match the package of the function
# returning the error, will skip wrapcheck analysis for this error. This is
# useful for broadly ignoring packages and/or subpackages from wrapcheck
# analysis. There are no defaults for this value.
ignorePackageGlobs:
- encoding/*
- github.com/pkg/*

# ignoreInterfaceRegexps defines a list of regular expressions which, if matched
# to a underlying interface name, will ignore unwrapped errors returned from a
# function whose call is defined on the given interface.
ignoreInterfaceRegexps:
- ^(?i)c(?-i)ach(ing|e)

# ReportInternalErrors determines whether wrapcheck should report errors returned
# from inside the package.
reportInternalErrors: true
```

## Usage

To lint all the packages in a program:

```bash
$ wrapcheck ./...
```

## Testing

This linter is tested using `analysistest`, you can view all the test cases
under the [testdata](./wrapcheck/testdata) directory.

## TLDR

If you've ever been debugging your Go program, and you've seen an error like
this pop up in your logs.

```log
time="2020-08-04T11:36:27+02:00" level=error error="sql: error no rows"
```

Then you know exactly how painful it can be to hunt down the cause when you have
many methods which looks just like the following:

```go
func (db *DB) getUserByID(userID string) (User, error) {
	sql := `SELECT * FROM user WHERE id = $1;`

	var u User
	if err := db.conn.Get(&u, sql, userID); err != nil {
		return User{}, err // wrapcheck error: error returned from external package is unwrapped
	}

	return u, nil
}

func (db *DB) getItemByID(itemID string) (Item, error) {
	sql := `SELECT * FROM item WHERE id = $1;`

	var i Item
	if err := db.conn.Get(&i, sql, itemID); err != nil {
		return Item{}, err // wrapcheck error: error returned from external package is unwrapped
	}

	return i, nil
}
```

The problem here is that multiple method calls into the `sql` package can return
the same error. Therefore, it helps to establish a trace point at the point
where error handing across package boundaries occurs.

To resolve this, simply wrap the error returned by the `db.Conn.Get()` call.

```go
func (db *DB) getUserByID(userID string) (User, error) {
	sql := `SELECT * FROM user WHERE id = $1;`

	var u User
	if err := db.Conn.Get(&u, sql, userID); err != nil {
		return User{}, fmt.Errorf("failed to get user by ID: %v", err) // No error!
	}

	return u, nil
}

func (db *DB) getItemByID(itemID string) (Item, error) {
	sql := `SELECT * FROM item WHERE id = $1;`

	var i Item
	if err := db.Conn.Get(&i, sql, itemID); err != nil {
		return Item{}, fmt.Errorf("failed to get item by ID: %v", err) // No error!
	}

	return i, nil
}
```

Now, your logs will be more descriptive, and allow you to easily locate the
source of your errors.

```log
time="2020-08-04T11:36:27+02:00" level=error error="failed to get user by ID: sql: error no rows"
```

A further step would be to enforce adding stack traces to your errors instead
using
[`errors.WithStack()`](https://pkg.go.dev/github.com/pkg/errors?tab=doc#WithStack)
however, enforcing this is out of scope for this linter for now.

## Why?

Errors in Go are simple values. They contain no more information about than the
minimum to satisfy the interface:

```go
type Error interface {
  Error() string
}
```

This is a fantastic feature, but can also be a limitation. Specifically when you
are attempting to identify the source of an error in your program.

As of Go 1.13, error wrapping using `fmt.Errorf(...)` is the recommend way to
compose errors in Go in order to add additional information.

Errors generated by your own code are usually predictable. However, when you
have a few frequently used libraries (think `sqlx` for example), you may run
into the dilemma of identifying exactly where in your program these errors are
caused.

In other words, you want a call stack.

This is especially apparent if you are a diligent Gopher and always hand your
errors back up the call stack, logging at the top level.

So how can we solve this?

## Solution

Wrapping errors at the call site.

When we call into external libraries which may return an error, we can wrap the
error to add additional information about the call site.

e.g.

```go
...

func (db *DB) createUser(name, email, city string) error {
  sql := `INSERT INTO customer (name, email, city) VALUES ($1, $2, $3);`

  if _, err := tx.Exec(sql, name, email, city); err != nil {
    // %v verb preferred to prevent error becoming part of external API
    return fmt.Errorf("failed to insert user: %v", err)
  }

  return nil
}

...
```

This solution allows you to add context which will be handed to the caller,
making identifying the source easier during debugging.

## Contributing

As with most static analysis tools, this linter will likely miss some obscure
cases. If you come across a case which you think should be covered and isn't,
please file an issue including a minimum reproducible example of the case.

## License

This project is licensed under the MIT license. See the [LICENSE](./LICENSE) file for more
details.



wrapcheck

Fatcontext detects nested contexts in loops or function literals

# fatcontext

[![Go Reference](https://pkg.go.dev/badge/github.com/Crocmagnon/fatcontext.svg)](https://pkg.go.dev/github.com/Crocmagnon/fatcontext)
[![Go Report Card](https://goreportcard.com/badge/github.com/Crocmagnon/fatcontext)](https://goreportcard.com/report/github.com/Crocmagnon/fatcontext)
[![Go Coverage](https://github.com/Crocmagnon/fatcontext/wiki/coverage.svg)](https://github.com/Crocmagnon/fatcontext/wiki/Coverage)

`fatcontext` is a Go linter which detects potential fat contexts in loops or function literals.
They can lead to performance issues, as documented here: https://gabnotes.org/fat-contexts/

## Installation / usage

`fatcontext` is available in `golangci-lint` since v1.58.0.

```bash
go install go.augendre.info/fatcontext/cmd/fatcontext@latest
fatcontext ./...
```

## Example

```go
package main

import "context"

func ok() {
	ctx := context.Background()

	for i := 0; i < 10; i++ {
		ctx := context.WithValue(ctx, "key", i)
		_ = ctx
	}
}

func notOk() {
	ctx := context.Background()

	for i := 0; i < 10; i++ {
		ctx = context.WithValue(ctx, "key", i) // "nested context in loop"
		_ = ctx
	}
}
```

## Development

Setup pre-commit locally:
```bash
pre-commit install
```

Run tests & linter:
```bash
make lint test
```

To release, just publish a git tag:
```bash
git tag -a v0.1.0 -m "v0.1.0"
git push --follow-tags
```


fatcontext

An easy way to find outdated dependencies of your Go projects

go-mod-outdated

A fast Go linters runner. It runs linters in parallel, uses caching, supports `yaml` config, has integrations with all major IDE and has dozens of linters included

<p align="center">
  <img alt="golangci-lint logo" src="assets/go.png" height="150" />
  <h3 align="center">golangci-lint</h3>
  <p align="center">Fast linters runner for Go</p>
</p>

---

`golangci-lint` is a fast Go linters runner.

It runs linters in parallel, uses caching, supports YAML configuration,
integrates with all major IDEs, and includes over a hundred linters.

## Install `golangci-lint`

- [On my machine](https://golangci-lint.run/docs/welcome/install/local);
- [On CI/CD systems](https://golangci-lint.run/docs/welcome/install/ci).

## Documentation

Documentation is hosted at https://golangci-lint.run.

## Social Networks

[![Join Slack](https://img.shields.io/badge/Slack-4285F4?logo=slack&logoColor=white)](https://gophers.slack.com/archives/CS0TBRKPC)
[![Follow on Mastodon](https://img.shields.io/badge/Mastodon-6364FF?logo=mastodon&logoColor=white)](https://fosstodon.org/@golangcilint)
[![Follow on Bluesky](https://img.shields.io/badge/Bluesky-0a7aff?logo=bluesky&logoColor=white)](https://bsky.app/profile/golangci-lint.run)
[![Follow on Twitter](https://img.shields.io/badge/Twitter-1DA1F2?logo=x&logoColor=white)](https://twitter.com/golangci)

## Support Us

`golangci-lint` is a free and open-source project built by volunteers.

If you value it, consider supporting us, we appreciate it! :heart:

[![Golangci-lint](https://img.shields.io/badge/Support-golangci_lint-blue?style=for-the-badge)](https://donate.golangci.org)
[![Linter Authors](https://img.shields.io/badge/Support-Linter_Authors-blue?style=for-the-badge)](https://golangci-lint.run/docs/product/thanks/)

## Badges

![Build Status](https://github.com/golangci/golangci-lint/workflows/CI/badge.svg)
[![License](https://img.shields.io/github/license/golangci/golangci-lint)](/LICENSE)
[![Release](https://img.shields.io/github/release/golangci/golangci-lint.svg)](https://github.com/golangci/golangci-lint/releases/latest)
[![Docker](https://img.shields.io/docker/pulls/golangci/golangci-lint)](https://hub.docker.com/r/golangci/golangci-lint)
[![GitHub Releases Stats of golangci-lint](https://img.shields.io/github/downloads/golangci/golangci-lint/total.svg?logo=github)](https://somsubhra.github.io/github-release-stats/?username=golangci&repository=golangci-lint)

## Contributors

This project exists thanks to all the people who contribute. [How to contribute](https://golangci-lint.run/docs/contributing/).

<a href="https://github.com/golangci/golangci-lint/graphs/contributors">
  <img src="https://opencollective.com/golangci-lint/contributors.svg?width=890&button=false&skip=golangcidev,CLAassistant,renovate,fossabot,golangcibot,kortschak,golangci-releaser,dependabot%5Bbot%5D" />
</a>

## Sponsors

<p>&nbsp;</p>
<p float="left">
  <a href="https://www.jetbrains.com/go/?utm_source=OSS&utm_medium=referral&utm_campaign=golangci" target="_blank">
    <picture>
      <source media="(prefers-color-scheme: dark)" srcset="assets/goland-white.svg">
      <source media="(prefers-color-scheme: light)" srcset="assets/goland.svg">
      <img alt="The complete IDE crafted for professional Go developers." src="assets/goland.svg" width="150" />
    </picture>
  </a>
</p>

## Stargazers over time

[![Stargazers over time](https://starchart.cc/golangci/golangci-lint.svg?variant=adaptive)](https://starchart.cc/golangci/golangci-lint)


golangci-lint

## Lint - run linters from Go

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

Lint makes it easy to run linters from Go code. This allows lint checks to be part of a regular `go build` + `go test` workflow. False positives are easily ignored and linters are automatically integrated into CI pipelines without any extra effort. Check the [project website](https://www.timeferret.com/lint) to learn more about how it can be useful.

### Quick Start

Download using
```
go get -t github.com/surullabs/lint
```
Run the default linters by adding a new test at the top level of your repository
```
func TestLint(t *testing.T) {
    // Run default linters
    err := lint.Default.Check("./...")
    
    // Ignore lint errors from auto-generated files
    err = lint.Skip(err, lint.RegexpMatch(`_string\.go`, `\.pb\.go`))
    
    if err != nil {
        t.Fatal("lint failures: %v", err)
    }
}
```

### How it works

`lint` runs linters using the excellent `os/exec` package. It searches all Go binary directories for the needed binaries and when they don't exist it downloads them using `go get`. Errors generated by running linters are split by newline and can be skipped as needed.

### Default linters

  - `gofmt` - [Run `gofmt -d` and report any differences as errors](https://golang.org/cmd/gofmt/)
  - `govet` - [Run `go tool vet -shadow`](https://golang.org/cmd/vet/)
  - `golint` - [https://github.com/golang/lint](https://github.com/golang/lint)
  - `gosimple` - [Code simplification](https://github.com/dominikh/go-simple)
  - `gostaticcheck` - [Verify function arguments](https://github.com/dominikh/go-staticcheck)
  - `errcheck` - [Find ignored errors](https://github.com/kisielk/errcheck)
  
## Using `gometalinter`

[Gometalinter](https://github.com/alecthomas/gometalinter) runs a number of linters concurrently. It also vendors each of these and uses the vendored versions automatically. A vendored version of `gometalinter` is included and can be used in the following manner. Please note that not all linters used by gometalinter have been tested.
 
```
import (
    "testing"
    "github.com/surullabs/lint/gometalinter"
)

func TestLint(t *testing.T) {
    // Run default linters
    metalinter := gometalinter.Check{
        Args: []string{
            // Arguments to gometalinter. Do not include the package names here.
        },
    }
    if err := metalinter.Check("./..."); err != nil {
        t.Fatal("lint failures: %v", err)
    }
}

```
 
## Other available linters
 
  - `varcheck` - [Detect unused variables and constants](https://github.com/opennota/check)
  - `structcheck` - [Detect unused struct fields](https://github.com/opennota/check)
  - `aligncheck` - [Detect suboptimal struct alignment](https://github.com/opennota/check)
  - `dupl` - [Detect duplicated code](https://github.com/mibk/dupl)
 
### Why `lint`?

There are a number of excellent linters available for Go and Lint makes it easy to run them from tests. While building our mobile calendar app [TimeFerret](https://www.timeferret.com), (which is built primarily in Go), including scripts that run linters as part of every repository grew tiresome very soon. Using `lint` to create tests that ran on each commit made the codebase much more stable, since any unneeded false positives were easily skipped. The main advantages of using `lint` over running tools manually is:

  - Skip false positives explicitly in your tests - This makes it easy to run only needed checks.
  - Enforce linter usage with no overhead - No special build scripts are needed to install linters on each developer machine as they are automatically downloaded.
  - Simple CI integration - Since linters are run as part of tests, there are no extra steps needed to integrate them into your CI pipeline.

### Adding a custom linter

Please check if you can use the [gometalinter](https://godoc.org/github.com/surullabs/lint/gometalinter) package first. If not, adding a new linter is made dead simple by the `github.com/surullabs/lint/checkers` package. The entire source for the `golint` integration is

```
import "github.com/surullabs/lint/checkers"

type Check struct {
}

func (Check) Check(pkgs ...string) error {
    return checkers.Lint("golint", "", github.com/golang/lint/golint", pkgs)
}
```

The `github.com/surullabs/lint/testutil` package contains utilities for testing custom linters.

You can also take a look at [this CL](https://github.com/surullabs/lint/commit/5e6be15e3b9964e8465655abb9759defd1c46af9) which adds `varcheck` for an example of how to add a linter.

If you'd like to vendor the linter source, please use the same method as the `gometalinter` package.

### License

Lint is available under the Apache License. See the LICENSE file for details.

### Contributing

Pull requests are always welcome! Please ensure any changes you send have an accompanying test case.


lint

PHP Parser written in Go
========================

<img src="./parser.jpg" alt="PHP Parser written in Go" width="980"/>

[![GoDoc](https://godoc.org/github.com/z7zmey/php-parser?status.svg)](https://godoc.org/github.com/z7zmey/php-parser)
[![Build Status](https://travis-ci.org/z7zmey/php-parser.svg?branch=master)](https://travis-ci.org/z7zmey/php-parser)
[![Go Report Card](https://goreportcard.com/badge/github.com/z7zmey/php-parser)](https://goreportcard.com/report/github.com/z7zmey/php-parser)
[![Maintainability](https://api.codeclimate.com/v1/badges/950783b2e739db26e0ed/maintainability)](https://codeclimate.com/github/z7zmey/php-parser/maintainability)
[![Test Coverage](https://api.codeclimate.com/v1/badges/950783b2e739db26e0ed/test_coverage)](https://codeclimate.com/github/z7zmey/php-parser/test_coverage)

This project uses [goyacc](https://godoc.org/golang.org/x/tools/cmd/goyacc) and [ragel](https://www.colm.net/open-source/ragel/) tools to create PHP parser. It parses source code into [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree). It can be used to write static analysis, refactoring, metrics, code style formatting tools.

#### Try it online: [demo](https://php-parser.com)

Features:
---------

- Fully support PHP 5 and PHP 7 syntax
- Abstract syntax tree (AST) representation
- Traversing AST
- Resolving namespaced names
- Parsing syntax-invalid PHP files
- Saving and printing free-floating comments and whitespaces

Who Uses
--------

[VKCOM/noverify](https://github.com/VKCOM/noverify) - NoVerify is a pretty fast linter for PHP

[quasilyte/phpgrep](https://github.com/quasilyte/phpgrep) - phpgrep is a tool for syntax-aware PHP code search

Usage example
-------

```Golang
package main

import (
	"log"
	"os"

	"github.com/z7zmey/php-parser/pkg/cfg"
	"github.com/z7zmey/php-parser/pkg/errors"
	"github.com/z7zmey/php-parser/pkg/parser"
	"github.com/z7zmey/php-parser/pkg/version"
	"github.com/z7zmey/php-parser/pkg/visitor/dumper"
)

func main() {
	src := []byte(`<? echo "Hello world";`)

	// Error handler

	var parserErrors []*errors.Error
	errorHandler := func(e *errors.Error) {
		parserErrors = append(parserErrors, e)
	}

	// Parse

	rootNode, err := parser.Parse(src, cfg.Config{
		Version:          &version.Version{Major: 5, Minor: 6},
		ErrorHandlerFunc: errorHandler,
	})

	if err != nil {
		log.Fatal("Error:" + err.Error())
	}

	// Dump

	goDumper := dumper.NewDumper(os.Stdout).
		WithTokens().
		WithPositions()

	rootNode.Accept(goDumper)
}
```

Roadmap
-------

- Control Flow Graph (CFG)
- PHP8

Install
-------

```
go get github.com/z7zmey/php-parser/cmd/php-parser
```

CLI
---

```
php-parser [flags] <path> ...
```

| flag    | type   | description                       |
| ------- | ------ | --------------------------------- |
| -p      | bool   | print filepath                    |
| -e      | bool   | print errors                      |
| -d      | bool   | dump in golang format             |
| -r      | bool   | resolve names                     |
| -prof   | string | start profiler: [cpu, mem, trace] |
| -phpver | string | php version (default: 7.4)        |

Namespace resolver
------------------

Namespace resolver is a visitor that resolves nodes fully qualified name and saves into `map[node.Node]string` structure

- For `Class`, `Interface`, `Trait`, `Function`, `Constant` nodes it saves name with current namespace.
- For `Name`, `Relative`, `FullyQualified` nodes it resolves `use` aliases and saves a fully qualified name.


php-parser

~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for `golint`

revive

staticcheck is `go vet` on steroids, applying a ton of static analysis checks you might be used to from tools like ReSharper for C#

<div align="center">
	<h1><img alt="Staticcheck logo" src="/images/logo.svg" height="300" /><br />
		The advanced Go linter
	</h1>
</div>

Staticcheck is a state of the art linter for the [Go programming
language](https://go.dev/). Using static analysis, it finds bugs and performance issues,
offers simplifications, and enforces style rules.

**Financial support by [private and corporate sponsors](https://staticcheck.dev/sponsors) guarantees the tool's continued development.
Please [become a sponsor](https://github.com/users/dominikh/sponsorship) if you or your company rely on Staticcheck.**


## Documentation

You can find extensive documentation on Staticcheck on [its website](https://staticcheck.dev/docs/).

## Installation

### Releases

It is recommended that you run released versions of the tools.
These releases can be found as git tags (e.g. `2022.1`).

The easiest way of installing a release is by using `go install`, for example `go install honnef.co/go/tools/cmd/staticcheck@2022.1`.
Alternatively, we also offer [prebuilt binaries](https://github.com/dominikh/go-tools/releases).

You can find more information about installation and releases in the [documentation](https://staticcheck.dev/docs/getting-started/).

### Master

You can also run the master branch instead of a release. Note that
while the master branch is usually stable, it may still contain new
checks or backwards incompatible changes that break your build. By
using the master branch you agree to become a beta tester.

## Tools

All of the following tools can be found in the cmd/ directory. Each
tool is accompanied by its own README, describing it in more detail.

| Tool                                               | Description                                                             |
|----------------------------------------------------|-------------------------------------------------------------------------|
| [staticcheck](cmd/staticcheck/)                    | Go static analysis, detecting bugs, performance issues, and much more. |
| [structlayout](cmd/structlayout/)                  | Displays the layout (field sizes and padding) of structs.               |
| [structlayout-optimize](cmd/structlayout-optimize) | Reorders struct fields to minimize the amount of padding.               |
| [structlayout-pretty](cmd/structlayout-pretty)     | Formats the output of structlayout with ASCII art.                      |

## Libraries

In addition to the aforementioned tools, this repository contains the
libraries necessary to implement these tools.

Unless otherwise noted, none of these libraries have stable APIs.
Their main purpose is to aid the implementation of the tools.
You'll have to expect semiregular backwards-incompatible changes if you decide to use these libraries.

## System requirements

Staticcheck can be compiled and run with the latest release of Go. It can analyze code targeting any version of Go upto
the latest release.


staticcheck

A linter that checks usage of [github.com/stretchr/testify](https://github.com/stretchr/testify)

testifylint

CLI and go package for surfacing code comment TODOs (in any language) and applying a `git blame`to identify the author

[![GoDoc](https://godoc.org/github.com/augmentable-dev/tickgit?status.svg)](https://godoc.org/github.com/augmentable-dev/tickgit)
[![BuildStatus](https://github.com/augmentable-dev/tickgit/workflows/tests/badge.svg)](https://github.com/augmentable-dev/tickgit/actions?workflow=tests)
[![Go Report Card](https://goreportcard.com/badge/github.com/augmentable-dev/tickgit)](https://goreportcard.com/report/github.com/augmentable-dev/tickgit)
![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/augmentable-dev/tickgit)
[![Coverage](http://gocover.io/_badge/github.com/augmentable-dev/tickgit)](http://gocover.io/github.com/augmentable-dev/tickgit)
[![TODOs](https://badgen.net/https/api.tickgit.com/badgen/github.com/augmentable-dev/tickgit)](https://www.tickgit.com/browse?repo=github.com/augmentable-dev/tickgit)

## tickgit 🎟️

`tickgit` is a tool to help you manage latent work in a codebase. Use the `tickgit` command to view pending tasks, progress reports, completion summaries and historical data (using `git` history).

It's not meant to replace full-fledged project management tools such as JIRA or Trello. It will, hopefully, be a useful way to augment those tools with project management patterns that coexist with your code. As such, it's primary audience is software engineers.

### TODOs

`tickgit` will scan a codebase and identify any TODO items in the comments. It will output a report like so:

```
# tickgit ~/Desktop/facebook/react
...
TODO:
  => packages/scheduler/src/__tests__/SchedulerBrowser-test.js:85:9
  => added 1 month ago by Andrew Clark <git@andrewclark.io> in a2e05b6c148b25590884e8911d4d4acfcb76a487

TODO: Scheduler no longer requires these methods to be polyfilled. But
  => packages/scheduler/src/__tests__/SchedulerBrowser-test.js:77:7
  => added 1 month ago by Andrew Clark <git@andrewclark.io> in a2e05b6c148b25590884e8911d4d4acfcb76a487

TODO: Scheduler no longer requires these methods to be polyfilled. But
  => packages/scheduler/src/forks/SchedulerHostConfig.default.js:77:7
  => added 1 month ago by Andrew Clark <git@andrewclark.io> in a2e05b6c148b25590884e8911d4d4acfcb76a487

TODO: useTransition hook instead.
  => fixtures/concurrent/time-slicing/src/index.js:110:11
  => added 3 weeks ago by Sebastian Markbåge <sebastian@calyptus.eu> in 3ad076472ce9108b9b8a6a6fe039244b74a34392

128 TODOs Found 📝
```

Check out [an example](https://www.tickgit.com/browse?repo=github.com/kubernetes/kubernetes) of the TODOs tickgit will surface for the Kubernetes codebase.

#### Coming Soon

- [x] Blame - get a better sense of how old TODOs are, when they were introduced and by whom
- [ ] Context - more visibility into the lines of code _around_ a TODO for greater context
- [ ] More `TODO` type phrases to match, such as `FIXME`, `XXX`, `HACK`, or customized alternatives.
- [ ] More configurability (e.g. custom ignore paths)
- [ ] Markdown parsing
- [ ] More thorough historical stats

### Installation

#### Homebrew

```
brew tap augmentable-dev/tickgit
brew install tickgit
```

### Usage

The most up to date usage will be the output of `tickgit --help`.

### API

To find information about using the tickgit API, see [this file](https://github.com/augmentable-dev/tickgit/blob/master/docs/API.md).


tickgit

Find which of your Go lang direct GitHub dependencies is susceptible to ChainJacking attack

![readme cover image](https://user-images.githubusercontent.com/1287098/142020269-af916c4d-7c66-4893-a030-daa4113e00f4.png)

ChainJacking is a tool to find which of your Go lang direct GitHub dependencies is susceptible to RepoJacking attack. Read more about it [here](https://checkmarx.com/blog/a-new-type-of-supply-chain-attack-could-put-popular-admin-tools-at-risk/)

[![repojacking explained](https://img.youtube.com/vi/xrafnrkKfEg/0.jpg)](https://www.youtube.com/watch?v=xrafnrkKfEg)


#### Requirements
- Python 3.6+ and pip
- Go and it's binaries >= 1.13
- GitHub token (for API queries) 
  - 💡 This token is used for read only purposes and does not require any permissions 

#### Installation
```
pip install chainjacking
```

## Using in CI Workflows
ChainJacking can be easily integrated into modern CI workflows to test new code contributions.  


### GitHub Actions

https://user-images.githubusercontent.com/1287098/142009618-5eb5d87c-a001-4536-abf3-c5d06216e1b6.mp4

Example configuration:
```yaml
name: Pull Request

on:
  pull_request

jobs:

  build:
    name: Run Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - uses: actions/setup-python@v2
        with:
          python-version: '3.9'

      - name: ChainJacking tool test
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          python -m pip install -q chainjacking
          python -m chainjacking -gt $GITHUB_TOKEN
```


## CLI
ChainJacking module can be run as a CLI tool simply as 
```
python -m chainjacking
```

### CLI Arguments
- `-gt <token>` - GitHub access token, to run queries on GitHub API (required)
- `-p <path>` - Path to scan. (default=current directory)
- `-v` - Verbose output mode
- `-url <url>` - Scan one or more GitHub URLs
- `-f <path>` - Scan one or more GitHub URLs from a file separated by new-line


#### Example: Scan a Go project
navigate your shell into a Go project's directory, and run:
```
python -m chainjacking -gt $GH_TOKEN
```

https://user-images.githubusercontent.com/1287098/142020377-c873716d-c080-418b-8597-f9e08dba3e82.mp4




ChainJacking

checkstyle is a style check tool like java checkstyle. This tool inspired by java checkstyle, golint. The style referred to some points in Go Code Review Comments

go-checkstyle
=============
[![Build Status](https://api.travis-ci.org/qiniu/checkstyle.png?branch=master)](https://travis-ci.org/qiniu/checkstyle)

checkstyle is a style check tool like java checkstyle. This tool inspired by [java checkstyle](https://github.com/checkstyle/checkstyle), [golint](https://github.com/golang/lint). The style refered to some points in [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments).

# Install
  go get github.com/qiniu/checkstyle/gocheckstyle

# Run
  gocheckstyle -config=.go_style dir1 dir2

# Config 
config is json file like the following:
```
{
    "file_line": 500,
    "func_line": 50,
    "params_num":4,
    "results_num":3,
    "formated": true,
    "pkg_name": true,
    "camel_name":true,
    "ignore":[
        "a/*",
        "b/*/c/*.go"
    ],
    "fatal":[
        "formated"
    ]
}

```

# Add to makefile
```
check_go_style:
	bash -c "mkdir -p checkstyle; cd checkstyle && export GOPATH=`pwd` && go get github.com/qiniu/checkstyle/gocheckstyle"
	checkstyle/bin/gocheckstyle -config=.go_style dir1 dir2

```

# Integrate with jenkins checkstyle plugin
excute in shell
```
    mkdir -p checkstyle; cd checkstyle && export GOPATH=`pwd` && go get github.com/qiniu/checkstyle/gocheckstyle"
    checkstyle/bin/gocheckstyle -reporter=xml -config=.go_style dir1 dir2 2>gostyle.xml
```
then add postbuild checkstyle file gostyle.xml

Run checkstyle with one or more filenames or directories. The output of this tool is a list of suggestions. If you need to force obey the rule, place it in fatal.

# Checkstyle's difference with other tools
Checkstyle differs from gofmt. Gofmt reformats Go source code, whereas checkstyle prints out coding style suggestion.

Checkstyle differs from golint. Checkstyle check file line/function line/param number, could be configed by user.


go-checkstyle

GoAst Viewer
================================================================

Golang AST visualizer.

## Demo

[GoAst Viewer Demo](https://yuroyoro.github.io/goast-viewer/index.html)

![](https://raw.githubusercontent.com/yuroyoro/goast-viewer/master/goast-viewer.png)


## Usage

You just need to run a http server and open your browser to `index.html`


## Installation

To install, use `go get` and `make install`.

```bash
$ go get -d github.com/yuroyoro/goast-viewer
$ cd $GOPATH/src/github.com/yuroyoro/goast-viewer
$ make build
```

## Authors

- [yuroyoro](https://github.com/yuroyoro)
- [paulvollmer](https://github.com/paulvollmer)


goast-viewer

# golang-ifood-sdk
A golang Ifood sdk 

![Actions on main](https://github.com/arxdsilva/golang-ifood-sdk/actions/workflows/test.yml/badge.svg?branch=main)
[![Coverage Status](https://coveralls.io/repos/github/arxdsilva/golang-ifood-sdk/badge.svg?branch=main)](https://coveralls.io/github/arxdsilva/golang-ifood-sdk?branch=main)
[![Go Report Card](https://goreportcard.com/badge/github.com/arxdsilva/golang-ifood-sdk)](https://goreportcard.com/report/github.com/arxdsilva/golang-ifood-sdk)
[![LICENSE](https://img.shields.io/badge/license-MIT-orange.svg)](LICENSE)
[![GoDoc](https://godoc.org/github.com/arxdsilva/golang-ifood-sdk?status.svg)](https://godoc.org/github.com/arxdsilva/golang-ifood-sdk)

## Usage V2

```go

package main

import (
    sdk "github.com/arxdsilva/golang-ifood-sdk/container"
)

func main() {
    var clientID, clientSecret, user, password string
    clientID = os.GetEnv("CLIENT_ID")
    clientSecret = os.GetEnv("CLIENT_SECRET")
    // START new SDK instance
    container := sdk.Create(clientID, clientSecret, 0, true)
    // Get user code to connect this supplier to the restaurant
    uc, err := container.AuthService.V2GetUserCode()
    if err != nil { 
        log.Fatal(err)
    }
    fmt.Println("user_code_url_complete:", uc.VerificationURLComplete)
    v2Creds, err := container.AuthService.V2Authenticate("client_credentials", uc.Usercode, uc.AuthorizationCodeVerifier)
    if err != nil { 
        log.Fatal(err)
    }
    events, err := container.EventsService.V2Poll()
    if err != nil {
        log.Fatal(err)
    }
    err = container.EventsService.V2Acknowledge(events)
    if err != nil {
        log.Fatal(err)
    }
    var newOrdersDetails []orders.OrderDetails
	for _, event := range events {
        // avoid non new orders
        if event.Code != "PLACED" {
            continue
        }
        details, err := container.OrdersService.V2GetDetails(event.ID)
        if err != nil {
            fmt.Println("err: ", err)
            continue
        }
        newOrdersDetails = append(newOrdersDetails, details)
	}
	for _, order := range newOrdersDetails {
        // change order status
        err = container.OrdersService.V2SetConfirmStatus(order.ID)
        if err != nil {
            fmt.Println("err: ", err)
            continue
        }
        // change other statuses
    }
    fmt.Printf("new orders: %+v\n", newOrdersDetails)
}
```


## Usage V1

```go

package main

import (
    sdk "github.com/arxdsilva/golang-ifood-sdk/container"
)

func main() {
    var clientID, clientSecret, user, password string
    clientID = os.GetEnv("CLIENT_ID")
    clientSecret = os.GetEnv("CLIENT_SECRET")
    // START new SDK instance
    container := sdk.New(0, time.Minute, false)
    container.GetHttpAdapter()
    // Alocate services
    container.GetAuthenticationService(clientID, clientSecret)
    container.GetMerchantService()
    container.GetCatalogService()
    container.GetEventsService()
    container.GetOrdersService()
    user = os.GetEnv("USER")
    password = os.GetEnv("PASSWORD")
    creds, err := container.AuthService.Authenticate(user,password)
    if err != nil { 
        log.Fatal(err)
    }
    merchants, err := container.MerchantService.ListAll()
    if err != nil { 
        log.Fatal(err)
    }
    events, err := container.EventsService.Poll()
    if err != nil {
        log.Fatal(err)
    }
    var newOrdersDetails []orders.OrderDetails
    for _, event := range events {
        err = container.EventsService.Acknowledge(event)
        if err != nil {
            fmt.Println("err: ", err)
            continue
        }
        // avoid non new orders
        if event.Code != "PLACED" {
            continue
        }
        details, err := container.OrdersService.GetDetails(event.ID)
        if err != nil {
            fmt.Println("err: ", err)
            continue
        }
        newOrdersDetails = append(newOrdersDetails, details)
	}
	for _, order := range newOrdersDetails {
        // change order status
        err = container.OrdersService.SetIntegrateStatus(order.ID)
        if err != nil {
            fmt.Println("err: ", err)
            continue
        }
        // change other statuses
    }
    fmt.Printf("new orders: %+v\n", newOrdersDetails)
}
```


golang-ifood-sdk

A light-weight superfast line of code counter written in pure Go

# STTO

Command-line utility written in Go to check total line of code in a file present in a directory.

## Authors

- [Mainak Bhattacharjee](https://github.com/mainak55512)

## Dependencies

- go 1.22.5
- github.com/mattn/go-runewidth v0.0.9
- github.com/olekukonko/tablewriter v0.0.5

## Benchmark

#### Benchmark was run on the clone of '[Redis](https://github.com/redis/redis)' repository

![Demo](./resources/benchmark.gif)

**N.B: stto is no way near the more established options like 'scc' or 'tokei' in terms of features. It is in early development stage and isn't production ready.

All the tools read over 1.5k files
![stto](./resources/stto_redis.png)
![scc](./resources/scc_redis.png)
![tokei](./resources/tokei_redis.png)

## Installation

Install using the following command for latest features
```bash
go install github.com/mainak55512/stto@latest
```
Alternatively you can use the optimized builds from the [release section](https://github.com/mainak55512/stto/releases)

N.B. Release builds are generally more optimized but lack latest features, 'go install' command is the prefered way to download the executable.

## Usage

Full usage details available in 
```bash
stto --help
```

### Usage 1:
![stto_usage_1](./resources/stto_usage_1.png)

### Usage 2:
![stto_usage_2](./resources/stto_usage_2.png)

### Usage 3:
![stto_usage_3](./resources/stto_usage_3.png)

N.B. 'jproc' is a json query tool writtrn in javascript. For more details check out the [repo](https://github.com/mainak55512/JSONProcessor).

## 🚀 About Me
I'm a Tech enthusiast and a hobby programmer.
You can visit my [Github profile](https://github.com/mainak55512) to see my other works :)



stto

Remove unnecessary type conversions from Go source

# About

The unconvert program analyzes Go packages to identify unnecessary
type conversions; i.e., expressions T(x) where x already has type T.

# Install

    go install github.com/mdempsky/unconvert@latest

# Usage

    $ unconvert -v bytes fmt
    GOROOT/src/bytes/reader.go:117:14: unnecessary conversion
                    abs = int64(r.i) + offset
                               ^
    GOROOT/src/fmt/print.go:411:21: unnecessary conversion
            p.fmt.integer(int64(v), 16, unsigned, udigits)
                               ^

# Flags

Using the -v flag, unconvert will also print the source line and a
caret to indicate the unnecessary conversion's position therein.

Using the -apply flag, unconvert will rewrite the Go source files
without the unnecessary type conversions.

Using the -all flag, unconvert will analyze the Go packages under all
possible GOOS/GOARCH combinations, and only identify conversions that
are unnecessary in all cases.

E.g., syscall.Timespec's Sec and Nsec fields are int64 under
linux/amd64 but int32 under linux/386.  An int64(ts.Sec) conversion
that appears in a linux/amd64-only file will be identified as
unnecessary, but it will be preserved if it occurs in a file that's
compiled for both linux/amd64 and linux/386.


unconvert

Automatically validates struct fields with tags

Validate
========

A Go package to automatically validate fields with tags

[![GoDoc](https://godoc.org/github.com/mccoyst/validate?status.svg)](https://godoc.org/github.com/mccoyst/validate)

[![Build Status](https://api.travis-ci.org/mccoyst/validate.svg?branch=master)](http://travis-ci.org/mccoyst/validate)

[![Test Coverage](https://img.shields.io/badge/coverage-100.0%25-brightgreen.svg)](https://gocover.io/github.com/mccoyst/validate)

Is it good?
-----------
Yes.


The Best Go Libraries For Code Analysis (33)