Commitlint: Lint Commit Messages

Lint commit messages

Demo generated with svg-term-cli

cat docs/assets/commitlint.json | svg-term --out docs/assets/commitlint.svg --frame --profile=Seti --height=20 --width=80

  • 🚓 Be a good commitizen
  • 📦 Share configuration via npm
  • 🤖 Tap into conventional-changelog

What is commitlint

commitlint checks if your commit messages meet the conventional commit format.

In general the pattern mostly looks like this:

type(scope?): subject  #scope is optional; multiple scopes are supported (current delimiter options: "/", "\" and ",")

Real world examples can look like this:

chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section

Common types according to commitlint-config-conventional (based on the Angular convention) can be:

  • build
  • chore
  • ci
  • docs
  • feat
  • fix
  • perf
  • refactor
  • revert
  • style
  • test

These can be modified by your own configuration.

Benefits using commitlint

Getting started

# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}
# For Windows:
npm install --save-dev @commitlint/config-conventional @commitlint/cli

# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

To lint commits before they are created you can use Husky's commit-msg hook:

# Install Husky v6
npm install husky --save-dev
# or
yarn add husky --dev

# Activate hooks
npx husky install
# or
yarn husky install

Add hook

cat <<EEE > .husky/commit-msg
#!/bin/sh
. "\$(dirname "\$0")/_/husky.sh"

npx --no -- commitlint --edit "\${1}"
EEE

Make hook executable

chmod a+x .husky/commit-msg

Check the husky documentation on how you can automatically have Git hooks enabled after install for different yarn versions.

Detailed Setup instructions

CLI

  • Primary way to interact with commitlint.
  • npm install --save-dev @commitlint/cli
  • Packages: cli

Config

  • Configuration is picked up from:
    • .commitlintrc
    • .commitlintrc.json
    • .commitlintrc.yaml
    • .commitlintrc.yml
    • .commitlintrc.js
    • .commitlintrc.cjs
    • .commitlintrc.ts
    • commitlint.config.js
    • commitlint.config.cjs
    • commitlint.config.ts
    • commitlint field in package.json
  • Packages: cli, core
  • See Rules for a complete list of possible rules
  • An example configuration can be found at @commitlint/config-conventional

Shared configuration

A number of shared configurations are available to install and use with commitlint:

⚠️ If you want to publish your own shareable config then make sure it has a name aligning with the pattern commitlint-config-emoji-log or commitlint-config-your-config-name — then in extend all you have to write is emoji-log or your-config-name.

API

  • Alternative, programmatic way to interact with commitlint
  • Packages:
    • format - Format commitlint reports
    • lint - Lint a string against commitlint rules
    • load - Load shared commitlint configuration
    • read - Read commit messages from a specified range or last edit
  • See API for a complete list of methods and examples

Tools

Roadmap

Ideas: conventional-changelog/commitlint#94

commitlint is considered stable and is used in various projects as development tool.

We identify ease of adoption and developer experience as fields where there is room and need for improvement. The items on the roadmap should enhance commitlint regarding those aspects.

Version Support and Releases

  • Node.js LTS >= 14
  • git >= 2.13.2

Releases

Security patches will be applied to versions which are not yet EOL.
Features will only be applied to the current main version.

ReleaseInital releaseEnd-of-life
v1716.05.202216.05.2023
v1626.12.202126.12.2022
v1517.11.202117.11.2022
v1426.10.202126.10.2022
v1324.05.202124.05.2022
v1223.02.202123.02.2022
v1113.09.202013.09.2020

Dates are subject to change.

We're not a sponsored OSS project. Therefore we can't promise that we will release patch versions for older releases in a timely manner.
If you are stuck on an older version and need a security patch we're happy if you can provide a PR.

Related projects

License

Copyright by @marionebl. All commitlint packages are released under the MIT license.

Development

commitlint is developed in a mono repository.

Install and run

git clone git@github.com:conventional-changelog/commitlint.git
cd commitlint
yarn
yarn run build # run build tasks
yarn start # run tests, again on change

For more information on how to contribute please take a look at our contribution guide.

Package dependency overview

commitlint-dependencies

(Partly outdated)

Publishing a release

npm login
nvm use (if you have nvm installed)
yarn clean
yarn install
yarn build
yarn test
yarn run publish --otp <one-time password>

Create Github release

  1. Copy changelog entry for the new version
  2. Create release for the new tag: https://github.com/conventional-changelog/commitlint/releases
  3. Post in the commitlint Slack-channel

Publish a next release (or i.e. patch release)

npm login
nvm use (if you have nvm installed)
yarn clean
yarn install
yarn build
yarn test
npx lerna publish --conventional-commits --dist-tag [`next` | `[PATCH_RELEASE_VERSION]`] --otp <one-time password>

If for some reason this stops in between, you can manually publish missing packages like this:

npm publish <package-name> --tag [`next` | `[PATCH_RELEASE_VERSION]`] --otp <one-time password>

Publishing (new) packages for the first time

npm publish [PACKAGE_NAME] --access public

For alias packages you need to add @alias/. Like we already do with @commitlint/ anyways. This is just a reminder to make sure we do not forget this.

Move next to latest

npm login
npx lerna exec --no-bail --no-private --no-sort --stream -- '[ -n "$(npm v . dist-tags.next)" ] && npm dist-tag add ${LERNA_PACKAGE_NAME}@$(npm v . dist-tags.next) latest --otp <one-time password>'

Remove next:

npx lerna exec --no-bail --no-private --no-sort --stream -- '[ -n "$(npm v . dist-tags.next)" ] && npm dist-tag rm ${LERNA_PACKAGE_NAME} next --otp <one-time password>'

Author: conventional-changelog
Source Code: https://github.com/conventional-changelog/commitlint 
License: MIT license

#node #lint #git 

Commitlint: Lint Commit Messages

Woke: Detect Non-inclusive Language in Your Source Code

Detect non-inclusive language in your source code.

I stay woke - Erykah Badu  


Creating an inclusive work environment is imperative to a healthy, supportive, and productive culture, and an environment where everyone feels welcome and included.

woke is a text file analysis tool that finds places within your source code that contain non-inclusive language and suggests replacing them with more inclusive alternatives.

Companies like GitHub, Twitter, and Apple are actively supporting a move to inclusive language.

woke.gif

Why is this named woke?

When I started writing woke in August 2020, my goal was to build a tool that would shed light on non-inclusive language in source code and that would enable a long-term commitment to using inclusive language.

woke is a reference to an awareness of social and political issues, especially racial prejudice and discrimination, and has a historic use within the African-American community. This tool aims to push this kind of awareness even further into the software development community.

I named this project woke because I saw it as a tool to awaken our code to non-inclusive language.

You can read more about the origins and history of the word on Wikipedia.

Install woke

Documentation

Documentation is hosted at https://docs.getwoke.tech.

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

GitHub contributors

Author: Get-woke
Source Code: https://github.com/get-woke/woke 
License: MIT license

#go #golang #lint 

Woke: Detect Non-inclusive Language in Your Source Code

Dependency-check: Checks Which Modules You Have Used in Your Code

dependency-check

checks which modules you have used in your code and then makes sure they are listed as dependencies in your package.json, or vice-versa

requirements for maintained majors

If used on an older Node.js version dependency-check will fail silently rather than crashing your tests.

  • 5.x supports Node.js 14 and later
  • 4.x supports Node.js 10 and later
  • 3.x supports Node.js 6 and later
  • 2.x supports Node.js 0.10 and later (Dev note: published using the legacy tag)

For more info on maintenance status, see SECURITY.md.

how it works

dependency-check parses your module code starting from the default entry files (e.g. index.js or main and any bin commands defined in package.json or if specific files has been defined, then those) and traverses through all relatively required JS files, ultimately producing a list of non-relative modules

  • relative - e.g. require('./a-relative-file.js'), if one of these are encountered the required file will be recursively parsed by the dependency-check algorithm
  • non-relative - e.g. require('a-module'), if one of these are encountered it will get added to the list of dependencies, but sub-dependencies of the module will not get recursively parsed

the goal of this module is to simply check that all non-relative modules that get require()'d are in package.json, which prevents people from getting 'module not found' errors when they install your module that has missing deps which was accidentally published to NPM (happened to me all the time, hence the impetus to write this module).

cli usage

$ npm install dependency-check -g
$ dependency-check <path to module file(s), package.json or module folder>

# e.g.

$ dependency-check ./package.json --verbose
Success! All dependencies used in the code are listed in package.json
Success! All dependencies in package.json are used in the code
$ dependency-check ./package.json --missing --verbose
Success! All dependencies used in the code are listed in package.json
$ dependency-check ./package.json --unused --verbose
Success! All dependencies in package.json are used in the code

# or with file input instead:

$ dependency-check ./index.js

# even with globs and multiple inputs:

$ dependency-check ./test/**/*.js ./lib/*.js

dependency-check exits with code 1 if there are discrepancies, in addition to printing them out

To always exit with code 0 pass --ignore

--missing

running dependency-check ./package.json --missing will only do the check to make sure that all modules in your code are listed in your package.json

--unused

running dependency-check ./package.json --unused will only do the inverse of the missing check and will tell you which modules in your package.json dependencies were not used in your code

--no-dev

running dependency-check ./package.json --unused --no-dev will not tell you if any devDependencies in your package.json were missing or unused

--no-peer

running dependency-check ./package.json --unused --no-peer will not tell you if any peerDependencies in your package.json were missing or unused

--ignore-module, -i

ignores a module. This works for both --unused and --missing. You can specify as many separate --ignore-module arguments as you want. For example running dependency-check ./package.json --unused --ignore-module foo will not tell you if the foo module was not used in your code. Supports globbing patterns through the use of micromatch, so eg. --ignore-module "@types/*" is possible

--ignore-unknown-extensions, -u

won't fail when finding imported files with file extensions that no detectives has been registered for

--no-default-entries

running eg. dependency-check package.json tests.js --no-default-entries won't add any default entries despite the main path given being one to a package.json or module folder. So only the tests.js file will be checked

--extensions, -e

running dependency-check ./package.json -e js,cjs:detective will resolve require paths to .js and .cjs paths, and parse using detective. Specifying any extension will disable the default detectives. Specify just -e js,cjs to use the standard detective, -e foo:: to use ignore the extension, -e js:precinct/es6 to specify a specific precinct setting

--detective

running dependency-check ./package.json --detective detective will require() the local detective as the default parser. This can be set per-extension using using -e. Defaults to parsing with precinct.

--json, -j

formats the output as a json object

--verbose

running with --verbose will enable a log message on success, otherwise dependency-check only logs on failure.

--help

shows above options and all other available options

auto check before every npm publish

add this to your .bash_profile/.bashrc

# originally from https://gist.github.com/mafintosh/405048d304fbabb830b2
npm () {
  ([ "$1" != "publish" ] || dependency-check .) && command npm "$@"
}

now when you do npm publish and you have missing dependencies it won't publish, e.g.:

$ npm publish
Fail! Dependencies not listed in package.json: siblings
$ npm install --save siblings
$ npm publish # works this time

grunt usage

See grunt-dependency-check.

protips

  • detective-style packages are used for parsing require() statements, which means it only does static requires. this means you should convert things like var foo = "bar"; require(foo) to be static, e.g. require("bar")
  • use globbing to effectively add all the files you want to check

Author: Dependency-check-team
Source Code: https://github.com/dependency-check-team/dependency-check 
License: 

#javascript #lint #npm #node 

Dependency-check: Checks Which Modules You Have Used in Your Code
Annie  Emard

Annie Emard

1653086640

Slim Lint: Configurable Tool For Analyzing Slim Templates

Slim-Lint

slim-lint is a tool to help keep your Slim files clean and readable. In addition to style and lint checks, it integrates with RuboCop to bring its powerful static analysis tools to your Slim templates.

You can run slim-lint manually from the command line, or integrate it into your SCM hooks.

Requirements

  • Ruby 2.4+
  • Slim 3.0+

Installation

gem install slim_lint

Usage

Run slim-lint from the command line by passing in a directory (or multiple directories) to recursively scan:

slim-lint app/views/

You can also specify a list of files explicitly:

slim-lint app/**/*.slim

slim-lint will output any problems with your Slim, including the offending filename and line number.

Command Line FlagDescription
-c/--configSpecify which configuration file to use
-e/--excludeExclude one or more files from being linted
-i/--include-linterSpecify which linters you specifically want to run
-x/--exclude-linterSpecify which linters you don't want to run
--stdin-file-path [file]Pipe source from STDIN, using file in offense reports
--[no-]colorWhether to output in color
--reporter [reporter]Specify which output formatter to use
--show-lintersShow all registered linters
--show-reportersShow all available reporters
-h/--helpShow command line flag documentation
-v/--versionShow version
-V/--verbose-versionShow detailed version information

Configuration

slim-lint will automatically recognize and load any file with the name .slim-lint.yml as a configuration file. It loads the configuration based on the directory slim-lint is being run from, ascending until a configuration file is found. Any configuration loaded is automatically merged with the default configuration (see config/default.yml).

Here's an example configuration file:

exclude:
  - 'exclude/files/in/this/directory/from/all/linters/**/*.slim'

linters:
  EmptyControlStatement:
    exclude:
      - 'app/views/directory_of_files_to_exclude/**/*.slim'
      - 'specific/file/to/exclude.slim'

  LineLength:
    include: 'specific/directory/to/include/**/*.slim'
    max: 100

  RedundantDiv:
    enabled: false

All linters have an enabled option which can be true or false, which controls whether the linter is run, along with linter-specific options. The defaults are defined in config/default.yml.

Linter Options

OptionDescription
enabledIf false, this linter will never be run. This takes precedence over any other option.
includeList of files or glob patterns to scope this linter to. This narrows down any files specified via the command line.
excludeList of files or glob patterns to exclude from this linter. This excludes any files specified via the command line or already filtered via the include option.

Global File Exclusion

The exclude global configuration option allows you to specify a list of files or glob patterns to exclude from all linters. This is useful for ignoring third-party code that you don't maintain or care to lint. You can specify a single string or a list of strings for this option.

Skipping Frontmatter

Some static blog generators such as Jekyll include leading frontmatter to the template for their own tracking purposes. slim-lint allows you to ignore these headers by specifying the skip_frontmatter option in your .slim-lint.yml configuration:

skip_frontmatter: true

Disabling Linters For Specific Code

Slim-lint linters

To disable a slim-lint linter, you can use a slim comment:

/ slim-lint:disable TagCase
IMG src="images/cat.gif"
/ slim-lint:enable TagCase

Rubocop cops

To disable Rubocop cop, you can use a coment control statement:

- # rubocop:disable Rails/OutputSafety
p = raw(@blog.content)
- # rubocop:enable Rails/OutputSafety

Linters

You can find detailed documentation on all supported linters by following the link below:

» Linters Documentation

Editor Integration

Sublime Text

Install the Sublime slim-lint plugin.

Emacs

If you use Flycheck, support for slim-lint is included as of version 20160718.215 installed from MELPA.

Atom

Install the linter-slim-lint plugin by running apm install linter-slim-lint.

Visual Studio Code

Install the VS Code slim-lint plugin.

Git Integration

If you'd like to integrate slim-lint into your Git workflow, check out overcommit, a powerful and flexible Git hook manager.

Rake Integration

To execute slim-lint via a Rake task, make sure you have rake included in your gem path (e.g. via Gemfile), and add the following to your Rakefile:

require 'slim_lint/rake_task'

SlimLint::RakeTask.new

By default, when you execute rake slim_lint, the above configuration is equivalent to running slim-lint ., which will lint all .slim files in the current directory and its descendants.

You can customize your task by writing:

require 'slim_lint/rake_task'

SlimLint::RakeTask.new do |t|
  t.config = 'custom/config.yml'
  t.files = ['app/views', 'custom/*.slim']
  t.quiet = true # Don't display output from slim-lint to STDOUT
end

You can also use this custom configuration with a set of files specified via the command line:

# Single quotes prevent shell glob expansion
rake 'slim_lint[app/views, custom/*.slim]'

Files specified in this manner take precedence over the task's files attribute.

Documentation

Code documentation is generated with YARD and hosted by RubyDoc.info.

Contributing

We love getting feedback with or without pull requests. If you do add a new feature, please add tests so that we can avoid breaking it in the future.

Speaking of tests, we use rspec, which can be run by executing the following from the root directory of the repository:

bundle exec rspec

Changelog

If you're interested in seeing the changes and bug fixes between each version of slim-lint, read the Slim-Lint Changelog.

Author: sds
Source Code: https://github.com/sds/slim-lint
License: View license

#slim #lint 

Slim Lint: Configurable Tool For Analyzing Slim Templates
Annie  Emard

Annie Emard

1653075360

HAML Lint: Tool For Writing Clean and Consistent HAML

HAML-Lint

haml-lint is a tool to help keep your HAML files clean and readable. In addition to HAML-specific style and lint checks, it integrates with RuboCop to bring its powerful static analysis tools to your HAML documents.

You can run haml-lint manually from the command line, or integrate it into your SCM hooks.

Requirements

  • Ruby 2.4+
  • HAML 4.0+

Installation

gem install haml_lint

If you'd rather install haml-lint using bundler, don't require it in your Gemfile:

gem 'haml_lint', require: false

Then you can still use haml-lint from the command line, but its source code won't be auto-loaded inside your application.

Usage

Run haml-lint from the command line by passing in a directory (or multiple directories) to recursively scan:

haml-lint app/views/

You can also specify a list of files explicitly:

haml-lint app/**/*.html.haml

haml-lint will output any problems with your HAML, including the offending filename and line number.

File Encoding

haml-lint assumes all files are encoded in UTF-8.

Command Line Flags

Command Line FlagDescription
--auto-gen-configGenerate a configuration file acting as a TODO list
--auto-gen-exclude-limitNumber of failures to allow in the TODO list before the entire rule is excluded
-c/--configSpecify which configuration file to use
-e/--excludeExclude one or more files from being linted
-i/--include-linterSpecify which linters you specifically want to run
-x/--exclude-linterSpecify which linters you don't want to run
-r/--reporterSpecify which reporter you want to use to generate the output
-p/--parallelRun linters in parallel using available CPUs
--fail-fastSpecify whether to fail after the first file with lint
--fail-levelSpecify the minimum severity (warning or error) for which the lint should fail
--[no-]colorWhether to output in color
--[no-]summaryWhether to output a summary in the default reporter
--show-lintersShow all registered linters
--show-reportersDisplay available reporters
-h/--helpShow command line flag documentation
-v/--versionShow haml-lint version
-V/--verbose-versionShow haml-lint, haml, and ruby version information

Configuration

haml-lint will automatically recognize and load any file with the name .haml-lint.yml as a configuration file. It loads the configuration based on the directory haml-lint is being run from, ascending until a configuration file is found. Any configuration loaded is automatically merged with the default configuration (see config/default.yml).

Here's an example configuration file:

linters:
  ImplicitDiv:
    enabled: false
    severity: error

  LineLength:
    max: 100

All linters have an enabled option which can be true or false, which controls whether the linter is run, along with linter-specific options. The defaults are defined in config/default.yml.

Linter Options

OptionDescription
enabledIf false, this linter will never be run. This takes precedence over any other option.
includeList of files or glob patterns to scope this linter to. This narrows down any files specified via the command line.
excludeList of files or glob patterns to exclude from this linter. This excludes any files specified via the command line or already filtered via the include option.
severityThe severity of the linter. External tools consuming haml-lint output can use this to determine whether to warn or error based on the lints reported.

Global File Exclusion

The exclude global configuration option allows you to specify a list of files or glob patterns to exclude from all linters. This is useful for ignoring third-party code that you don't maintain or care to lint. You can specify a single string or a list of strings for this option.

Skipping Frontmatter

Some static blog generators such as Jekyll include leading frontmatter to the template for their own tracking purposes. haml-lint allows you to ignore these headers by specifying the skip_frontmatter option in your .haml-lint.yml configuration:

skip_frontmatter: true

Inheriting from Other Configuration Files

The inherits_from global configuration option allows you to specify an inheritance chain for a configuration file. It accepts either a scalar value of a single file name or a vector of multiple files to inherit from. The inherited files are resolved in a first in, first out order and with "last one wins" precedence. For example:

inherits_from:
  - .shared_haml-lint.yml
  - .personal_haml-lint.yml

First, the default configuration is loaded. Then the .shared_haml-lint.yml configuration is loaded, followed by .personal_haml-lint.yml. Each of these overwrite each other in the event of a collision in configuration value. Once the inheritance chain is resolved, the base configuration is loaded and applies its rules to overwrite any in the intermediate configuration.

Lastly, in order to match your RuboCop configuration style, you can also use the inherit_from directive, which is an alias for inherits_from.

Linters

» Linters Documentation

haml-lint is an opinionated tool that helps you enforce a consistent style in your HAML files. As an opinionated tool, we've had to make calls about what we think are the "best" style conventions, even when there are often reasonable arguments for more than one possible style. While all of our choices have a rational basis, we think that the opinions themselves are less important than the fact that haml-lint provides us with an automated and low-cost means of enforcing consistency.

Custom Linters

Add the following to your configuration file:

require:
  - './relative/path/to/my_first_linter.rb'
  - 'absolute/path/to/my_second_linter.rb'

The files that are referenced by this config should have the following structure:

module HamlLint
  # MyFirstLinter is the name of the linter in this example, but it can be anything
  class Linter::MyFirstLinter < Linter
    include LinterRegistry

    def visit_tag
      return unless node.tag_name == 'div'
      record_lint(node, "You're not allowed divs!")
    end
  end
end

For more information on the different types on HAML node, please look through the HAML parser code: https://github.com/haml/haml/blob/master/lib/haml/parser.rb

Keep in mind that by default your linter will be disabled by default. So you will need to enable it in your configuration file to have it run.

Disabling Linters within Source Code

One or more individual linters can be disabled locally in a file by adding a directive comment. These comments look like the following:

-# haml-lint:disable AltText, LineLength
[...]
-# haml-lint:enable AltText, LineLength

You can disable all linters for a section with the following:

-# haml-lint:disable all

Directive Scope

A directive will disable the given linters for the scope of the block. This scope is inherited by child elements and sibling elements that come after the comment. For example:

-# haml-lint:disable AltText
#content
  %img#will-not-show-lint-1{ src: "will-not-show-lint-1.png" }
  -# haml-lint:enable AltText
  %img#will-show-lint-1{ src: "will-show-lint-1.png" }
  .sidebar
    %img#will-show-lint-2{ src: "will-show-lint-2.png" }
%img#will-not-show-lint-2{ src: "will-not-show-lint-2.png" }

The #will-not-show-lint-1 image on line 2 will not raise an AltText lint because of the directive on line 1. Since that directive is at the top level of the tree, it applies everywhere.

However, on line 4, the directive enables the AltText linter for the remainder of the #content element's content. This means that the #will-show-lint-1 image on line 5 will raise an AltText lint because it is a sibling of the enabling directive that appears later in the #content element. Likewise, the #will-show-lint-2 image on line 7 will raise an AltText lint because it is a child of a sibling of the enabling directive.

Lastly, the #will-not-show-lint-2 image on line 8 will not raise an AltText lint because the enabling directive on line 4 exists in a separate element and is not a sibling of the it.

Directive Precedence

If there are multiple directives for the same linter in an element, the last directive wins. For example:

-# haml-lint:enable AltText
%p Hello, world!
-# haml-lint:disable AltText
%img#will-not-show-lint{ src: "will-not-show-lint.png" }

There are two conflicting directives for the AltText linter. The first one enables it, but the second one disables it. Since the disable directive came later, the #will-not-show-lint element will not raise an AltText lint.

You can use this functionality to selectively enable directives within a file by first using the haml-lint:disable all directive to disable all linters in the file, then selectively using haml-lint:enable to enable linters one at a time.

Onboarding Onto a Preexisting Project

Adding a new linter into a project that wasn't previously using one can be a daunting task. To help ease the pain of starting to use Haml-Lint, you can generate a configuration file that will exclude all linters from reporting lint in files that currently have lint. This gives you something similar to a to-do list where the violations that you had when you started using Haml-Lint are listed for you to whittle away, but ensuring that any views you create going forward are properly linted.

To use this functionality, call Haml-Lint like:

haml-lint --auto-gen-config

This will generate a .haml-lint_todo.yml file that contains all existing lint as exclusions. You can then add inherits_from: .haml-lint_todo.yml to your .haml-lint.yml configuration file to ensure these exclusions are used whenever you call haml-lint.

By default, any rules with more than 15 violations will be disabled in the todo-file. You can increase this limit with the auto-gen-exclude-limit option:

haml-lint --auto-gen-config --auto-gen-exclude-limit 100

Editor Integration

Vim

If you use vim, you can have haml-lint automatically run against your HAML files after saving by using the Syntastic plugin. If you already have the plugin, just add let g:syntastic_haml_checkers = ['haml_lint'] to your .vimrc.

Vim 8 / Neovim

If you use vim 8+ or Neovim, you can have haml-lint automatically run against your HAML files as you type by using the Asynchronous Lint Engine (ALE) plugin. ALE will automatically lint your HAML files if it detects haml-lint in your PATH.

Sublime Text 3

If you use SublimeLinter 3 with Sublime Text 3 you can install the SublimeLinter-haml-lint plugin using Package Control.

Atom

If you use atom, you can install the linter-haml plugin.

TextMate 2

If you use TextMate 2, you can install the Haml-Lint.tmbundle bundle.

Visual Studio Code

If you use Visual Studio Code, you can install the Haml Lint extension

Git Integration

If you'd like to integrate haml-lint into your Git workflow, check out our Git hook manager, overcommit.

Rake Integration

To execute haml-lint via a Rake task, make sure you have rake included in your gem path (e.g. via Gemfile) add the following to your Rakefile:

require 'haml_lint/rake_task'

HamlLint::RakeTask.new

By default, when you execute rake haml_lint, the above configuration is equivalent to running haml-lint ., which will lint all .haml files in the current directory and its descendants.

You can customize your task by writing:

require 'haml_lint/rake_task'

HamlLint::RakeTask.new do |t|
  t.config = 'custom/config.yml'
  t.files = ['app/views', 'custom/*.haml']
  t.quiet = true # Don't display output from haml-lint to STDOUT
end

You can also use this custom configuration with a set of files specified via the command line:

# Single quotes prevent shell glob expansion
rake 'haml_lint[app/views, custom/*.haml]'

Files specified in this manner take precedence over the task's files attribute.

Documentation

Code documentation is generated with YARD and hosted by RubyDoc.info.

Contributing

We love getting feedback with or without pull requests. If you do add a new feature, please add tests so that we can avoid breaking it in the future.

Speaking of tests, we use Appraisal to test against both HAML 4 and 5. We use rspec to write our tests. To run the test suite, execute the following from the root directory of the repository:

appraisal bundle install
appraisal bundle exec rspec

Community

All major discussion surrounding HAML-Lint happens on the GitHub issues page.

Changelog

If you're interested in seeing the changes and bug fixes between each version of haml-lint, read the HAML-Lint Changelog.

Author: sds
Source Code: https://github.com/sds/haml-lint
License: MIT license

#haml #lint 

HAML Lint: Tool For Writing Clean and Consistent HAML
Annie  Emard

Annie Emard

1652911080

MarkdownLint: A Tool To Check Markdown Files and Flag Style Issues

Markdown lint tool

A tool to check markdown files and flag style issues.

Installation

Markdownlint is written in ruby and is distributed as a rubygem. As long as you have a relatively up to date ruby on your system, markdownlint will be simple to install and use. You have 2 options to install it:

To install from rubygems, run:

gem install mdl

To install the latest development version from github:

git clone https://github.com/markdownlint/markdownlint
cd markdownlint
rake install

Note that you will need rake (gem install rake) and bundler (gem install bundler) in order to build from source.

Usage

To have markdownlint check your markdown files, simply run mdl with the filenames as a parameter:

mdl README.md

Markdownlint can also take a directory, and it will scan all markdown files within the directory (and nested directories):

mdl docs/

If you don't specify a filename, markdownlint will use stdin:

cat foo.md | mdl

Markdownlint will output a list of issues it finds, and the line number where the issue is. See RULES.md for information on each issue, as well as how to correct it:

README.md:1: MD013 Line length
README.md:70: MD029 Ordered list item prefix
README.md:71: MD029 Ordered list item prefix
README.md:72: MD029 Ordered list item prefix
README.md:73: MD029 Ordered list item prefix

Markdownlint has many more options you can pass on the command line, run mdl --help to see what they are, or see the documentation on configuring markdownlint.

Styles

Not everyone writes markdown in the same way, and there are multiple flavors and styles, each of which are valid. While markdownlint's default settings will result in markdown files that reflect the author's preferred markdown authoring preferences, your project may have different guidelines.

It's not markdownlint's intention to dictate any one specific style, and in order to support these differing styles and/or preferences, markdownlint supports what are called 'style files'. A style file is a file describing which rules markdownlint should enable, and also what settings to apply to individual rules. For example, rule MD013 checks for long lines, and by default will report an issue for any line longer than 80 characters. If your project has a different maximum line length limit, or if you don't want to enforce a line limit at all, then this can be configured in a style file.

For more information on creating style files, see the creating styles document.

Related projects

Contributing

See CONTRIBUTING.md for more information.

Author: markdownlint
Source Code: https://github.com/markdownlint/markdownlint
License: MIT License

#markdown #lint 

MarkdownLint: A Tool To Check Markdown Files and Flag Style Issues
Annie  Emard

Annie Emard

1652660940

Check That Your Puppet Manifests Conform to The Style Guide

Puppet Lint

Note that as of release 2.5.0, this project is being maintained in the main puppetlabs namespace.

Puppet Lint tests Puppet code against the recommended Puppet language style guide. Puppet Lint validates only code style; it does not validate syntax. To test syntax, use Puppet's puppet parser validate command.

Compatibility warning

Puppet Lint version 2 is the last planned version with support for Puppet 3 and Ruby 1.8.7. The next major version of Puppet Lint will drop support for these versions.

Installation

Install the Puppet Lint gem by running:

gem install puppet-lint

Testing with Puppet Lint

To test manifests for correct Puppet style, run the puppet-lint command with the path to the files you want to test.

For example:

puppet-lint ~/modules/puppetlabs-java/manifests/init.pp
puppet-lint ~/modules/puppetlabs-mysql/manifests

Fix issues automatically

To instruct Lint to automatically fix any issues that it detects, use the --fix flag:

puppet-lint --fix /modules

Modify which checks to run

Puppet Lint options allow you to modify which checks to run. You can disable any of the checks temporarily or permanently, or you can limit testing to specific checks.

List all available checks

To list all available checks along with basic usage documentation, use the --list-checks option.

Run specific checks

To run only specific checks, use the --only-checks option, with a comma-separated list of arguments specifying which checks to make:

puppet-lint --only-checks trailing_whitespace,140chars modules/

To avoid enormous patch sets when using the --fix flag, use the --only-checks option to limit which checks Puppet Lint makes:

puppet-lint --only-checks trailing_whitespace --fix modules/

Disable Lint checks

You can disable specific Lint checks on the command line, disable them permanently with a configuration file, or disable them with control comments within your Puppet code.

Disable checks on the command line

To disable any of the checks when running the puppet-lint command, add a --no-<check_name>-check flag to the command. For example, to skip the 140-character check, run:

puppet-lint --no-140chars-check modules/

Disable checks within Puppet code

To disable checks from within your Puppet code itself, use control comments. Disable checks on either a per-line or per-block basis using #lint:ignore:<check_name>.

For example:

class foo {
  $bar = 'bar'

  # This ignores the double_quoted_strings check over multiple lines

  # lint:ignore:double_quoted_strings
  $baz = "baz"
  $gronk = "gronk"
  # lint:endignore

  # This ignores the 140chars check on a single line

  $this_line_has_a_really_long_name_and_value_that_is_much_longer_than_the_style_guide_recommends = "I mean, a really, really long line like you can't believe" # lint:ignore:140chars
}

Configuration file

Each time Puppet Lint starts up, it loads configuration from three files in order:

  1. /etc/puppet-lint.rc
  2. ~/.puppet-lint.rc
  3. .puppet-lint.rc

This means that a flag in the local .puppet-lint.rc will take precedence over a flag in the global /etc/puppet-lint.rc, for example. Flags specified on the command line take final precedence and override all config file options.

Any flag that can be specified on the command line can also be specified in the configuration file. For example, to always skip the hard tab character check, create ~/.puppet-lint.rc and include the line:

--no-hard_tabs-check

Or to specify a whitelist of allowed checks, include a line like:

--only-checks=trailing_whitespace,hard_tabs,duplicate_params,double_quoted_strings,unquoted_file_mode,only_variable_string,variables_not_enclosed,single_quote_string_with_variables,variable_contains_dash,ensure_not_symlink_target,unquoted_resource_title,relative_classname_inclusion,file_mode,resource_reference_without_title_capital,leading_zero,arrow_alignment,variable_is_lowercase,ensure_first_param,resource_reference_without_whitespace,file_ensure,trailing_comma,leading_zero

Please note that there is an important difference between reading options from the command line and reading options from a configuration file: In the former case the shell interprets one level of quotes. That does not happen in the latter case. So, it would make sense to quote some configuration values on the command line, like so:

$ puppet-lint --ignore-paths 'modules/stdlib/*' modules/

When reading from a configuration file those quotes would be passed on to the option parser -- probably not giving the expected result. Instead the line should read

--ignore-paths=modules/stdlib/*

Testing with Puppet Lint as a Rake task

To test your entire Puppet manifest directory, add require 'puppet-lint/tasks/puppet-lint' to your Rakefile and then run:

rake lint

To modify the default behaviour of the Rake task, modify the Puppet Lint configuration by defining the task yourself. For example:

PuppetLint::RakeTask.new :lint do |config|  # Pattern of files to check, defaults to `**/*.pp`  config.pattern = 'modules'  # Pattern of files to ignore  config.ignore_paths = ['modules/apt', 'modules/stdlib']  # List of checks to disable  config.disable_checks = ['documentation', '140chars']  # Should puppet-lint prefix it's output with the file being checked,  # defaults to true  config.with_filename = false  # Should the task fail if there were any warnings, defaults to false  config.fail_on_warnings = true  # Format string for puppet-lint's output (see the puppet-lint help output  # for details  config.log_format = '%{filename} - %{message}'  # Print out the context for the problem, defaults to false  config.with_context = true  # Enable automatic fixing of problems, defaults to false  config.fix = true  # Show ignored problems in the output, defaults to false  config.show_ignored = true  # Compare module layout relative to the module root  config.relative = true end

Disable checks in the Lint Rake task

You can also disable checks when running Puppet Lint through the supplied Rake task by modifying your Rakefile.

To disable a check, add the following line after the require statement in your Rakefile:

PuppetLint.configuration.send("disable_<check name>")

For example, to disable the 140-character check, add:

PuppetLint.configuration.send("disable_140chars")

To set the Lint Rake task to ignore certain paths:

PuppetLint.configuration.ignore_paths = ["vendor/**/*.pp"]

To set a pattern of files that Lint should check:

# Defaults to `**/*.pp`
PuppetLint.configuration.pattern = "modules"

Testing with Puppet Lint as a GitHub Action

There is a GitHub Actions action available to get linter feedback in workflows:

Options

See puppet-lint --help for a full list of command line options and checks.

Checks

For a complete list of checks, and how to resolve errors on each check, see the Puppet Lint checks page.

Spacing, Indentation, and Whitespace

  • Must use two-space soft tabs.
  • Must not use literal tab characters.
  • Must not contain trailing white space.
  • Should not exceed an 140-character line width.
    • An exception has been made for source => 'puppet://...' lines as splitting these over multiple lines decreases the readability of the manifests.
  • Should align arrows (=>) within blocks of attributes.

Quoting

  • All strings that do not contain variables should be enclosed in single quotes.
    • An exception has been made for double-quoted strings containing \n or \t.
  • All strings that contain variables must be enclosed in double quotes.
  • All variables should be enclosed in braces when interpolated in a string.
  • Variables standing by themselves should not be quoted.

Capitalization

  • All variables should be in lowercase.

Resources

  • All resource titles should be quoted.
    • An exception has been made for resource titles that consist of only a variable standing by itself.
  • If a resource declaration includes an ensure attribute, it should be the first attribute specified.
  • Symbolic links should be declared by using an ensure value of link and explicitly specifying a value for the target attribute.
  • File modes should be represented as a 4-digit string enclosed in single quotes or use symbolic file modes.

Conditionals

  • You should not intermingle conditionals inside resource declarations (that is, selectors inside resources).
  • Case statements should have a default case.

Classes

  • Relationship declarations with the chaining syntax should only be used in the 'left to right' direction.
  • Classes should not be defined inside a class.
  • Defines should not be defined inside a class.
  • Classes should not inherit between namespaces.
  • Required parameters in class & defined type definitions should be listed before optional parameters.
  • When using top-scope variables, including facts, Puppet modules should explicitly specify the empty namespace.
  • Chaining operators should appear on the same line as the right hand operand.

Reporting bugs or incorrect results

If you find a bug in Puppet Lint or its results, please create an issue in the repo issues tracker. Bonus points will be awarded if you also include a patch that fixes the issue.

Thank you

Many thanks to the following people for contributing to puppet-lint

  • James Turnbull (@kartar)
  • Jan Vansteenkiste (@vStone)
  • Julian Simpson (@simpsonjulian)
  • S. Zachariah Sprackett (@zsprackett)

As well as the many people who have reported the issues they've had!

License

Copyright (c) 2011-2016 Tim Sharpe

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Author: rodjek
Source Code: https://github.com/rodjek/puppet-lint
License: MIT License

#puppet #lint 

Check That Your Puppet Manifests Conform to The Style Guide
Annie  Emard

Annie Emard

1652649180

Tool To Check The Validity Of Puppet Metadata.json Files

metadata-json-lint

The metadata-json-lint tool validates and lints metadata.json files in Puppet modules against style guidelines from the Puppet Forge module metadata recommendations.

Compatibility

metadata-json-lint is compatible with Ruby versions 2.0.0, 2.1.9, 2.3.1, and 2.4.1.

Installation

via gem command:

gem install metadata-json-lint

via Gemfile:

gem 'metadata-json-lint'

Usage

Testing with metadata-json-lint

On the command line, run metadata-json-lint with the path of your metadata.json file:

metadata-json-lint /path/to/metadata.json

Testing with metadata-json-lint as a Rake task

If you are already using puppet_spec_helper, the 'validate' task already includes metadata-json-lint.

You can also integrate metadata-json-lint checks into your tests using the Rake task. Add require 'metadata-json-lint/rake_task' to your Rakefile, and then run:

rake metadata_lint

To set options for the Rake task, include them when you define the task:

require 'metadata_json_lint'
task :metadata_lint do
  MetadataJsonLint.parse('metadata.json') do |options|
      options.strict_license = false
  end
end

Alternatively, set the option after requiring the Rake task:

require 'metadata-json-lint/rake_task'
MetadataJsonLint.options.strict_license = false

Options

  • --[no-]strict-dependencies: Whether to fail if module version dependencies are open-ended. Defaults to false.
  • --[no-]strict-license: Whether to fail on strict license check. Defaults to true.
  • --[no-]fail-on-warnings: Whether to fail on warnings. Defaults to true.
  • --[no-]strict-puppet-version: Whether to fail if Puppet version requirements are open-ended or no longer supported. Defaults to false.

Contributors

A big thank you to the contributors.

Making a new release

How to make a new release?

  • update the gemspec file with the desired version
$ git diff
diff --git a/metadata-json-lint.gemspec b/metadata-json-lint.gemspec
index c86668e..6a3ad38 100644
--- a/metadata-json-lint.gemspec
+++ b/metadata-json-lint.gemspec
@@ -2,7 +2,7 @@ require 'date'

 Gem::Specification.new do |s|
   s.name        = 'metadata-json-lint'
-  s.version     = '2.4.0'
+  s.version     = '2.5.0'
   s.date        = Date.today.to_s
   s.summary     = 'metadata-json-lint /path/to/metadata.json'
   s.description = 'Utility to verify Puppet metadata.json files'
  • export a GitHub access token as environment variable:
export CHANGELOG_GITHUB_TOKEN=*token*
  • Install deps and generate the changelog
$ bundle install --path .vendor/ --jobs=$(nproc) --with release
$ bundle exec rake changelog
Found 25 tags
Fetching tags dates: 25/25
Sorting tags...
Received issues: 103
Pull Request count: 77
Filtered pull requests: 72
Filtered issues: 26
Fetching events for issues and PR: 98
Fetching closed dates for issues: 98/98
Fetching SHAs for tags: 25
Associating PRs with tags: 72/72
Generating entry...
Done!
Generated log placed in ~/metadata-json-lint/CHANGELOG.md

Check the diff for CHANGELOG.md. Does it contain a breaking change but the new version is only a minor bump? Does the new release only contains bug fixes? Adjust the version properly while honouring semantic versioning. If required, regenerate the CHANGELOG.md. Afterwards submit it as a PR.

If it gets approved, merge the PR, create a git tag on that and push it.

Author: voxpupuli
Source Code: https://github.com/voxpupuli/metadata-json-lint
License: Apache-2.0 License

#metadata #json #lint 

Tool To Check The Validity Of Puppet Metadata.json Files
Annie  Emard

Annie Emard

1652608800

A Linter for Kubernetes Resources with A Customizable Rule Set

kube-lint

A linter for Kubernetes resources with a customizable rule set.

Introduction

kube-lint hopes to make it easy to validate that your Kubernetes configuration files and your running resources adhere to a standard that you define. You define a list of rules that you would like to validate against your resources and kube-lint will evaluate those rules against them.

In many organizations you will want to have a standard for what is considered "correct" enough to be deployed into your Kubernetes clusters. You may have conventions for labels or restrictions on certain types of services being created. You can use kube-lint during your CI/CD pipeline to gate resources being created that do not adhere to your standards. Additionally you can use kube-lint to audit against a running set of resources in your cluster.

CONSIDER THIS A PROTOTYPE. PLEASE PROVIDE FEEDBACK IN THE ISSUES

Only Pod linting is currently implemented

Installation

  • Download a release from the releases page that matches your platform.
  • Extract the archive

For MacOS

wget https://github.com/viglesiasce/kube-lint/releases/download/v0.0.1-prototype/kube-lint-prototype-darwin.tgz
tar zxfv kube-lint-prototype-darwin.tgz
./darwin/kube-lint -h

For Linux

wget https://github.com/viglesiasce/kube-lint/releases/download/v0.0.1-prototype/kube-lint-prototype-linux.tgz
tar zxfv kube-lint-prototype-linux.tgz
./linux/kube-lint -h

Rule configuration

The rule configuration file is a YAML formatted list of KubernetesRules. An example config file is available at example/config.yaml in this repository.

A KubernetesRule has the following format:

name: app-label
description: Includes a label with key "app"
kind: Pod
field: .metadata.labels.app
operator: set
valueType: string
tags:
- operations
- security

name is an identifier for this rule.

description provides details about what the rule is checking for.

kind is the type of resource this check should be done against.

field is a jsonpath used to get the value you want to evaluate against.

operator is the check that youd like to do against your expected vs actual values (ie equal, matches, lessthan). For string type the available operators are equal, notequal, set, unset, matches. For bool type the available operators are equal, notequal, set, unset. For float64 type, the available operators are equal, notequal, set, unset, greaterthan, lessthan.

valueType is the type of the value that needs to be evaluated. string is the default. bool and float64 are also implemented.

tags is a list of strings that can be used to decide whether to run this rule or not via the CLI.

Running kube-lint

Basic operation

Once installed you can run kube-lint from this directory as follows:

kube-lint pods --config example/config.yaml

To change the rules edit example/config.yaml. You rulebender you.

Filtering rules by tag

You can evaluate a subset of rules by filtering down to only those that include certain tags. For example:

kube-lint pods --config example/config.yaml --tags security,operations

Filtering resources by namespace

You can also filter which resources are evaluated by passing the --namespace flag as follows:

kube-lint pods --config example/config.yaml --namespace kube-system

TODO if this seems like a reasonable approach to pursue

  • Replace panic everywhere with proper error handling
  • Add tests. Lots of tests.
  • Add docstrings to all exported functions/types/methods
  • Make -f be able to load a directories of yaml files (like kubectl)
  • Decide on how to deal with unset parameters
  • Choose a logging framework and use it
  • Add more resources (services/deployments/etc.)
  • Use ${HOME}/.kube-lint for config params
  • Develop standardized baseline of rules that are useful
  • Vendor dependencies using glide

Contributing

Add an issue to talk about what youd like to see changed. Lets talk about it then come up with a plan of action.

Author: viglesiasce
Source Code: https://github.com/viglesiasce/kube-lint
License: Apache-2.0 License

#lint #kubernetes 

A Linter for Kubernetes Resources with A Customizable Rule Set
Annie  Emard

Annie Emard

1652552040

CFN Lint: AWS CloudFormation Linter

AWS CloudFormation Linter

Validate AWS CloudFormation yaml/json templates against the AWS CloudFormation Resource Specification and additional checks. Includes checking valid values for resource properties and best practices.

Warning

This is an attempt to provide validation for AWS CloudFormation templates properties and their values. For values things can get pretty complicated (mappings, joins, splits, conditions, and nesting those functions inside each other) so it's a best effort to validate those values but the promise is to not fail if we can't understand or translate all the things that could be going on.

Serverless Application Model

The Serverless Application Model (SAM) is supported by the linter. The template is transformed using AWS SAM before the linter processes the template.

To get information about the SAM Transformation, run the linter with --info

Install

Python 2.7+ and 3.5+ are supported.

Pip

pip install cfn-lint. If pip is not available, run python setup.py clean --all then python setup.py install.

Homebrew (macOS)

brew install cfn-lint

Docker

In cfn-python-lint source tree:

docker build --tag cfn-python-lint:latest .

In repository to be linted:

docker run --rm -v `pwd`:/data cfn-python-lint:latest /data/template.yaml

Editor Plugins

There are IDE plugins available to get direct linter feedback from you favorite editor:

GitHub Action

Online demo

Basic Usage

  • cfn-lint template.yaml
  • cfn-lint -t template.yaml

Multiple files can be linted by either specifying multiple specific files:

  • cfn-lint template1.yaml template2.yaml
  • cfn-lint -t template1.yaml template2.yaml

or by using wildcards (globbing):

Lint all yaml files in path:

  • cfn-lint path/*.yaml

Lint all yaml files in path and all subdirectories (recursive):

  • cfn-lint path/**/*.yaml

Note: If using sh/bash/zsh, you must enable globbing. (setopt -s globstar for sh/bash, setopt extended_glob for zsh).

Exit Codes

cfn-lint will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error cfn-lint will use bitwise OR to determine the final exit code. This will result in these possibilities.

  • 0 is no issue was found
  • 2 is an error
  • 4 is a warning
  • 6 is an error and a warning
  • 8 is an informational
  • 10 is an error and informational
  • 12 is an warning and informational
  • 14 is an error and a warning and an informational

Specifying the template as an input stream

The template to be linted can also be passed using standard input:

  • cat path/template.yaml | cfn-lint -

Specifying the template with other parameters

  • cfn-lint -r us-east-1 ap-south-1 -- template.yaml
  • cfn-lint -r us-east-1 ap-south-1 -t template.yaml

Configuration

Command Line

From a command prompt run cfn-lint <path to template> to run standard linting of the template.

Config File

It will look for a configuration file in the following locations (by order of preference):

  • .cfnlintrc, .cfnlintrc.yaml or .cfnlintrc.yml in the current working directory
  • ~/.cfnlintrc for the home directory

In that file you can specify settings from the parameter section below.

Example:

templates:
  - test/fixtures/templates/good/**/*.yaml
ignore_templates:
  - codebuild.yaml
include_checks:
  - I
custom_rules: custom_rules.txt

Parameters

Optional parameters:

Command LineMetadataOptionsDescription
-h, --help  Get description of cfn-lint
-z, --custom-rules filenameText file containing user-defined custom rules. See here for more information
-t, --template filenameAlternative way to specify Template file path to the file that needs to be tested by cfn-lint
-f, --formatformatquiet, parseable, json, junit, pretty, sarifOutput format
-l, --list-rules  List all the rules
-r, --regionsregions[REGIONS [REGIONS ...]], ALL_REGIONSTest the template against many regions. Supported regions
-b, --ignore-bad-templateignore_bad_template Ignores bad template errors
--ignore-templates IGNORE_TEMPLATES [IGNORE_TEMPLATES ...]Ignore templates from being scanned
-a, --append-rulesappend_rules[RULESPATH [RULESPATH ...]]Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module.
-i, --ignore-checksignore_checks[IGNORE_CHECKS [IGNORE_CHECKS ...]]Only check rules whose ID do not match or prefix these values. Examples: 
- A value of W will disable all warnings
- W2 disables all Warnings for Parameter rules.
- W2001 will disable rule W2001
-e, --include-experimentalinclude_experimental Whether rules that still in an experimental state should be included in the checks
-c, --include-checks INCLUDE_CHECKS [INCLUDE_CHECKS ...]Include rules whose id match these values
-m, --mandatory-checks  Rules to check regardless of ignore configuration
-x, --configure-rule CONFIGURE_RULES [CONFIGURE_RULES ...]Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=false
-D, --debug  Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.
-I, --info  Specify to enable logging. Outputs additional information about the template processing.
-u, --update-specs  Update the CloudFormation Resource Specifications. You may need sudo to run this. You will need internet access when running this command
-o, --override-spec filenameSpec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info here
-g, --build-graph  Creates a file in the same directory as the template that models the template's resources in DOT format
-s, --registry-schemas  one or more directories of CloudFormation Registry Resource Schemas
-v, --version  Version of cfn-lint

Info Rules

To maintain backwards compatibility info rules are not included by default. To include these rules you will need to include -c I or --include-checks I

Metadata

Template Based Metadata

Inside the root level Metadata key you can configure cfn-lint using the supported parameters.

Metadata:
  cfn-lint:
    config:
      regions:
        - us-east-1
        - us-east-2
      ignore_checks:
        - E2530

Resource Based Metadata

Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that AWS::Serverless resources may lose metadata during the Serverless transform

Resources:
  myInstance:
    Type: AWS::EC2::Instance
    Metadata:
      cfn-lint:
        config:
          ignore_checks:
            - E3030
    Properties:
      InstanceType: nt.x4superlarge
      ImageId: ami-abc1234

Precedence

cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters

Configure Rules

Certain rules support configuration properties. You can configure these rules by using configure_rules parameter.

From the command line the format is RuleId:key=value, for example: E3012:strict=false. From the cfnlintrc or Metadata section the format is

Metadata:
  cfn-lint:
    config:
      configure_rules:
        RuleId:
          key: value

The configurable rules have a non-empty Config entry in the table here.

Getting Started Guides

There are getting started guides available in the documentation section to help with integrating cfn-lint or creating rules.

Rules

This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.

This collection of rules can be extended with custom rules using the --append-rules argument.

More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented here.

Custom Rules

The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:

<Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]

Example

A separate custom rule text file must be created.

The example below validates example_template.yml does not use any EC2 instances of size m4.16xlarge

custom_rule.txt

AWS::EC2::Instance InstanceSize NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"

example_template.yml

AWSTemplateFormatVersion: "2010-09-09"
Resources:
        myInstance:
                Type: AWS::EC2::Instance
                Properties:
                        InstanceType: m4.16xlarge
                        ImageId: ami-asdfef

The custom rule can be added to the configuration file or ran as a command line argument

The linter will produce the following output, running cfn-lint example_template.yml -z custom_rules.txt:

W9001  This is an expensive instance type, don't use it
mqtemplate.yml:6:17

More information describing how custom rules are setup and an overview of all operators available is documented here.

Customize specifications

The linter follows the AWS CloudFormation Resource Specifications by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use Tagging.

The linter provides the possibility to implement these customized specifications using the --override-spec argument.

More information about how this feature works is documented here

pre-commit

If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install pre-commit and add the following text to your repositories' .pre-commit-config.yaml:

repos:
- repo: https://github.com/aws-cloudformation/cfn-python-lint
  rev: v0.59.0  # The version of cfn-lint to use
  hooks:
    - id: cfn-python-lint
      files: path/to/cfn/dir/.*\.(json|yml|yaml)$
  • If you exclude the files: line above, every json/yml/yaml file will be checked.
  • You can see available cfn-lint versions on the releases page.

Author: aws-cloudformation
Source Code: https://github.com/aws-cloudformation/cfn-lint
License: MIT-0 License

#aws #lint 

CFN Lint: AWS CloudFormation Linter
Annie  Emard

Annie Emard

1652517180

SCSS Lint: Configurable Tool for Writing Clean, Consistent SCSS

scss-lint is a tool to help keep your SCSS files clean and readable by running it against a collection of configurable linter rules. You can run it manually from the command line, or integrate it into your SCM hooks.

NOTICE: Consider other tools before adopting SCSS-Lint

The Sass core team is now building Sass in Dart instead of Ruby, and will no longer be maintaining the Ruby implementation unless a maintainer steps up to help. Since the SCSS-Lint project relies on the Ruby Sass implementation, this means it will eventually not support the latest Sass features and bug fixes.

One alternative worthy of consideration is stylelint, which supports SCSS natively. If you want to use SCSS-specific rules in addition to stylelint core rules, you need to configure stylelint plugins like stylelint-scss or stylelint-order.

The SCSS-Lint project will continue to accept pull requests and provide basic support on the issue tracker.

Requirements

  • Ruby 2.4+
  • Sass 3.5.5+
  • Files you wish to lint must be written in SCSS (not Sass) syntax

Installation

gem install scss_lint

...or add the following to your Gemfile and run bundle install:

gem 'scss_lint', require: false

The require: false is necessary because scss-lint monkey patches Sass in order to properly traverse the parse tree created by the Sass parser. This can interfere with other applications that invoke the Sass parser after scss-lint libraries have been loaded at runtime, so you should only require it in the context in which you are linting, nowhere else.

Usage

Run scss-lint from the command line by passing in a directory (or multiple directories) to recursively scan:

scss-lint app/assets/stylesheets/

You can also specify a list of files explicitly:

scss-lint app/assets/stylesheets/**/*.css.scss

...or you can lint a file passed via standard input (note the --stdin-file-path flag is required when passing via standard input):

cat some-file | scss-lint --stdin-file-path=path/to/treat/stdin/as/having.scss

scss-lint will output any problems with your SCSS, including the offending filename and line number (if available).

Command Line FlagDescription
-c/--configSpecify a configuration file to use
-e/--excludeExclude one or more files from being linted
-f/--formatOutput format (see Formatters)
-o/--outWrite output to a file instead of STDOUT
-r/--requireRequire file/library (mind $LOAD_PATH, uses Kernel.require)
-i/--include-linterSpecify which linters you specifically want to run
-x/--exclude-linterSpecify which linters you don't want to run
--stdin-file-pathWhen linting a file passed via standard input, treat it as having the specified path to apply the appropriate configuration
--[no-]colorWhether to output in color
-h/--helpShow command line flag documentation
--show-formattersShow all available formatters
--show-lintersShow all available linters
-v/--versionShow version

When running scss-lint with JRuby, using JRuby's --dev flag will probably improve performance.

Configuration

scss-lint loads configuration in the following order of precedence:

  1. Configuration file specified via the --config flag
  2. Configuration from .scss-lint.yml in the current working directory, if it exists
  3. Configuration from .scss-lint.yml in the user's home directory, if it exists

All configurations extend the default configuration.

Note: The first configuration file found is the one that is loaded, e.g. the .scss-lint.yml file in the current working directory is loaded instead of the one in the user's home directory—they are not merged with each other.

Here's an example configuration file:

scss_files: 'app/assets/stylesheets/**/*.css.scss'

exclude: 'app/assets/stylesheets/plugins/**'

linters:
  BorderZero:
    enabled: false

  Indentation:
    exclude:
      - 'path/to/file.scss'
      - 'path/to/directory/**'
    severity: warning
    width: 2

All linters have an enabled option which can be true or false, which controls whether the linter is run, along with linter-specific options. The defaults are defined in config/default.yml.

Severities

The severity linter option allows you to specify whether the lint should be treated as a warning or an error. Warnings cause scss-lint to exit with a different error code than errors (unless both warnings and errors are present, in which case the error exit code is returned). This is useful when integrating scss-lint with build systems or other executables, as you can rely on its exit status code to indicate whether a lint actually requires attention.

You can also define the default severity for all linters by setting the global severity option.

Excluding Files

The exclude directive allows you to specify a glob pattern of files that should not be linted by scss-lint. Paths are relative to the location of the config file itself if they are not absolute paths. If an inherited file specifies the exclude directive, the two exclusion lists are combined. Any additional exclusions specified via the --exclude flag are also combined. If you need to exclude files for a single linter you can specify the list of files using the linter's exclude configuration option.

Generating a Configuration

To start using scss-lint you can use the Config Formatter, which will generate an .scss-lint.yml configuration file with all linters which caused a lint disabled. Starting with this as your configuration you can slowly enable each linter and fix any lints one by one.

Disabling Linters via Source

For special cases where a particular lint doesn't make sense in a specific area of a file, special inline comments can be used to enable/disable linters. Some examples are provided below:

Disable for the entire file

// scss-lint:disable BorderZero
p {
  border: none; // No lint reported
}

Disable a few linters

// scss-lint:disable BorderZero, StringQuotes
p {
  border: none; // No lint reported
  content: "hello"; // No lint reported
}

Disable all lints within a block (and all contained blocks)

p {
  // scss-lint:disable BorderZero
  border: none; // No lint reported
}

a {
  border: none; // Lint reported
}

Disable and enable again

// scss-lint:disable BorderZero
p {
  border: none; // No lint reported
}
// scss-lint:enable BorderZero

a {
  border: none; // Lint reported
}

Disable for just one line

p {
  // No lint reported:
  border: none; // scss-lint:disable BorderZero

  a {
    border: none; // Lint reported
  }
}

Disable/enable all linters

// scss-lint:disable all
p {
  border: none; // No lint reported
}
// scss-lint:enable all

a {
  border: none; // Lint reported
}

Formatters

Default

The default formatter is intended to be easy to consume by both humans and external tools.

scss-lint [scss-files...]
test.scss:2:1 [W] StringQuotes: Prefer single quoted strings
test.scss:2:1 [W] Indentation: Line should be indented 0 spaces, but was indented 1 space
test.scss:5:1 [W] StringQuotes: Prefer single quoted strings
test.scss:6:8 [W] UrlQuotes: URLs should be enclosed in quotes

CleanFiles

Displays a list of all files that were free of lints.

Config

Returns a valid .scss-lint.yml configuration where all linters which caused a lint are disabled. Starting with this as your configuration, you can slowly enable each linter and fix any lints one by one.

scss-lint --format=Config [scss-files...]
linters:
  Indentation:
    enabled: false
  StringQuotes:
    enabled: false
  UrlQuotes:
    enabled: false

Files

Useful when you just want to open all offending files in an editor. This will just output the names of the files so that you can execute the following to open them all:

scss-lint --format=Files [scss-files...] | xargs vim

JSON

Outputs JSON with filenames and an array of issue objects.

{
  "test.css": [
    {"line": 2, "column": 1, "length": 2, "severity": "warning", "reason": "Prefer single quoted strings", "linter": "StringQuotes"},
    {"line": 2, "column": 1, "length": 1, "severity": "warning", "reason": "Line should be indented 0 spaces, but was indented 1 spaces", "linter": "Indentation"},
    {"line": 5, "column": 5, "length": 2, "severity": "warning", "reason": "Prefer single quoted strings", "linter": "StringQuotes"},
    {"line": 6, "column": 4, "length": 9, "severity": "warning", "reason": "URLs should be enclosed in quotes", "linter": "UrlQuotes"}
  ]
}

TAP

Outputs TAP version 13 format.

TAP version 13
1..5
ok 1 - ok1.scss
not ok 2 - not-ok1.scss:123:10 SCSSLint::Linter::PrivateNamingConvention
  ---
  message: Description of lint 1
  severity: warning
  data:
    file: not-ok1.scss
    line: 123
    column: 10
  ---
not ok 3 - not-ok2.scss:20:2 SCSSLint::Linter::PrivateNamingConvention
  ---
  message: Description of lint 2
  severity: error
  data:
    file: not-ok2.scss
    line: 20
    column: 2
  ---
not ok 4 - not-ok2.scss:21:3 SCSSLint::Linter::PrivateNamingConvention
  ---
  message: Description of lint 3
  severity: warning
  data:
    file: not-ok2.scss
    line: 21
    column: 3
  ---
ok 5 - ok2.scss

Stats

Outputs statistics about how many lints of each type were found, and across how many files. This reporter can help in cleaning up a large codebase, allowing you to fix and then enable one lint type at a time.

15  ColorKeyword                  (across  1 files)
15  ColorVariable                 (across  1 files)
11  StringQuotes                  (across 11 files)
11  EmptyLineBetweenBlocks        (across 11 files)
 5  Indentation                   (across  1 files)
 5  QualifyingElement             (across  2 files)
 4  MergeableSelector             (across  1 files)
--  ----------------------        -----------------
66  total                         (across 12 files)

Plugins

There are also formatters that integrate with third-party tools which are available as plugins.

Checkstyle

Outputs an XML document with <checkstyle>, <file>, and <error> tags. Suitable for consumption by tools like Jenkins with the Checkstyle plugin.

gem install scss_lint_reporter_checkstyle
scss-lint --require=scss_lint_reporter_checkstyle --format=Checkstyle [scss-files...]
<?xml version="1.0" encoding="utf-8"?>
<checkstyle version="1.5.6">
  <file name="test.css">
    <error line="2" severity="warning" message="Prefer single quoted strings" />
    <error line="2" severity="warning" message="Line should be indented 0 spaces, but was indented 1 spaces" />
    <error line="5" severity="warning" message="Prefer single quoted strings" />
    <error line="6" severity="warning" message="URLs should be enclosed in quotes" />
  </file>
</checkstyle>

Exit Status Codes

scss-lint tries to use semantic exit statuses wherever possible, but the full list of codes and the conditions under which they are returned is listed here for completeness.

Exit StatusDescription
0No lints were found
1Lints with a severity of warning were reported (no errors)
2One or more errors were reported (and any number of warnings)
64Command line usage error (invalid flag, etc.)
66One or more files specified were not found
69Required library specified via -r/--require flag was not found
70Unexpected error (i.e. a bug); please report it
78Invalid configuration file; your YAML is likely incorrect
80Files glob patterns specified did not match any files.

Linters

scss-lint is a customizable tool with opinionated defaults that helps you enforce a consistent style in your SCSS. For these opinionated defaults, we've had to make calls about what we think are the "best" style conventions, even when there are often reasonable arguments for more than one possible style.

Should you want to customize the checks run against your code, you can do so by editing your configuration file to match your preferred style.

» Linters Documentation

Custom Linters

scss-lint allows you to create custom linters specific to your project. By default, it will load linters from the .scss-linters in the root of your repository. You can customize which directories to load from via the plugin_directories option in your .scss-lint.yml configuration file. See the linters directory for examples of how to write linters. All linters loaded from directories in plugin_directories are enabled by default, and you can set their configuration in your .scss-lint.yml.

# .scss-linters/another_linter.rb

module SCSSLint
  class Linter::AnotherLinter < Linter
    include LinterRegistry

    ...
  end
end
# .scss-lint.yml
plugin_directories: ['.scss-linters', '.another_directory']

linters:
  AnotherLinter:
    enabled: true
    some_option: [1, 2, 3]

You can also load linters packaged as gems by specifying the gems via the plugin_gems configuration option. See the scss_lint_plugin_example for an example of how to structure these plugins.

If the gem is packaged with an .scss-lint.yml file in its root directory then this will be merged with your configuration. This provides a convenient way for organizations to define a single repo with their scss-lint configuration and custom linters and use them across multiple projects. You can always override plugin configuration with your repo's .scss-lint.yml file.

# .scss-lint.yml
plugin_gems: ['scss_lint_plugin_example']

Note that you don't need to publish a gem to Rubygems to take advantage of this feature. Using Bundler, you can specify your plugin gem in your project's Gemfile and reference its git repository instead:

# Gemfile
gem 'scss_lint_plugin_example', git: 'git://github.com/cih/scss_lint_plugin_example'

As long as you execute scss-lint via bundle exec scss-lint, it should be able to load the gem.

Preprocessing

Sometimes SCSS files need to be preprocessed before being linted. This is made possible with two options that can be specified in your configuration file.

The preprocess_command option specifies the command to run once per SCSS file. The command can be specified with arguments. The contents of a SCSS file will be written to STDIN, and the processed SCSS contents must be written to STDOUT. If the process exits with a code other than 0, scss-lint will immediately exit with an error.

For example, preprocess_command: "cat" specifies a simple no-op preprocessor (on Unix-like systems). cat simply writes the contents of STDIN back out to STDOUT.

Metadata codeblocks like Jekyll Front Matter at the beginning of SCSS files can cause a syntax error when SCSS-Lint does not encounter Sass at the first line of the file, e.g. Invalid CSS after "@charset "utf-8"": expected "{", was ";". To search the first line for front matter's triple dash delimiter ---, strip out the YAML codeblock and pass the result to SCSS-Lint with line numbers preserved, you can use preprocess_command: "sed '1{/^---$/{:a N;/---$/!ba;d}}'" -- please note this sed command is valid for gnu-sed. If you are using the FreeBSD version of sed that ships with Mac OS X by default, it will throw an EOF error. You may solve this error by installing Homebrew, running brew install gnu-sed, and then substituting gsed for sed in the preprocess_command.

If only some SCSS files need to be preprocessed, you may use the preprocess_files option to specify a list of file globs that need preprocessing. Preprocessing only a subset of files should make scss-lint more performant.

Automated Code Review

Codacy

Codacy automates code reviews and monitors code quality on every commit and pull request. With Codacy you have scss-lint analysis out-of-the-box, and it is free for open source projects. It gives visibility into the technical debt and it can track code style and security issues, code coverage, code duplication, cyclomatic complexity and enforce best practices.

Editor Integration

Vim

You can have scss-lint automatically run against your SCSS files after saving by using the Syntastic plugin. If you already have the plugin, just add let g:syntastic_scss_checkers = ['scss_lint'] to your .vimrc.

IntelliJ

Install the SCSS Lint plugin for IntelliJ

Sublime Text

Install the Sublime scss-lint plugin.

Atom

Install the Atom scss-lint plugin. It is a part of the atomlinter project, so if you are already using other linter plugins, you can keep them in one place.

Emacs

Install and enable both scss-mode and flycheck-mode. You can enable automatic linting for scss-mode buffers with (add-hook 'scss-mode-hook 'flycheck-mode) in your init.el.

TextMate 2

If you use TextMate 2, you can install the SCSS-Lint.tmbundle bundle.

Visual Studio Code

If you use Visual Studio Code, you can install the scss-lint extension

Git Integration

If you'd like to integrate scss-lint into your Git workflow, check out our Git hook manager, overcommit.

Rake Integration

To execute scss-lint via a Rake task, ensure you have rake in your gem path (e.g. by adding to your Gemfile), and add the following to your Rakefile:

require 'scss_lint/rake_task'

SCSSLint::RakeTask.new

When you execute rake scss_lint, the above configuration is equivalent to just running scss-lint, which will lint all .scss files in the current working directory and its descendants.

You can customize the task by writing:

require 'scss_lint/rake_task'

SCSSLint::RakeTask.new do |t|
  t.config = 'custom/config.yml'
  t.args = ['--format', 'JSON', '--out', 'results.txt']
  t.files = Dir.glob(['app/assets', 'custom/*.scss'])
end

You can specify any command line arguments in the args attribute that are allowed by the scss-lint Ruby binary script. Each argument must be passed as an Array element, rather than one String with spaces.

You can also use this custom configuration with a set of files specified via the command line (note that this will not expand glob patterns):

# Single quotes prevent shell glob expansion
rake 'scss_lint[app/assets, custom/file-with-a-literal-asterisk-*.scss]'

Files specified in this manner take precedence over the files attribute initialized in the configuration above.

Maven Integration

Maven integration is available as part of the Sass maven plugin scss-lint since version 2.3 Check out the plugin documentation.

The Maven plugin comes with the necessary libraries included, a separate installation of ruby or scss-lint is not required.

Documentation

Code documentation is generated with YARD and hosted by RubyDoc.info.

Contributing

We love getting feedback with or without pull requests. If you do add a new feature, please add tests so that we can avoid breaking it in the future.

Speaking of tests, we use rspec, which can be run like so:

bundle exec rspec

After you get the unit tests passing, you probably want to see your version of scss-lint in action. You can use Bundler to execute your binary locally from within your project's directory:

bundle exec bin/scss-lint

Community

All major discussion surrounding SCSS-Lint happens on the GitHub issues page.

You can also follow @scss_lint on Twitter.

Changelog

If you're interested in seeing the changes and bug fixes between each version of scss-lint, read the SCSS-Lint Changelog.

Code of conduct

This project adheres to the Open Code of Conduct. By participating, you are expected to honor this code.

Author: sds
Source Code: https://github.com/sds/scss-lint
License: MIT License

#scss #lint 

SCSS Lint: Configurable Tool for Writing Clean, Consistent SCSS
Annie  Emard

Annie Emard

1652505180

Sass Lint: Pure Node.js Sass Linting

Sass Lint

A Node-only Sass linter for both sass and scss syntax!

Install

You can get sass-lint from NPM:

Install globally

npm install -g sass-lint

To save to a project as a dev dependency

npm install sass-lint --save-dev

Configuring

Sass-lint can be configured from a .sass-lint.yml or .sasslintrc file in your project. The .sasslintrc file can be in either JSON format or YAML. Both formats are interchangeable easily using tools such as json2yaml. If you don't either file in the root of your project or you would like all your projects to follow a standard config file then you can specify the path to one in your project's package.json file with the sasslintConfig option.

For example:

{
  "name": "my-project",
  "version": "1.0.0",
  "sasslintConfig": "PATH/TO/YOUR/CONFIG/FILE"
}

Use the Sample Config (YAML) or Sample Config (JSON) as a guide to create your own config file. The default configuration can be found here.

Configuration Documentation

Migrating from SCSS-Lint: If you already have a config for SCSS-Lint, you can instantly convert it to the equivalent Sass Lint config at sasstools.github.io/make-sass-lint-config.

Options

The following are options that you can use to config the Sass Linter.

  • cache-config - Allows you to cache your config for a small speed boost when not changing the contents of your config file
  • config-file - Specify another config file to load
  • formatter - Choose the format for any warnings/errors to be displayed
  • merge-default-rules - Allows you to merge your rules with the default config file included with sass-lint
  • output-file - Choose to write the linters output to a file

Files

The files option contains two properties, include and ignore. Both can be set to either a glob or an array of glob strings/file paths depending on your projects' needs and setup.

For example below we are providing a singular glob string to our include property and an array of patterns to our ignore property:

files:
  include: 'sass/**/*.s+(a|c)ss'
  ignore:
    - 'sass/vendor/**/*.scss'
    - 'sass/tests/**/*.scss'

As mentioned you can also provide an array to the include property like so

files:
  include:
    - 'sass/blocks/*.s+(a|c)ss'
    - 'sass/elements/*.s+(a|c)ss'
  ignore:
    - 'sass/vendor/**/*.scss'
    - 'sass/tests/**/*.scss'

Rules

For all rules, setting their severity to 0 turns it off, setting to 1 sets it as a warning (something that should not be committed in), and setting to 2 sets it to an error (something that should not be written). If a rule is set to just a severity, it will use the default configuration (where available).

If you want to configure options, set the rule to an array, where the first item in the array is the severity, and the second item in the array is an object including the options you would like to set.

Here is an example configuration of a rule, where we are specifying that breaking the indentation rule should be treated as an error (its severity set to two), and setting the size option of the rule to 2 spaces:

rules:
  indentation:
    - 2
    -
      size: 2

Rules Documentation


Disabling Linters via Source

Special comments can be used to disable and enable certain rules throughout your source files in a variety of scenarios. These can be useful when dealing with legacy code or with certain necessary code smells. You can read the documentation for this feature here.

Below are examples of how to use this feature:

Disable a rule for the entire file

// sass-lint:disable border-zero
p {
  border: none; // No lint reported
}

Disable more than 1 rule

// sass-lint:disable border-zero, quotes
p {
  border: none; // No lint reported
  content: "hello"; // No lint reported
}

Disable a rule for a single line

p {
  border: none; // sass-lint:disable-line border-zero
}

Disable all lints within a block (and all contained blocks)

p {
  // sass-lint:disable-block border-zero
  border: none; // No result reported
}

a {
  border: none; // Failing result reported
}

Disable and enable again

// sass-lint:disable border-zero
p {
  border: none; // No result reported
}
// sass-lint:enable border-zero

a {
  border: none; // Failing result reported
}

Disable/enable all linters

// sass-lint:disable-all
p {
  border: none; // No result reported
}
// sass-lint:enable-all

a {
  border: none; // Failing result reported
}

CLI

Sass Lint v1.1.0 introduced the ability to run Sass Lint through a command line interface. See the CLI Docs for full documentation on how to use the CLI.

There are small differences which are useful to understand over other CLI tools you may have encountered with other linters.

By default any rule set to severity: 2 in your config will throw an error which will stop the CLI on the first error it encounters. If you wish to see a list of errors and not have the CLI exit then you'll need to use the -q or --no-exit flag.

Warnings or any rule set to severity: 1 in your config by default will not be reported by the CLI tool unless you use verbose flag -v or --verbose.

With this in mind if you would like to have the CLI show both warnings and errors then at the very least your starting point to use the cli should be the following command. sass-lint -v -q

CLI Examples

Specify a config

Below is an example of the command being used to load a config -c app/config/.sass-lint.yml file, show errors and warnings on the command line, and target a glob pattern **/*.scss:

sass-lint -c app/config/.sass-lint.yml '**/*.scss' -v -q

or with long form flags

sass-lint --config app/config/.sass-lint.yml '**/*.scss' --verbose --no-exit

Including multiple source destinations

By default when specifying a directory/file to lint from the CLI you would do something similar to the following

sass-lint 'myapp/**/*.scss' -v -q

or with long form flags

sass-lint 'myapp/**/*.scss' --verbose --no-exit

Notice that you need to wrap glob patterns in quotation marks

If you want to specify multiple input sources then you need to include a single comma and a space , to separate each pattern as shown in the following

sass-lint 'myapp/dir1/**.*.scss, myapp/dir2/**/*.scss' -v -q

or with long form flags

sass-lint 'myapp/dir1/**.*.scss, myapp/dir2/**/*.scss' --verbose --no-exit

If you don't include the extra space after the comma then the multiple patterns will not be interpreted correctly and you could see sass-lint fail.

Ignore files/patterns

To add a list of files to ignore tests/**/*.scss, dist/other.scss into the mix you could do the following:

sass-lint -c app/config/.sass-lint.yml '**/*.scss' -v -q -i 'tests/**/*.scss, dist/other.scss'

or with long form flags

sass-lint --config app/config/.sass-lint.yml '**/*.scss' --verbose --no-exit --ignore 'tests/**/*.scss, dist/other.scss'

Notice that glob patterns need to be wrapped in quotation or single quote marks in order to be passed to sass-lint correctly and if you want to ignore multiple paths you also need to wrap it in quotation marks and separate each pattern/file with a comma and a space , .

This will be revisited and updated in sass-lint v2.0.0.

For further information you can visit our CLI documentation linked below.

CLI Documentation


Front matter

Certain static site generators such as Jekyll include the YAML front matter block at the top of their scss file. Sass-lint by default checks a file for this block and attempts to parse your Sass without this front matter. You can see an example of a front matter block below.


---
# Only the main Sass file needs front matter (the dashes are enough)
---

.test {
  color: red;
}

Contributions

We welcome all contributions to this project but please do read our contribution guidelines first, especially before opening a pull request. It would also be good to read our code of conduct.

Please don't feel hurt or embarrassed if you find your issues/PR's that don't follow these guidelines closed as it can be a very time consuming process managing the quantity of issues and PR's we receive. If you have any questions just ask!


Creating Rules

Our AST is Gonzales-PE. Each rule will be passed the full AST which they can traverse as they please. There are many different node types that may be traversed, and an extensive API for working with nodes. The file of the rule must have the same name as the name of the rule. All of the available rules are in our rules directory. Default options will be merged in with user config.

Author: sasstools
Source Code: https://github.com/sasstools/sass-lint
License: MIT License

#sass #lint 

Sass Lint: Pure Node.js Sass Linting
Bongani  Ngema

Bongani Ngema

1651113420

Lockfile-lint: Lint Lockfiles for Improved Security and Trust Policies

lockfile linting 🌈

lint lockfiles for improved security and trust policies   

About

Lockfiles are used as trusted whitelist of resources manifest to fetch packages from. However, keeping track of the changes introduced to lockfiles is not an easy task as they are designed to be consumed by machines 🤖.

What happens when someone creates a Pull Request and sneaks a malicious resource package that replaces a real library? 😱

Exactly! Lint your lockfiles to ensure they adhere to pre-defined security policies and mitigate this vector of attack.

Why is this important? read: Why npm lockfiles can be a security blindspot for injecting malicious modules

Usage

Easily invoked with npx on any project and lint it:

npx lockfile-lint --path yarn.lock --allowed-hosts npm yarn --validate-https

To lint the npm-shrinkwrap.json file, add the --type npm flag:

npx lockfile-lint --path npm-shrinkwrap.json --type npm --allowed-hosts npm yarn --validate-https

If you get no results, congratulations, the file passes!

If lockfile-lint detects exceptions to the policies it will report them:

carbon

Refer to lockfile-lint for more details on the CLI usage.

You can use lockfile-lint as a standalone CLI tool, or as an API library using the following npm packages:

  • lockfile-lint - a CLI tool that can be easily integrated as a pre-commit hook or part of a CI/build
  • lockfile-lint-api - a library providing a programmatic API

Security Disclaimer

Please be advised of the following security disclaimers that are outside of the control of a lockfile linter:

When you whitelist all hosts from npmjs, yarnpkg, github or other registries you implicitly convey that you trust all the packages originating from these sources. As such, a malicious package can exist in a registry source that you whitelist. Direct dependencies that you should add to a project should be well vetted before adding such as using a tool like npq.

Author: lirantal
Source Code: https://github.com/lirantal/lockfile-lint 
License: Apache-2.0 License

#node #npm #lint 

Lockfile-lint: Lint Lockfiles for Improved Security and Trust Policies
Annie  Emard

Annie Emard

1650370020

Community-Driven Set Of Lint Rules for Dart and Flutter Projects

Lint for Dart/Flutter

lint is a hand-picked, open-source, community-driven collection of lint rules for Dart and Flutter projects. The set of rules follows the Effective Dart: Style Guide.

This package can be used as a replacement for package:lints or the discontinued package:pedantic for those who prefer stricter rules.

lint tries to be strict but not annoying.

Install

Add lint as dependency to your pubspec.yaml. Version ^1.0.0 means you're automatically getting the latest version for lint when running pub upgrade

dev_dependencies:
  lint: ^1.0.0

Create an analysis_options.yaml file in the root of your project with the following content:

# This file configures the analyzer to use the lint rule set from `package:lint`

# For apps, use the default set
include: package:lint/analysis_options.yaml

# Packages, that may be distributed (i.e. via pub.dev) should use the package 
# version, resulting in a better pub score.
# include: package:lint/analysis_options_package.yaml

# You might want to exclude auto-generated files from dart analysis
analyzer:
  exclude:
    #- '**.freezed.dart'

# You can customize the lint rules set to your own liking. A list of all rules
# can be found at https://dart-lang.github.io/linter/lints/options/options.html
linter:
  rules:
    # Util classes are awesome!
    # avoid_classes_with_only_static_members: false
    
    # Make constructors the first thing in every class
    # sort_constructors_first: true

    # Choose wisely, but you don't have to
    # prefer_double_quotes: true
    # prefer_single_quotes: true

Lint badge

You're using lint in your open-source project? Add the badge to your README.md show that you honor strict lint rules

[![style: lint](https://img.shields.io/badge/style-lint-4BC0F5.svg)](https://pub.dev/packages/lint)

Comparison with other lint packages

A detailed comparison of all linting packages for dart can be found at https://rydmike.com/blog_flutter_linting.html

lint is among the strictest but not the strictest. It tires to find the right balance between useful and annoying.

Comparison to discontinued package:pedantic

Google publicly shares their internal rules as package:pedantic in open-source. It represents what Google is enforcing internally throughout all Dart code. For a lint rule to be added to pedantic, Google has to change all code which doesn't follow the style.

This strict practice results in only 27/150+ rules to be enabled. While some are contradictory to each other and can not enabled together, a big chunk of rules isn't enabled because it requires too much work to update all of Googles existing code.

For developers outside Google, it is the norm to have separate lint rules per project. One project might enable more rules then others.

lint enables a majority of lint rules, leaving out contradictory and very opinionated rules.

License

Copyright 2019 Pascal Welsch

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Author: passsy
Source Code: https://github.com/passsy/dart-lint
License: Apache-2.0 License

#lint #dart #flutter 

Community-Driven Set Of Lint Rules for Dart and Flutter Projects

Django-allauth: A simple Boilerplate to Setup Authentication

Django-Authentication 

A simple Boilerplate to Setup Authentication using Django-allauth, with a custom template for login and registration using django-crispy-forms.

Getting Started

Prerequisites

  • Python 3.8.6 or higher

Project setup

# clone the repo
$ git clone https://github.com/yezz123/Django-Authentication

# move to the project folder
$ cd Django-Authentication

Creating virtual environment

  • Create a virtual environment for this project:
# creating pipenv environment for python 3
$ virtualenv venv

# activating the pipenv environment
$ cd venv/bin #windows environment you activate from Scripts folder

# if you have multiple python 3 versions installed then
$ source ./activate

Configured Enviromment

Environment variables

SECRET_KEY = #random string
DEBUG = #True or False
ALLOWED_HOSTS = #localhost
DATABASE_NAME = #database name (You can just use the default if you want to use SQLite)
DATABASE_USER = #database user for postgres
DATABASE_PASSWORD = #database password for postgres
DATABASE_HOST = #database host for postgres
DATABASE_PORT = #database port for postgres
ACCOUNT_EMAIL_VERIFICATION = #mandatory or optional
EMAIL_BACKEND = #email backend
EMAIL_HOST = #email host
EMAIL_HOST_PASSWORD = #email host password
EMAIL_USE_TLS = # if your email use tls
EMAIL_PORT = #email port

change all the environment variables in the .env.sample and don't forget to rename it to .env.

Run the project

After Setup the environment, you can run the project using the Makefile provided in the project folder.

help:
 @echo "Targets:"
 @echo "    make install" #install requirements
 @echo "    make makemigrations" #prepare migrations
 @echo "    make migrations" #migrate database
 @echo "    make createsuperuser" #create superuser
 @echo "    make run_server" #run the server
 @echo "    make lint" #lint the code using black
 @echo "    make test" #run the tests using Pytest

Preconfigured Packages

Includes preconfigured packages to kick start Django-Authentication by just setting appropriate configuration.

PackageUsage
django-allauthIntegrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.
django-crispy-formsdjango-crispy-forms provides you with a crispy filter and {% crispy %} tag that will let you control the rendering behavior of your Django forms in a very elegant and DRY way.

Contributing

  • Django-Authentication is a simple project, so you can contribute to it by just adding your code to the project to improve it.
  • If you have any questions, please feel free to open an issue or create a pull request.

Download Details:
Author: yezz123
Source Code: https://github.com/yezz123/Django-Authentication
License: MIT License

#django #python 

Django-allauth: A simple Boilerplate to Setup Authentication