Lawrence  Lesch

Lawrence Lesch

1668126120

Gts: TypeScript Style Guide, formatter, and Linter

gts

Google TypeScript Style

gts is Google's TypeScript style guide, and the configuration for our formatter, linter, and automatic code fixer. No lint rules to edit, no configuration to update, no more bike shedding over syntax.

To borrow from standardjs:

  • No configuration. The easiest way to enforce consistent style in your project. Just drop it in.
  • Automatically format code. Just run gts fix and say goodbye to messy or inconsistent code.
  • Catch style issues & programmer errors early. Save precious code review time by eliminating back-and-forth between reviewer & contributor.
  • Opinionated, but not to a fault. We recommend you use the default configuration, but if you need to customize compiler or linter config, you can.

Under the covers, we use eslint to enforce the style guide and provide automated fixes, and prettier to re-format code.

Getting Started

The easiest way to get started is to run:

npx gts init

How it works

When you run the npx gts init command, it's going to do a few things for you:

  • Adds an opinionated tsconfig.json file to your project that uses the Google TypeScript Style.
  • Adds the necessary devDependencies to your package.json.
  • Adds scripts to your package.json:
    • lint: Lints and checks for formatting problems.
    • fix: Automatically fixes formatting and linting problems (if possible).
    • clean: Removes output files.
    • compile: Compiles the source code using TypeScript compiler.
    • pretest, posttest and prepare: convenience integrations.
  • If a source folder is not already present it will add a default template project.

Individual files

The commands above will all run in the scope of the current folder. Some commands can be run on individual files:

gts lint index.ts
gts lint one.ts two.ts three.ts
gts lint *.ts

Working with eslint

Under the covers, we use eslint to enforce the style guide and provide automated fixes, and prettier to re-format code. To use the shared eslint configuration, create an .eslintrc in your project directory, and extend the shared config:

---
extends:
  - './node_modules/gts'

If you don't want to use the gts CLI, you can drop down to using the module as a basic eslint config, and just use the eslint cli:

$ eslint --fix

This opens the ability to use the vast eslint ecosystem including custom rules, and tools like the VSCode plugin for eslint:

Badge

Show your love for gts and include a badge!

[![Code Style: Google](https://img.shields.io/badge/code%20style-google-blueviolet.svg)](https://github.com/google/gts)

Supported Node.js Versions

Our client libraries follow the Node.js release schedule. Libraries are compatible with all current active and maintenance versions of Node.js.


Made with ❤️ by the Google Node.js team.

NOTE: This is not an official Google product.

Download Details:

Author: Google
Source Code: https://github.com/google/gts 
License: Apache-2.0 license

#typescript #google #linter 

Gts: TypeScript Style Guide, formatter, and Linter
Rupert  Beatty

Rupert Beatty

1667598300

Tailor: Cross-platform Static analyzer and Linter for Swift

Tailor

Tailor is a cross-platform static analysis and lint tool for source code written in Apple's Swift programming language. It analyzes your code to ensure consistent styling and help avoid bugs.

Tailor. Cross-platform static analyzer and linter for Swift.

Tailor supports Swift 3.0.1 out of the box and helps enforce style guidelines outlined in the The Swift Programming Language, GitHub, Ray Wenderlich, and Coursera style guides. It supports cross-platform usage and can be run on Mac OS X via your shell or integrated with Xcode, as well as on Linux and Windows.

Tailor parses Swift source code using the primary Java target of ANTLR:

ANTLR is a powerful parser generator [ . . . ] widely used in academia and industry to build all sorts of languages, tools, and frameworks.

About the ANTLR Parser Generator

Getting Started

Installation

Requires Java (JRE or JDK) Version 8 or above: Java SE Downloads

Homebrew, Linuxbrew

brew install tailor

Mac OS X (10.10+), Linux

curl -fsSL https://tailor.sh/install.sh | sh

Windows (10+)

iex (new-object net.webclient).downloadstring('https://tailor.sh/install.ps1')

Manually

You may also download Tailor via GitHub Releases, extract the archive, and symlink the tailor/bin/tailor shell script to a location in your $PATH.

Continuous Integration

If your continuous integration server supports Homebrew installation, you may use the following snippet:

before_install:
  - brew update
  - brew install tailor

In other cases, use this snippet:

Replace ${TAILOR_RELEASE_ARCHIVE} with the URL of the release you would like to install, e.g. https://github.com/sleekbyte/tailor/releases/download/v0.1.0/tailor.tar.

before_script:
  - wget ${TAILOR_RELEASE_ARCHIVE} -O /tmp/tailor.tar
  - tar -xvf /tmp/tailor.tar
  - export PATH=$PATH:$PWD/tailor/bin/

Usage

Run Tailor with a list of files and directories to analyze, or via Xcode.

$ tailor [options] [--] [[file|directory] ...]

Help for Tailor is accessible via the [-h|--help] option.

$ tailor -h
Usage: tailor [options] [--] [[file|directory] ...]

Perform static analysis on Swift source files.

Invoking Tailor with at least one file or directory will analyze all Swift files at those paths. If
no paths are provided, Tailor will analyze all Swift files found in '$SRCROOT' (if defined), which
is set by Xcode when run in a Build Phase. Tailor may be set up as an Xcode Build Phase
automatically with the --xcode option.

Options:
 -c,--config=<path/to/.tailor.yml>             specify configuration file
    --debug                                    print ANTLR error messages when parsing error occurs
    --except=<rule1,rule2,...>                 run all rules except the specified ones
 -f,--format=<xcode|json|cc|html>              select an output format
 -h,--help                                     display help
    --invert-color                             invert colorized console output
 -l,--max-line-length=<0-999>                  maximum Line length (in characters)
    --list-files                               display Swift source files to be analyzed
    --max-class-length=<0-999>                 maximum Class length (in lines)
    --max-closure-length=<0-999>               maximum Closure length (in lines)
    --max-file-length=<0-999>                  maximum File length (in lines)
    --max-function-length=<0-999>              maximum Function length (in lines)
    --max-name-length=<0-999>                  maximum Identifier name length (in characters)
    --max-severity=<error|warning (default)>   maximum severity
    --max-struct-length=<0-999>                maximum Struct length (in lines)
    --min-name-length=<1-999>                  minimum Identifier name length (in characters)
    --no-color                                 disable colorized console output
    --only=<rule1,rule2,...>                   run only the specified rules
    --purge=<1-999>                            reduce memory usage by clearing DFA cache after
                                               specified number of files are parsed
    --show-rules                               show description for each rule
 -v,--version                                  display version
    --xcode=<path/to/project.xcodeproj>        add Tailor Build Phase Run Script to Xcode Project

Features

Enabling and Disabling Rules

Rule identifiers and "preferred/not preferred" code samples may be found on the Rules page.

Rules may be individually disabled (blacklist) or enabled (whitelist) via the --except and --only command-line flags.

Except

tailor --except=brace-style,trailing-whitespace main.swift

Only

tailor --only=redundant-parentheses,terminating-semicolon main.swift

Cross-Platform

Tailor may be used on Mac OS X via your shell or integrated with Xcode, as well as on Linux and Windows.

Linux

Tailor on Ubuntu

Windows

Tailor on Windows

Automatic Xcode Integration

Tailor can be integrated with Xcode projects using the --xcode option.

tailor --xcode /path/to/demo.xcodeproj/

This adds the following Build Phase Run Script to your project's default target. Run Script

Tailor's output will be displayed inline within the Xcode Editor Area and as a list in the Log Navigator. Xcode messages

Configure Xcode to Analyze Code Natively (⇧⌘B)

Add a new configuration, say Analyze, to the project

screen shot 2016-11-30 at 12 29 34 am

Modify the active scheme's Analyze phase to use the new build configuration created above

screen shot 2016-11-30 at 12 37 08 am

Tweak the build phase run script to run Tailor only when analyzing the project (⇧⌘B)

if [ "${CONFIGURATION}" = "Analyze" ]; then
    if hash tailor 2>/dev/null; then
        tailor
    else
        echo "warning: Please install Tailor from https://tailor.sh"
    fi
fi

Colorized Output

Tailor uses the following color schemes to format CLI output:

Dark theme (enabled by default) Dark theme

Light theme (enabled via --invert-color option) Light theme

No color theme (enabled via --no-color option) No color

Warnings, Errors, and Failing the Build

--max-severity can be used to control the maximum severity of violation messages. It can be set to error or warning (by default, it is set to warning). Setting it to error allows you to distinguish between lower and higher priority messages. It also fails the build in Xcode, if any errors are reported (similar to how a compiler error fails the build in Xcode). With max-severity set to warning, all violation messages are warnings and the Xcode build will never fail.

This setting also affects Tailor's exit code on the command-line, a failing build will exit 1 whereas having warnings only will exit 0, allowing Tailor to be easily integrated into pre-commit hooks.

Disable Violations within Source Code

Violations on a specific line may be disabled with a trailing single-line comment.

import Foundation; // tailor:disable

Additionally, violations in a given block of code can be disabled by enclosing the block within tailor:off and tailor:on comments.

// tailor:off
import Foundation;
import UIKit;
import CoreData;
// tailor:on

class Demo() {
  // Define public members here
}

Note

  • // tailor:off and // tailor:on comments must be paired

Configuration

The behavior of Tailor can be customized via the .tailor.yml configuration file. It enables you to

  • include/exclude certain files and directories from analysis
  • enable and disable specific analysis rules
  • specify output format
  • specify CLI output color scheme

You can tell Tailor which configuration file to use by specifying its file path via the --config CLI option. By default, Tailor will look for the configuration file in the directory where you will run Tailor from.

The file follows the YAML 1.1 format.

Including/Excluding files

Tailor checks all files found by a recursive search starting from the directories given as command line arguments. However, it only analyzes Swift files that end in .swift. If you would like Tailor to analyze specific files and directories, you will have to add entries for them under include. Files and directories can also be ignored through exclude.

Here is an example that might be used for an iOS project:

include:
    - Source            # Inspect all Swift files under "Source/"
exclude:
    - '**Tests.swift'   # Ignore Swift files that end in "Tests"
    - Source/Carthage   # Ignore Swift files under "Source/Carthage/"
    - Source/Pods       # Ignore Swift files under "Source/Pods/"

Notes

  • Files and directories are specified relative to where tailor is run from
  • Paths to directories or Swift files provided explicitly via CLI will cause the include/exclude rules specified in .tailor.yml to be ignored
  • Exclude is given higher precedence than Include
  • Tailor recognizes the Java Glob syntax

Enabling/Disabling rules

Tailor allows you to individually disable (blacklist) or enable (whitelist) rules via the except and only labels.

Here is an example showcasing how to enable certain rules:

# Tailor will solely check for violations to the following rules
only:
    - upper-camel-case
    - trailing-closure
    - forced-type-cast
    - redundant-parentheses

Here is an example showcasing how to disable certain rules:

# Tailor will check for violations to all rules except for the following ones
except:
    - parenthesis-whitespace
    - lower-camel-case

Notes

  • only is given precedence over except
  • Rules that are explicitly included/excluded via CLI will cause the only/except rules specified in .tailor.yml to be ignored

Specifying output format

Tailor allows you to specify the output format (xcode/json) via the format label.

Here is an example showcasing how to specify the output format:

# The output format will now be in JSON
format: json

Note

  • The output format explicitly specified via CLI will cause the output format defined in .tailor.yml to be ignored

Specifying CLI output color scheme

Tailor allows you to specify the CLI output color schemes via the color label. To disable colored output, set color to disable. To invert the color scheme, set color to invert.

Here is an example showcasing how to specify the CLI output color scheme:

# The CLI output will not be colored
color: disable

Note

  • The CLI output color scheme explicitly specified via CLI will cause the output color scheme defined in .tailor.yml to be ignored

Formatters

Tailor's output format may be customized via the -f/--format option. The Xcode formatter is selected by default.

Xcode Formatter (default)

The default xcode formatter outputs violation messages according to the format expected by Xcode to be displayed inline within the Xcode Editor Area and as a list in the Log Navigator. This format is also as human-friendly as possible on the console.

$ tailor main.swift

********** /main.swift **********
/main.swift:1:    warning: [multiple-imports] Imports should be on separate lines
/main.swift:1:18: warning: [terminating-semicolon] Statements should not terminate with a semicolon
/main.swift:3:05: warning: [constant-naming] Global Constant should be either lowerCamelCase or UpperCamelCase
/main.swift:5:07: warning: [redundant-parentheses] Conditional clause should not be enclosed within parentheses
/main.swift:7:    warning: [terminating-newline] File should terminate with exactly one newline character ('\n')

Analyzed 1 file, skipped 0 files, and detected 5 violations (0 errors, 5 warnings).

JSON Formatter

The json formatter outputs an array of violation messages for each file, and a summary object indicating the parsing results and the violation counts.

$ tailor -f json main.swift
{
  "files": [
    {
      "path": "/main.swift",
      "violations": [
        {
          "severity": "warning",
          "rule": "constant-naming",
          "location": {
            "line": 1,
            "column": 5
          },
          "message": "Global Constant should be either lowerCamelCase or UpperCamelCase"
        }
      ],
      "parsed": true
    }
  ],
  "summary": {
    "violations": 1,
    "warnings": 1,
    "analyzed": 1,
    "errors": 0,
    "skipped": 0
  }
}

HTML Formatter

The html formatter outputs a complete HTML document that should be written to a file.

tailor -f html main.swift > tailor.html

HTML format

Developers

Please review the guidelines for contributing to this repository.

Development Environment

External Tools and Libraries

Development & Runtime

ToolLicense
ANTLR 4.5The BSD License
Apache Commons CLIApache License, Version 2.0
JansiApache License, Version 2.0
XcodeprojMIT
SnakeYAMLApache License, Version 2.0
GsonApache License, Version 2.0
Mustache.javaApache License, Version 2.0

Development Only

ToolLicense
GradleApache License, Version 2.0
Travis CIFree for Open Source Projects
MockitoMIT
JUnitEclipse Public License 1.0
Java HamcrestThe BSD 3-Clause License
FindBugsGNU Lesser General Public License
CheckstyleGNU Lesser General Public License
PMDBSD-style
JaCoCoEclipse Public License v1.0
CoverallsFree for Open Source
BundlerMIT
CodacyFree for Open Source
System RulesCommon Public License 1.0
RonnMIT

Download Details:

Author: Sleekbyte
Source Code: https://github.com/sleekbyte/tailor 
License: MIT license

#swift #apple #linter #static #analyzer 

Tailor: Cross-platform Static analyzer and Linter for Swift
Elian  Harber

Elian Harber

1667480069

Golangci-lint: Fast Linters Runner for Go

golangci-lint

Fast linters runner for Go

 


golangci-lint is 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.

Install golangci-lint

Features

  • Very fast: runs linters in parallel, reuses Go build cache and caches analysis results.
  • ⚙️ Yaml-based configuration.
  • 🖥 integrations with VS Code, Sublime Text, GoLand, GNU Emacs, Vim, Atom, GitHub Actions.
  • 🥇 A lot of linters included, no need to install them.
  • 📈 Minimum number of false positives because of tuned default settings.
  • 🔥nice output with colors, source code lines and marked identifiers.

Demo

golangci-lint demo

Short 1.5 min video demo of analyzing beego. asciicast

Documentation

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

Stargazers over time

Stargazers over time

Download Details:

Author: Golangci
Source Code: https://github.com/golangci/golangci-lint 
License: GPL-3.0 license

#go #golang #ci #linter 

Golangci-lint: Fast Linters Runner for Go
Lawrence  Lesch

Lawrence Lesch

1662420720

Linter-eslint: ESLint Plugin for Atom Linter

linter-eslint 

This linter plugin for Linter provides an interface to eslint versions 7 and below. It will be used with files that have the "JavaScript" syntax.

For linting in projects that use ESLint v8 and above, install linter-eslint-node.

Installation

apm install linter-eslint

linter-eslint will look for a version of eslint local to your project and use it if it's available. If none is found it will fall back to the version it ships with.

Let's say you depend on a specific version of eslint. Maybe it has unreleased features or maybe it's newer than what linter-eslint ships with. If your-project/node_modules/eslint exists linter-eslint will be used. This package requires an eslint of at least v1.0.0.

If you do not have the linter package installed, it will be installed for you. If you are using an alternative linter-* consumer, the linter package can be disabled.

If you wish to lint files in JavaScript-derivative languages (like Typescript, Flow) with ESLint, you must add the scope name for that grammar to the List of scopes to run ESLint on option in linter-eslint Settings. For example, to lint TypeScript files, add source.ts to the list.

Use with plugins

You have two options:

Install locally to your project eslint and the plugin

  • $ npm i --save-dev eslint [eslint-plugins]

Install globally eslint and plugins

  • $ npm i -g eslint [eslint-plugins]
  • Activate Use Global Eslint package option
  • (Optional) Set Global Node Path with $ npm config get prefix

Using ESLint

Note that recent versions of ESLint do not use any rules by default. This means you have to specify a configuration file for your project!

To do this in a straightforward way run this:

eslint --init

Alternatively you can create the .eslintrc file by yourself. It is a good idea to have a look at the ESLint documentation, including the list of rules.

A Note About Settings

If Use Global is on, Atom will use the global ESLint. The path to it is figured out by running npm get prefix. If this fails for any reason, you can set the global path manually in Global Node Installation Path.

If Use Global is off, Atom will try to find a local installation in the project folder, look if there's ESLint in ${PROJECT_ROOT}/node_modules and use it if found.

The path to the local node_modules folder can be a path relative to the project or an absolute path and should end in /node_modules/. This path is used if the other methods of discovery have failed.

If there is no local installation Atom will use the built-in ESLint in the linter-eslint package itself.

Contributing

See the contributing guidelines to get started.

Download Details:

Author: AtomLinter
Source Code: https://github.com/AtomLinter/linter-eslint 

#javascript #eslint #linter 

Linter-eslint: ESLint Plugin for Atom Linter

Go-critic: The Most Opinionated Go Source Code Linter for Code Audit

go-critic

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

Logo

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

Features

  • Almost 100 diagnostics that check for bugs, performance and style issues
  • Extensible without re-compilation with dynamic rules
  • Includes #opinionated checks with very strict and specific requirements
  • Self-documented: gocritic doc <checkname> gives a checker description

Installation

For most users, using go-critic under golangci-lint is enough.

Precompiled go-critic binaries can be found at releases page.

Instructions below show how to build go-critic from sources.

GO111MODULE=on go get -v -u github.com/go-critic/go-critic/cmd/gocritic

If the command above does not work, you can try cloning this repository under your GOPATH and run make gocritic.

On macOS, you can also install go-critic using MacPorts: sudo port install go-critic

Usage

Be sure gocritic executable is under your $PATH.

Usage of gocritic: gocritic [sub-command] [sub-command args...] Run gocritic without arguments to get help output.

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

check sub-command examples:

# Runs all stable checkers on `fmt` package:
gocritic check fmt

# Run all stable checkers on `pkg1` and `pkg2`
gocritic check pkg1 pkg2

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

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

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

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

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

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

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

To get a list of available checker parameters, run gocritic 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.

Documentation

The latest documentation is available at go-critic.com.

Contributing

This project aims to be contribution-friendly.

Our chats: English or Russian (Telegram website)

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.

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

Author: Go-critic
Source Code: https://github.com/go-critic/go-critic 
License: MIT license

#go #golang #linter 

Go-critic: The Most Opinionated Go Source Code Linter for Code Audit

Errcheck Checks That You Checked Errors

errcheck

errcheck is a program for checking for unchecked errors in go programs.

Install

go install github.com/kisielk/errcheck@latest

errcheck requires Go 1.12 or newer, and depends on the package go/packages from the golang.org/x/tools repository.

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.

go/analysis

The package provides Analyzer instance that can be used with go/analysis API.

Currently supported flags are blank, assert, exclude, and excludeonly. Just as the API itself, the analyzer is exprimental 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/ioutil.ReadFile
io.Copy(*bytes.Buffer)
io.Copy(os.Stdout)

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

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 integrates errcheck with Emacs by providing a go-errcheck command and customizable variables to automatically pass flags to errcheck.

Vim

vim-go can run errcheck via both its :GoErrCheck and :GoMetaLinter commands.

Author: Kisielk
Source Code: https://github.com/kisielk/errcheck 
License: MIT license

#go #golang #linter #error 

Errcheck Checks That You Checked Errors
Annie  Emard

Annie Emard

1653063780

Ember Template Lint: Linter For Ember Or Handlebars Templates

ember-template-lint

ember-template-lint is a library that will lint your handlebars template and return error results.

For example, if the rule no-bare-strings is enabled, this template would be in violation:

{{! app/components/my-thing/template.hbs  }}
<div>A bare string</div>

When the ember-template-lint executable is run, we would have a single result indicating that the no-bare-strings rule found an error.

Requirements

  • Node.js ^12.22.0 || ^14.17.0 || >=16.0.0

Installation

npm install --save-dev ember-template-lint
yarn add --dev ember-template-lint

Note: this library is installed by default with new Ember apps.

Usage

While ember-template-lint does have a Node API, the main way to use it is through its executable, which is intended to be installed locally within a project.

Basic usage is as straightforward as

ember-template-lint .

Workflow Examples

See documentation on workflow examples.

See documentation on the todo functionality.

Configuration

Project Wide

You can turn on specific rules by toggling them in a .template-lintrc.js file at the base of your project, or at a custom relative path which may be identified using the CLI:

module.exports = {
  extends: 'recommended',

  rules: {
    'no-bare-strings': true,
  },
};

For more detailed information see configuration.

Presets

 NameDescription
recommendedEnables the recommended rules.
💅stylisticEnables stylistic rules for those who aren't ready to adopt ember-template-lint-plugin-prettier (including stylistic rules that were previously in the recommended preset in ember-template-lint v1).
⌨️a11yEnables A11Y rules. Its goal is to include all A11Y related rules, therefore it does not follow the same SemVer policy as the other presets. Please see versioning for more details.

Rules

Each rule has emojis denoting:

  • what configuration it belongs to
  • 🔧 if some problems reported by the rule are automatically fixable by the --fix command line option
Name💅⌨️🔧
attribute-indentation    
block-indentation 💅 🔧
builtin-component-arguments   
deprecated-inline-view-helper   
deprecated-render-helper   
eol-last 💅 🔧
inline-link-to   🔧
linebreak-style 💅  
link-href-attributes ⌨️ 
link-rel-noopener  🔧
modifier-name-case 💅  
no-abstract-roles ⌨️ 
no-accesskey-attribute ⌨️🔧
no-action   
no-action-modifiers    
no-args-paths   
no-arguments-for-html-elements   
no-aria-hidden-body ⌨️🔧
no-array-prototype-extensions   🔧
no-attrs-in-components   
no-autofocus-attribute ⌨️ 
no-bare-strings    
no-block-params-for-html-elements   
no-capital-arguments   
no-class-bindings   
no-curly-component-invocation  🔧
no-debugger   
no-down-event-binding ⌨️ 
no-duplicate-attributes ⌨️ 
no-duplicate-id ⌨️ 
no-duplicate-landmark-elements ⌨️ 
no-dynamic-subexpression-invocations    
no-element-event-actions    
no-empty-headings ⌨️ 
no-extra-mut-helper-argument   
no-forbidden-elements   
no-heading-inside-button ⌨️ 
no-html-comments   
no-implicit-this   
no-index-component-invocation   
no-inline-styles   
no-input-block   
no-input-tagname   
no-invalid-aria-attributes  ⌨️ 
no-invalid-interactive ⌨️ 
no-invalid-link-text ⌨️ 
no-invalid-link-title ⌨️ 
no-invalid-meta ⌨️ 
no-invalid-role ⌨️ 
no-link-to-positional-params   
no-link-to-tagname   
no-log   
no-model-argument-in-route-templates   🔧
no-multiple-empty-lines 💅  
no-mut-helper    
no-negated-condition  🔧
no-nested-interactive ⌨️ 
no-nested-landmark ⌨️ 
no-nested-splattributes   
no-obscure-array-access   🔧
no-obsolete-elements ⌨️ 
no-outlet-outside-routes   
no-partial   
no-passed-in-event-handlers   
no-positional-data-test-selectors  🔧
no-positive-tabindex ⌨️ 
no-potential-path-strings   
no-quoteless-attributes   
no-redundant-fn  🔧
no-redundant-landmark-role ⌨️🔧
no-restricted-invocations    
no-route-action   
no-scope-outside-table-headings  ⌨️ 
no-shadowed-elements   
no-this-in-template-only-components   🔧
no-trailing-spaces 💅  
no-triple-curlies   
no-unbalanced-curlies   
no-unbound   
no-unknown-arguments-for-builtin-components  🔧
no-unnecessary-component-helper   
no-unnecessary-concat 💅  
no-unused-block-params   
no-valueless-arguments   
no-whitespace-for-layout ⌨️ 
no-whitespace-within-word ⌨️ 
no-with   
no-yield-only   
no-yield-to-default   
quotes 💅 🔧
require-aria-activedescendant-tabindex  ⌨️ 
require-button-type  🔧
require-context-role ⌨️ 
require-each-key    
require-form-method    
require-has-block-helper  🔧
require-iframe-title ⌨️ 
require-input-label ⌨️ 
require-lang-attribute ⌨️ 
require-presentational-children ⌨️ 
require-splattributes    
require-valid-alt-text ⌨️ 
require-valid-named-block-naming-format   
self-closing-void-elements 💅  
simple-unless   
splat-attributes-only   
style-concatenation   
table-groups ⌨️ 
template-length    

Supporting the --fix option

You can add a fixer to a rule. See fixer documentation for more details.

Sharing configs

It is possible to share a config (extends) or plugin (custom rules) across projects. See ember-template-lint-plugin-peopleconnect for an example.

Defining your own rules

You can define and use your own custom rules using the plugin system. See plugin documentation for more details.

Semantic Versioning Policy

The semver policy for this addon can be read here: semver policy.

Contributing

See the Contributing Guidelines for information on how to help out.

Author: ember-template-lint
Source Code: https://github.com/ember-template-lint/ember-template-lint
License: MIT license

#linter #ember #javascript 

Ember Template Lint: Linter For Ember Or Handlebars Templates
Annie  Emard

Annie Emard

1652622360

KubeLinter: Static Analysis Tool That Checks Kubernetes YAML Files

Static analysis for Kubernetes

What is KubeLinter?

KubeLinter analyzes Kubernetes YAML files and Helm charts, and checks them against a variety of best practices, with a focus on production readiness and security.

KubeLinter runs sensible default checks, designed to give you useful information about your Kubernetes YAML files and Helm charts. This is to help teams check early and often for security misconfigurations and DevOps best practices. Some common examples of these include running containers as a non-root user, enforcing least privilege, and storing sensitive information only in secrets.

KubeLinter is configurable, so you can enable and disable checks, as well as create your own custom checks, depending on the policies you want to follow within your organization.

When a lint check fails, KubeLinter reports recommendations for how to resolve any potential issues and returns a non-zero exit code.

Documentation

Visit https://docs.kubelinter.io for detailed documentation on installing, using and configuring KubeLinter.

Installing KubeLinter

Using Go

To install using Go, run the following command:

GO111MODULE=on go install golang.stackrox.io/kube-linter/cmd/kube-linter

Otherwise, download the latest binary from Releases and add it to your PATH.

Using Homebrew for macOS or LinuxBrew for Linux

To install using Homebrew or LinuxBrew, run the following command:

brew install kube-linter

Building from source

Prerequisites

  • Make sure that you have installed Go prior to building from source.

Building KubeLinter

Installing KubeLinter from source is as simple as following these steps:

First, clone the KubeLinter repository.

git clone git@github.com:stackrox/kube-linter.git

Then, compile the source code. This will create the kube-linter binary files for each platform and places them in the .gobin folder.

make build

Finally, you are ready to start using KubeLinter. Verify your version to ensure you've successfully installed KubeLinter.

.gobin/kube-linter version

Testing KubeLinter

There are several layers of testing. Each layer is expected to pass.

go unit tests:

make test

end-to-end integration tests:

make e2e-test

and finally, end-to-end integration tests using bats-core:

make e2e-bats

Verifying KubeLinter images

KubeLinter images are signed by cosign. We recommend verifying the image before using it.

Once you've installed cosign, you can use the KubeLinter public key to verify the KubeLinter image with:

cat kubelinter-cosign.pub
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEl0HCkCRzYv0qH5QiazoXeXe2qwFX
DmAszeH26g1s3OSsG/focPWkN88wEKQ5eiE95v+Z2snUQPl/mjPdvqpyjA==
-----END PUBLIC KEY-----


cosign verify --key kubelinter-cosign $IMAGE_NAME

KubeLinter also provides cosign keyless signatures.

You can verify the KubeLinter image with:

# NOTE: Keyless signatures are NOT PRODUCTION ready.

COSIGN_EXPERIMENTAL=1 cosign verify $IMAGE_NAME

Using KubeLinter

Local YAML Linting

Running KubeLinter to Lint your YAML files only requires two steps in its most basic form.

Locate the YAML file you'd like to test for security and production readiness best practices:

Run the following command:

kube-linter lint /path/to/your/yaml.yaml

Example

Consider the following sample pod specification file pod.yaml. This file has two production readiness issues and one security issue:

Security Issue:

  1. The container in this pod is not running as a read only file system, which could allow it to write to the root filesystem.

Production readiness:

The container's CPU limits are not set, which could allow it to consume excessive CPU.

The container's memory limits are not set, which could allow it to consume excessive memory

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

Copy the YAML above to pod.yaml and lint this file by running the following command:

kube-linter lint pod.yaml

KubeLinter runs its default checks and reports recommendations. Below is the output from our previous command.

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in your container's securityContext.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set    your container's CPU requests and limits depending on its requirements. See    https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has memory limit 0 (check: unset-memory-requirements, remediation:    Set your container's memory requests and limits depending on its requirements.    See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

Error: found 3 lint errors

To learn more about using and configuring KubeLinter, visit the documentation page.

Mentions/Tutorials

The following are tutorials on KubeLinter written by users. If you have one that you would like to add to this list, please send a PR!

Community

If you would like to engage with the KubeLinter community, including maintainers and other users, you can join the Slack workspace here.

To contribute, check out our contributing guide.

As a reminder, all participation in the KubeLinter community is governed by our code of conduct.

WARNING: Alpha release

KubeLinter is at an early stage of development. There may be breaking changes in the future to the command usage, flags, and configuration file formats. However, we encourage you to use KubeLinter to test your environment YAML files, see what breaks, and contribute.

StackRox

KubeLinter is made with ❤️ by StackRox.

If you're interested in KubeLinter, or in any of the other cool things we do, please know that we're hiring! Check out our open positions. We'd love to hear from you!

Author: stackrox
Source Code: https://github.com/stackrox/kube-linter
License: Apache-2.0 License

#kubernetes #linter #yaml 

KubeLinter: Static Analysis Tool That Checks Kubernetes YAML Files
Annie  Emard

Annie Emard

1652461380

CheckMake: Experimental Linter/Analyzer for Makefiles

checkmake

Overview

checkmake is an experimental tool for linting and checking Makefiles. It may not do what you want it to.

Usage

% checkmake Makefile

% checkmake --help
checkmake.

Usage:
checkmake [--debug|--config=<configPath>] <makefile>
checkmake -h | --help
checkmake --version

Options:
-h --help               Show this screen.
--version               Show version.
--debug                 Enable debug mode
--config=<configPath>   Configuration file to read
--list-rules            List registered rules

% checkmake fixtures/missing_phony.make

      RULE                 DESCRIPTION             LINE NUMBER

  minphony        Missing required phony target    0
                  "all"
  minphony        Missing required phony target    0
                  "test"
  phonydeclared   Target "all" should be           18
                  declared PHONY.

Docker usage

Build the image, or pull it:

docker build --build-arg BUILDER_NAME='Your Name' --build-arg BUILDER_EMAIL=your.name@example.com . -t checker

Then run it with your Makefile attached, below is an example of it assuming the Makefile is in your current working directory:

docker run -v "$PWD"/Makefile:/Makefile checker

Installation

Requirements

The pandoc document converter utility is required to run checkmate. You can find out if you have it via which pandoc. Install pandoc if the command was not found.

Packages

There are packages for linux up on packagecloud.io or build it yourself with the steps below.

Build

To build checkmake you will need to have golang installed. Once you have Go installed, you can simply clone the repo and build the binary and man page yourself with the following commands.

git clone https://github.com/mrtazz/checkmake
cd checkmake
make

Inspiration

This is totally inspired by an idea by Dan Buch.

Author: mrtazz
Source Code: https://github.com/mrtazz/checkmake
License: MIT License

#go #linter #analyzer 

CheckMake: Experimental Linter/Analyzer for Makefiles
Annie  Emard

Annie Emard

1652281500

Combination Of Multiple Linters To Install As A GitHub Action

Super-Linter

This repository is for the GitHub Action to run a Super-Linter. It is a simple combination of various linters, written in bash, to help validate your source code.

The end goal of this tool:

  • Prevent broken code from being uploaded to the default branch (Usually master or main)
  • Help establish coding best practices across multiple languages
  • Build guidelines for code layout and format
  • Automate the process to help streamline code reviews

How it Works

The super-linter finds issues and reports them to the console output. Fixes are suggested in the console output but not automatically fixed, and a status check will show up as failed on the pull request.

The design of the Super-Linter is currently to allow linting to occur in GitHub Actions as a part of continuous integration occurring on pull requests as the commits get pushed. It works best when commits are being pushed early and often to a branch with an open or draft pull request. There is some desire to move this closer to local development for faster feedback on linting errors but this is not yet supported.

Repository Visualization

Supported Linters

Developers on GitHub can call the GitHub Action to lint their codebase with the following list of linters:

LanguageLinter
Ansibleansible-lint
AWS CloudFormation templatescfn-lint
Azure Resource Manager (ARM)arm-ttk
C++cpp-lint / clang-format
C#dotnet-format / clang-format
CSSstylelint
Clojureclj-kondo
CoffeeScriptcoffeelint
Copy/paste detectionjscpd
Dartdartanalyzer
Dockerfilehadolint
EditorConfigeditorconfig-checker
ENVdotenv-linter
Gherkingherkin-lint
GitHub Actionsactionlint
Golanggolangci-lint
Groovynpm-groovy-lint
HTMLHTMLHint
Javacheckstyle / google-java-format
JavaScriptESLint / standard js
JSONeslint-plugin-json
JSONCeslint-plugin-jsonc
Kubevalkubeval
Kotlinktlint
LaTeXChkTex
Lualuacheck
Markdownmarkdownlint
Natural languagetextlint
OpenAPIspectral
Perlperlcritic
PHPPHP built-in linter / PHP CodeSniffer / PHPStan / Psalm
PowerShellPSScriptAnalyzer
Protocol Buffersprotolint
Python3pylint / flake8 / black / isort
Rlintr
RakuRaku
RubyRuboCop
RustRustfmt / Clippy
Scalascalafmt
SecretsGitLeaks
ShellShellcheck / [executable bit check] / shfmt
Snakemakesnakefmt / snakemake --lint
SQLsql-lint / sqlfluff
Tektontekton-lint
Terraformtflint / terrascan
Terragruntterragrunt
TypeScriptESLint / standard js
XMLLibXML
YAMLYamlLint

How to use

More in-depth tutorial available

To use this GitHub Action you will need to complete the following:

  1. Create a new file in your repository called .github/workflows/linter.yml
  2. Copy the example workflow from below into that new file, no extra configuration required
  3. Commit that file to a new branch
  4. Open up a pull request and observe the action working
  5. Enjoy your more stable, and cleaner codebase
  6. Check out the Wiki for customization options

NOTE: If you pass the Environment variable GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} in your workflow, then the GitHub Super-Linter will mark the status of each individual linter run in the Checks section of a pull request. Without this you will only see the overall status of the full run. There is no need to set the GitHub Secret as it is automatically set by GitHub, it only needs to be passed to the action.

Example connecting GitHub Action Workflow

In your repository you should have a .github/workflows folder with GitHub Action similar to below:

This file should have the following code:

---
#################################
#################################
## Super Linter GitHub Actions ##
#################################
#################################
name: Lint Code Base

#
# Documentation:
# https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions
#

#############################
# Start the job on all push #
#############################
on:
  push:
    branches-ignore: [master, main]
    # Remove the line above to run when pushing to master
  pull_request:
    branches: [master, main]

###############
# Set the Job #
###############
jobs:
  build:
    # Name the Job
    name: Lint Code Base
    # Set the agent to run on
    runs-on: ubuntu-latest

    ##################
    # Load all steps #
    ##################
    steps:
      ##########################
      # Checkout the code base #
      ##########################
      - name: Checkout Code
        uses: actions/checkout@v3
        with:
          # Full git history is needed to get a proper list of changed files within `super-linter`
          fetch-depth: 0

      ################################
      # Run Linter against code base #
      ################################
      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: master
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Add Super-Linter badge in your repository README

You can show Super-Linter status with a badge in your repository README

Format:

[![GitHub Super-Linter](https://github.com/<OWNER>/<REPOSITORY>/workflows/Lint%20Code%20Base/badge.svg)](https://github.com/marketplace/actions/super-linter)

Example:

[![GitHub Super-Linter](https://github.com/nvuillam/npm-groovy-lint/workflows/Lint%20Code%20Base/badge.svg)](https://github.com/marketplace/actions/super-linter)

Note: IF you did not use Lint Code Base as GitHub Action name, please read GitHub Actions Badges documentation.

Images

The GitHub Super-Linter now builds and supports multiple images. We have found as we added more linters, the image size expanded drastically. After further investigation, we were able to see that a few linters were very disk heavy. We removed those linters and created the slim image. This allows users to choose which Super-Linter they want to run and potentially speed up their build time. The available images:

  • github/super-linter:v4
  • github/super-linter:slim-v4

Standard Image

The standard github/super-linter:v4 comes with all supported linters. Example usage:

################################
# Run Linter against code base #
################################
- name: Lint Code Base
  uses: github/super-linter@v4
  env:
    VALIDATE_ALL_CODEBASE: false
    DEFAULT_BRANCH: master
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Slim Image

The slim github/super-linter:slim-v4 comes with all supported linters but removes the following:

  • rust linters
  • dotenv linters
  • armttk linters
  • pwsh linters
  • c# linters

By removing these linters, we were able to bring the image size down by 2gb and drastically speed up the build and download time. The behavior will be the same for non-supported languages, and will skip languages at run time. Example usage:

################################
# Run Linter against code base #
################################
- name: Lint Code Base
  uses: github/super-linter/slim@v4
  env:
    VALIDATE_ALL_CODEBASE: false
    DEFAULT_BRANCH: master
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Environment variables

The super-linter allows you to pass the following ENV variables to be able to trigger different functionality.

Note: All the VALIDATE_[LANGUAGE] variables behave in a very specific way:

  • If none of them are passed, then they all default to true.
  • If any one of the variables are set to true, we default to leaving any unset variable to false (only validate those languages).
  • If any one of the variables are set to false, we default to leaving any unset variable to true (only exclude those languages).
  • If there are VALIDATE_[LANGUAGE] variables set to both true and false. It will fail.

This means that if you run the linter "out of the box", all languages will be checked. But if you wish to select or exclude specific linters, we give you full control to choose which linters are run, and won't run anything unexpected.

ENV VARDefault ValueNotes
ACTIONS_RUNNER_DEBUGfalseFlag to enable additional information about the linter, versions, and additional output.
ANSIBLE_CONFIG_FILE.ansible-lint.ymlFilename for Ansible-lint configuration (ex: .ansible-lint, .ansible-lint.yml)
ANSIBLE_DIRECTORY/ansibleFlag to set the root directory for Ansible file location(s), relative to DEFAULT_WORKSPACE. Set to . to use the top-level of the DEFAULT_WORKSPACE.
ANSIBLE_ROLES_PATH${ANSIBLE_DIRECTORY}/rolesPath to the Ansible roles directory.
CSS_FILE_NAME.stylelintrc.jsonFilename for Stylelint configuration (ex: .stylelintrc.yml, .stylelintrc.yaml)
DEFAULT_BRANCHmasterThe name of the repository default branch.
DEFAULT_WORKSPACE/tmp/lintThe location containing files to lint if you are running locally.
DISABLE_ERRORSfalseFlag to have the linter complete with exit code 0 even if errors were detected.
DOCKERFILE_HADOLINT_FILE_NAME.hadolint.yamlFilename for hadolint configuration (ex: .hadolintlintrc.yaml)
EDITORCONFIG_FILE_NAME.ecrcFilename for editorconfig-checker configuration
ERROR_ON_MISSING_EXEC_BITfalseIf set to false, the bash-exec linter will report a warning if a shell script is not executable. If set to true, the bash-exec linter will report an error instead.
FILTER_REGEX_EXCLUDEnoneRegular expression defining which files will be excluded from linting (ex: .*src/test.*)
FILTER_REGEX_INCLUDEallRegular expression defining which files will be processed by linters (ex: .*src/.*)
GITHUB_ACTIONS_CONFIG_FILEactionlint.ymlFilename for Actionlint configuration (ex: actionlint.yml)
GITHUB_CUSTOM_API_URLhttps://api.github.comSpecify a custom GitHub API URL in case GitHub Enterprise is used: e.g. https://github.myenterprise.com/api/v3
GITHUB_DOMAINgithub.comSpecify a custom GitHub domain in case GitHub Enterprise is used: e.g. github.myenterprise.com
GITLEAKS_CONFIG_FILE.gitleaks.tomlFilename for GitLeaks configuration (ex: .geatleaks.toml)
IGNORE_GENERATED_FILESfalseIf set to true, super-linter will ignore all the files with @generated marker but without @not-generated marker.
IGNORE_GITIGNORED_FILESfalseIf set to true, super-linter will ignore all the files that are ignored by Git.
JAVA_FILE_NAMEsun_checks.xmlFilename for Checkstyle configuration (ex: checkstyle.xml)
JAVASCRIPT_DEFAULT_STYLEstandardFlag to set the default style of JavaScript. Available options: standard/prettier
JAVASCRIPT_ES_CONFIG_FILE.eslintrc.ymlFilename for ESLint configuration (ex: .eslintrc.yml, .eslintrc.json)
JSCPD_CONFIG_FILE.jscpd.jsonFilename for JSCPD configuration
KUBERNETES_KUBEVAL_OPTIONSnullAdditional arguments to pass to the command-line when running Kubernetes Kubeval (Example: --ignore-missing-schemas)
LINTER_RULES_PATH.github/lintersDirectory for all linter configuration rules.
LOG_FILEsuper-linter.logThe filename for outputting logs. All output is sent to the log file regardless of LOG_LEVEL.
LOG_LEVELVERBOSEHow much output the script will generate to the console. One of ERROR, WARN, NOTICE, VERBOSE, DEBUG or TRACE.
MARKDOWN_CONFIG_FILE.markdown-lint.ymlFilename for Markdownlint configuration (ex: .markdown-lint.yml, .markdownlint.json, .markdownlint.yaml)
MARKDOWN_CUSTOM_RULE_GLOBS.markdown-lint/rules,rules/**Comma-separated list of file globs matching custom Markdownlint rule files.
MULTI_STATUStrueA status API is made for each language that is linted to make visual parsing easier.
NATURAL_LANGUAGE_CONFIG_FILE.textlintrcFilename for textlint configuration (ex: .textlintrc)
PERL_PERLCRITIC_OPTIONSnullAdditional arguments to pass to the command-line when running perlcritic (Example: --theme community)
PHP_CONFIG_FILEphp.iniFilename for PHP Configuration (ex: php.ini)
PROTOBUF_CONFIG_FILE.protolintrc.ymlFilename for protolint configuration (ex: .protolintrc.yml)
PYTHON_BLACK_CONFIG_FILE.python-blackFilename for black configuration (ex: .isort.cfg, pyproject.toml)
PYTHON_FLAKE8_CONFIG_FILE.flake8Filename for flake8 configuration (ex: .flake8, tox.ini)
PYTHON_ISORT_CONFIG_FILE.isort.cfgFilename for isort configuration (ex: .isort.cfg, pyproject.toml)
PYTHON_MYPY_CONFIG_FILE.mypy.iniFilename for mypy configuration (ex: .mypi.ini, setup.config)
PYTHON_PYLINT_CONFIG_FILE.python-lintFilename for pylint configuration (ex: .python-lint, .pylintrc)
RUBY_CONFIG_FILE.ruby-lint.ymlFilename for rubocop configuration (ex: .ruby-lint.yml, .rubocop.yml)
SCALAFMT_CONFIG_FILE.scalafmt.confFilename for scalafmt configuration (ex: .scalafmt.conf)
SNAKEMAKE_SNAKEFMT_CONFIG_FILE.snakefmt.tomlFilename for Snakemake configuration (ex: pyproject.toml, .snakefmt.toml)
SSL_CERT_SECRETnoneSSL cert to add to the Super-Linter trust store. This is needed for users on self-hosted runners or need to inject the cert for security standards (ex. ${{ secrets.SSL_CERT }})
SSH_KEYnoneSSH key that has access to your private repositories
SSH_SETUP_GITHUBfalseIf set to true, adds the github.com SSH key to known_hosts. This is ignored if SSH_KEY is provided - i.e. the github.com SSH key is always added if SSH_KEY is provided
SSH_INSECURE_NO_VERIFY_GITHUB_KEYfalseINSECURE - If set to true, does not verify the fingerprint of the github.com SSH key before adding this. This is not recommended!
SQL_CONFIG_FILE.sql-config.jsonFilename for SQL-Lint configuration (ex: sql-config.json , .config.json)
SQLFLUFF_CONFIG_FILE/.sqlfluffFilename for SQLFLUFF configuration (ex: /.sqlfluff, pyproject.toml)
SUPPRESS_FILE_TYPE_WARNfalseIf set to true, will hide warning messages about files without their proper extensions. Default is false
SUPPRESS_POSSUMfalseIf set to true, will hide the ASCII possum at top of log output. Default is false
TERRAFORM_TERRASCAN_CONFIG_FILEterrascan.tomlFilename for terrascan configuration (ex: terrascan.toml)
TERRAFORM_TFLINT_CONFIG_FILE.tflint.hclFilename for tfLint configuration (ex: .tflint.hcl)
TYPESCRIPT_DEFAULT_STYLEts-standardFlag to set the default style of TypeScript. Available options: ts-standard/prettier
TYPESCRIPT_ES_CONFIG_FILE.eslintrc.ymlFilename for ESLint configuration (ex: .eslintrc.yml, .eslintrc.json)
TYPESCRIPT_STANDARD_TSCONFIG_FILEtsconfig.jsonFilename for TypeScript configuration in ts-standard (ex: tsconfig.json, tsconfig.eslint.json)
USE_FIND_ALGORITHMfalseBy default, we use git diff to find all files in the workspace and what has been updated, this would enable the Linux find method instead to find all files to lint
VALIDATE_ALL_CODEBASEtrueWill parse the entire repository and find all files to validate across all types. NOTE: When set to false, only new or edited files will be parsed for validation.
VALIDATE_JSCPD_ALL_CODEBASEfalseIf set to true, will lint the whole codebase with JSCPD. If set to false, JSCPD will only lint files one by one.
VALIDATE_ANSIBLEtrueFlag to enable or disable the linting process of the Ansible language.
VALIDATE_ARMtrueFlag to enable or disable the linting process of the ARM language.
VALIDATE_BASHtrueFlag to enable or disable the linting process of the Bash language.
VALIDATE_BASH_EXECtrueFlag to enable or disable the linting process of the Bash language to validate if file is stored as executable.
VALIDATE_CPPtrueFlag to enable or disable the linting process of the C++ language.
VALIDATE_CLANG_FORMATtrueFlag to enable or disable the linting process of the C++/C language with clang-format.
VALIDATE_CLOJUREtrueFlag to enable or disable the linting process of the Clojure language.
VALIDATE_CLOUDFORMATIONtrueFlag to enable or disable the linting process of the AWS Cloud Formation language.
VALIDATE_COFFEESCRIPTtrueFlag to enable or disable the linting process of the Coffeescript language.
VALIDATE_CSHARPtrueFlag to enable or disable the linting process of the C# language.
VALIDATE_CSStrueFlag to enable or disable the linting process of the CSS language.
VALIDATE_DARTtrueFlag to enable or disable the linting process of the Dart language.
VALIDATE_DOCKERFILE_HADOLINTtrueFlag to enable or disable the linting process of the Docker language.
VALIDATE_EDITORCONFIGtrueFlag to enable or disable the linting process with the EditorConfig.
VALIDATE_ENVtrueFlag to enable or disable the linting process of the ENV language.
VALIDATE_GHERKINtrueFlag to enable or disable the linting process of the Gherkin language.
VALIDATE_GITHUB_ACTIONStrueFlag to enable or disable the linting process of the GitHub Actions.
VALIDATE_GITLEAKStrueFlag to enable or disable the linting process of the secrets.
VALIDATE_GOtrueFlag to enable or disable the linting process of the Golang language.
VALIDATE_GOOGLE_JAVA_FORMATtrueFlag to enable or disable the linting process of the Java language. (Utilizing: google-java-format)
VALIDATE_GROOVYtrueFlag to enable or disable the linting process of the language.
VALIDATE_HTMLtrueFlag to enable or disable the linting process of the HTML language.
VALIDATE_JAVAtrueFlag to enable or disable the linting process of the Java language. (Utilizing: checkstyle)
VALIDATE_JAVASCRIPT_EStrueFlag to enable or disable the linting process of the JavaScript language. (Utilizing: eslint)
VALIDATE_JAVASCRIPT_STANDARDtrueFlag to enable or disable the linting process of the JavaScript language. (Utilizing: standard)
VALIDATE_JSCPDtrueFlag to enable or disable the JSCPD.
VALIDATE_JSONtrueFlag to enable or disable the linting process of the JSON language.
VALIDATE_JSXtrueFlag to enable or disable the linting process for jsx files (Utilizing: eslint)
VALIDATE_KOTLINtrueFlag to enable or disable the linting process of the Kotlin language.
VALIDATE_KOTLIN_ANDROIDtrueFlag to enable or disable the linting process of the Kotlin language. (Utilizing: ktlint --android)
VALIDATE_KUBERNETES_KUBEVALtrueFlag to enable or disable the linting process of Kubernetes descriptors with Kubeval
VALIDATE_LATEXtrueFlag to enable or disable the linting process of the LaTeX language.
VALIDATE_LUAtrueFlag to enable or disable the linting process of the language.
VALIDATE_MARKDOWNtrueFlag to enable or disable the linting process of the Markdown language.
VALIDATE_NATURAL_LANGUAGEtrueFlag to enable or disable the linting process of the natural language.
VALIDATE_OPENAPItrueFlag to enable or disable the linting process of the OpenAPI language.
VALIDATE_PERLtrueFlag to enable or disable the linting process of the Perl language.
VALIDATE_PHPtrueFlag to enable or disable the linting process of the PHP language. (Utilizing: PHP built-in linter) (keep for backward compatibility)
VALIDATE_PHP_BUILTINtrueFlag to enable or disable the linting process of the PHP language. (Utilizing: PHP built-in linter)
VALIDATE_PHP_PHPCStrueFlag to enable or disable the linting process of the PHP language. (Utilizing: PHP CodeSniffer)
VALIDATE_PHP_PHPSTANtrueFlag to enable or disable the linting process of the PHP language. (Utilizing: PHPStan)
VALIDATE_PHP_PSALMtrueFlag to enable or disable the linting process of the PHP language. (Utilizing: PSalm)
VALIDATE_POWERSHELLtrueFlag to enable or disable the linting process of the Powershell language.
VALIDATE_PROTOBUFtrueFlag to enable or disable the linting process of the Protobuf language.
VALIDATE_PYTHONtrueFlag to enable or disable the linting process of the Python language. (Utilizing: pylint) (keep for backward compatibility)
VALIDATE_PYTHON_BLACKtrueFlag to enable or disable the linting process of the Python language. (Utilizing: black)
VALIDATE_PYTHON_FLAKE8trueFlag to enable or disable the linting process of the Python language. (Utilizing: flake8)
VALIDATE_PYTHON_ISORTtrueFlag to enable or disable the linting process of the Python language. (Utilizing: isort)
VALIDATE_PYTHON_MYPYtrueFlag to enable or disable the linting process of the Python language. (Utilizing: mypy)
VALIDATE_PYTHON_PYLINTtrueFlag to enable or disable the linting process of the Python language. (Utilizing: pylint)
VALIDATE_RtrueFlag to enable or disable the linting process of the R language.
VALIDATE_RAKUtrueFlag to enable or disable the linting process of the Raku language.
VALIDATE_RUBYtrueFlag to enable or disable the linting process of the Ruby language.
VALIDATE_RUST_2015trueFlag to enable or disable the linting process of the Rust language. (edition: 2015)
VALIDATE_RUST_2018trueFlag to enable or disable the linting process of Rust language. (edition: 2018)
VALIDATE_RUST_2021trueFlag to enable or disable the linting process of Rust language. (edition: 2021)
VALIDATE_RUST_CLIPPYtrueFlag to enable or disable the clippy linting process of Rust language.
VALIDATE_SCALAFMTtrueFlag to enable or disable the linting process of Scala language. (Utilizing: scalafmt --test)
VALIDATE_SHELL_SHFMTtrueFlag to enable or disable the linting process of Shell scripts. (Utilizing: shfmt)
VALIDATE_SNAKEMAKE_LINTtrueFlag to enable or disable the linting process of Snakefiles. (Utilizing: snakemake --lint)
VALIDATE_SNAKEMAKE_SNAKEFMTtrueFlag to enable or disable the linting process of Snakefiles. (Utilizing: snakefmt)
VALIDATE_STATEStrueFlag to enable or disable the linting process for AWS States Language.
VALIDATE_SQLtrueFlag to enable or disable the linting process of the SQL language.
VALIDATE_SQLFLUFFtrueFlag to enable or disable the linting process of the SQL language. (Utilizing: sqlfuff)
VALIDATE_TEKTONtrueFlag to enable or disable the linting process of the Tekton language.
VALIDATE_TERRAFORM_TERRASCANtrueFlag to enable or disable the linting process of the Terraform language for security related issues.
VALIDATE_TERRAFORM_TFLINTtrueFlag to enable or disable the linting process of the Terraform language. (Utilizing tflint)
VALIDATE_TERRAGRUNTtrueFlag to enable or disable the linting process for Terragrunt files.
VALIDATE_TSXtrueFlag to enable or disable the linting process for tsx files (Utilizing: eslint)
VALIDATE_TYPESCRIPT_EStrueFlag to enable or disable the linting process of the TypeScript language. (Utilizing: eslint)
VALIDATE_TYPESCRIPT_STANDARDtrueFlag to enable or disable the linting process of the TypeScript language. (Utilizing: ts-standard)
VALIDATE_XMLtrueFlag to enable or disable the linting process of the XML language.
VALIDATE_YAMLtrueFlag to enable or disable the linting process of the YAML language.
YAML_CONFIG_FILE.yaml-lint.ymlFilename for Yamllint configuration (ex: .yaml-lint.yml, .yamllint.yml)
YAML_ERROR_ON_WARNINGfalseFlag to enable or disable the error on warning for Yamllint.

Template rules files

You can use the GitHub Super-Linter with or without your own personal rules sets. This allows for greater flexibility for each individual codebase. The Template rules all try to follow the standards we believe should be enabled at the basic level.

  • Copy any or all template rules files from TEMPLATES/ into the .github/linters/ directory of your repository, and modify them to suit your needs.

Using your own rules files

If your repository contains your own rules files that live outside of a .github/linters/ directory, you will have to tell Super-Linter where your rules files are located in your repository, and what their filenames are. To learn more, see Using your own rules files.

Disabling rules

If you need to disable certain rules and functionality, you can view Disable Rules

Using your own SSH key

If you need to add your own SSH key to the linter because of private dependencies, you can use the SSH_KEY environment variable. The value of that environment variable should be an SSH private key that has access to your private repositories.

You should add this key as an Encrypted Secret and access it with the secrets parameter.

Example workflow:

---
#################################
#################################
## Super Linter GitHub Actions ##
#################################
#################################
name: Lint Code Base

#
# Documentation:
# https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions
#

#############################
# Start the job on all push #
#############################
on:
  push:
    branches-ignore: [master, main]
    # Remove the line above to run when pushing to master
  pull_request:
    branches: [master, main]

###############
# Set the Job #
###############
jobs:
  build:
    # Name the Job
    name: Lint Code Base
    # Set the agent to run on
    runs-on: ubuntu-latest

    ##################
    # Load all steps #
    ##################
    steps:
      ##########################
      # Checkout the code base #
      ##########################
      - name: Checkout Code
        uses: actions/checkout@v2
        with:
          # Full git history is needed to get a proper list of changed files within `super-linter`
          fetch-depth: 0

      ################################
      # Run Linter against code base #
      ################################
      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: master
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

Filter linted files

If you need to lint only a folder or exclude some files from linting, you can use optional environment parameters FILTER_REGEX_INCLUDE and FILTER_REGEX_EXCLUDE

Examples:

  • Lint only src folder: FILTER_REGEX_INCLUDE: .*src/.*
  • Do not lint files inside test folder: FILTER_REGEX_EXCLUDE: .*test/.*
  • Do not lint JavaScript files inside test folder: FILTER_REGEX_EXCLUDE: .*test/.*.js

Additionally when IGNORE_GENERATED_FILES=true, super-linter ignores any file with @generated marker in it unless the file also has @not-generated marker. @generated marker is used by Facebook and some other projects to mark generated files. For example, this file is considered generated:

#!/bin/sh
echo "@generated"

And this file is considered not generated:

#!/bin/sh
echo "@generated" # @not-generated

Docker Hub

The Docker container that is built from this repository is located at github/super-linter

Run Super-Linter outside GitHub Actions

Local (troubleshooting/debugging/enhancements)

If you find that you need to run super-linter locally, you can follow the documentation at Running super-linter locally

Check out the note in How it Works to understand more about the Super-Linter linting locally versus via continuous integration.

Azure

Check out this article

GitLab

Check out this snippet and this Guided Exploration: GitLab CI CD Extension for Super-Linter

Visual Studio Code

You can checkout this repository using Container Remote Development, and debug the linter using the Test Linter task. Example

We will also support GitHub Codespaces once it becomes available

SSL Certs

If you need to inject a SSL cert into the trust store, you will need to first copy the cert to GitHub Secrets Once you have copied the plain text certificate into GitHub Secrets, you can use the variable SSL_CERT_SECRET to point the Super-Linter to the files contents. Once found, it will load the certificate contents to a file, and to the trust store.

  • Example workflow:
- name: Lint Code Base
  uses: github/super-linter@v4
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SSL_CERT_SECRET: ${{ secrets.ROOT_CA }}

Community Activity

super-linter stats

Limitations

Below are a list of the known limitations for the GitHub Super-Linter:

  • Due to being completely packaged at run time, you will not be able to update dependencies or change versions of the enclosed linters and binaries
  • Additional details from package.json are not read by the GitHub Super-Linter
  • Downloading additional codebases as dependencies from private repositories will fail due to lack of permissions

How to contribute

If you would like to help contribute to this GitHub Action, please see CONTRIBUTING

Author: github
Source Code: https://github.com/github/super-linter
License: MIT License

#github #linter 

Combination Of Multiple Linters To Install As A GitHub Action

How to Use Linter — The Better Way

The linters are great tools that helps developers to improve code quality and even discover potential bugs. It uses static analysis approach and can provide almost realtime feedback when combining with IDEs / editors. It is more and more common for developers to adopt it and even some programming languages (ex. Golang) embedded a linter by default (and refuse to run if you got lint errors). But sometimes we might not use it in the best way, and I would like to share my two-cents in this post.

Linter at a glance

Let’s use eslint as an example to demo how linter works. When using linter, it is actually pretty straightforward and you just need to pass the path of source code as argument:

$ eslint src/**/*.js

And when there is an error, the output might look like this:

> eslint src/**/*.js 

/home/jeromewu/repos/app/src/App.js 
  10:61  error  'undefinedVar' is not defined  no-undef 

✖ 1 problem (1 error, 0 warnings)

If you are lucky, you code still works even with lint errors (even for the example above, if you code never execute the code contains this undefined variable, it still works). But it is recommended to fix all lint errors to reduce risks.

Although linter is useful, but sometimes developers may find it annoying as some lint rules are not easy to follow or your habit just different from the rules. And this is where I think some developers might misunderstand the purpose of linters.

Don’t just use linters, learn from lint rules

In my opinion, the purpose of the linters is not to find out the issues in our code and make our life miserable, but to help us to learn how to improve code quality according to the rules we applied. So the ultimate outcome should be us (as a developer) being able to write lint-error free code without linters reminding us all the time. So for me (and my team), the typical workflow with linters is like this:

  • No matter which IDE or editor we use, install linter plugins to have realtime lint hints.
  • Whenever encountering a lint error and we don’t understand why, check the website for explanation. (ex.  no-undef in eslint)
  • If there is any rule that is not applicable in our use cases, turn it off for certain files or totally disable in configuration file. (Yes, it is totally fine to disable lint rules as long as you are sure about that)
  • Repeat steps above and train ourselves to have less and less lint hints during development.

With this workflow and mindset, I believe linters are no longer your enemies, but good partners to help you improve and learn.

#linter #software #javascript #golang

How to Use Linter — The Better Way
Royce  Reinger

Royce Reinger

1622442240

Keep Your Code Clean using Black & Pylint & Git Hooks & Pre-commit

Indispensable tools for collaborative development

Coding can be a very hard task especially when working on a project with different developers. Each member of the team has his/her own way of coding leading to very heterogeneous scripts.

This is why it is important to have a similar **code formatter **and **code linter **in order to make your git commits cleaner. This can be carried out either between the staging and committing phase or during the CI/CD chain.

In this article, we will see how to do so as a pre-commit step using git hooks.

Table of content

The summary is as follows:

  1. Black
  2. Pylint
  3. Pre-commits as Git Hooks

Black

Black is a python code formatter which style configurations are deliberately limited. It makes your code cleaner so you can focus more on the content. The code review is also more efficient since the diffs are as minor as possible.

It can be installed using the following command line:

pip install black

You can run black on any python file by typing:

Black pathtofile.py

Image by the author

#coding #git #python #linter

Keep Your Code Clean using Black & Pylint & Git Hooks & Pre-commit
Elian  Harber

Elian Harber

1620316020

Writing Custom Linter in Go

Writing linters is simple. I was surprised how it’s easy to write a Go linter. Today, we’ll write a linter that will calculate the cyclomatic complexity of the Go code.

What is cyclomatic complexity?

Cyclomatic complexity is a software metric used to indicate the complexity of a program. ref

The idea is simple — every time we find any control flow statements we increase the complexity by one. I know I oversimplified it a bit but I don’t want to overwhelm you with unnecessary details.

There are a few steps we should follow to write our custom linter. Firstly, we can create a test that will check if our linter works or not. Let’s put him into pkg/analyzer/analyzer_test.go file.

package analyzer

import (
	"os"
	"path/filepath"
	"testing"

	"golang.org/x/tools/go/analysis/analysistest"
)

func TestAll(t *testing.T) {
	wd, err := os.Getwd()
	if err != nil {
		t.Fatalf("Failed to get wd: %s", err)
	}

	testdata := filepath.Join(filepath.Dir(filepath.Dir(wd)), "testdata")
	analysistest.Run(t, testdata, NewAnalyzer(), "complexity")
}

The analysistest.Run() function is a helper that simplifies testing linters. What it does is running our linter on package complexity in testate folder. We use NewAnalyzer() function that will return instance of our analyzer. Let’s add it to pkg/analyzer/analyzer.go.

#go #golang #linter

Writing Custom Linter in Go

5 CSS Build Tools That You Should Know in 2021

FrontEnd development is evolving rapidly. And with it, CSS is getting interesting. New features such as logical properties, content-visibility have made their way into CSS recently.

The State of CSS 2020 survey has listed a few tools that developers know about and use regularly. Based on the survey result, let’s take a moment to list a few of those tools that you should probably know about.

#programming #web-development #linter #css #front-end-development

5 CSS Build Tools That You Should Know in 2021

Ysia Tamas

1604917320

Enhancing Code Quality With Github Actions

This article will shed light on one of the features that Github offers, which enables us to achieve the above step and much-more.

Let us delve deeper into this feature and explore a way to maintain the production-level code quality.

Github Actions

Github actions allow users to automate tasks of the Software development lifecycle like Code Review, Building, and Deployment.

Github Actions provides the feature to attach some workflows with a repository. These workflows will get automatically triggered by events like Pull Request, Push, etc. and perform some actions based on its definition.

**Workflow: **A workflow is the collection of one or more jobs that will be automatically triggered by any event or can be scheduled by the user. It is used to build, test, deploy the code of your repository.

#programming #linter #github-actions #good-programming-practice #github

Enhancing Code Quality With Github Actions