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 Flag	Description
--auto-gen-config	Generate a configuration file acting as a TODO list
--auto-gen-exclude-limit	Number of failures to allow in the TODO list before the entire rule is excluded
-c/--config	Specify which configuration file to use
-e/--exclude	Exclude one or more files from being linted
-i/--include-linter	Specify which linters you specifically want to run
-x/--exclude-linter	Specify which linters you don't want to run
-r/--reporter	Specify which reporter you want to use to generate the output
-p/--parallel	Run linters in parallel using available CPUs
--fail-fast	Specify whether to fail after the first file with lint
--fail-level	Specify the minimum severity (warning or error) for which the lint should fail
--[no-]color	Whether to output in color
--[no-]summary	Whether to output a summary in the default reporter
--show-linters	Show all registered linters
--show-reporters	Display available reporters
-h/--help	Show command line flag documentation
-v/--version	Show haml-lint version
-V/--verbose-version	Show 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

Option	Description
enabled	If false, this linter will never be run. This takes precedence over any other option.
include	List of files or glob patterns to scope this linter to. This narrows down any files specified via the command line.
exclude	List 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.
severity	The 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 

What is GEEK

Buddha Community

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 Flag	Description
--auto-gen-config	Generate a configuration file acting as a TODO list
--auto-gen-exclude-limit	Number of failures to allow in the TODO list before the entire rule is excluded
-c/--config	Specify which configuration file to use
-e/--exclude	Exclude one or more files from being linted
-i/--include-linter	Specify which linters you specifically want to run
-x/--exclude-linter	Specify which linters you don't want to run
-r/--reporter	Specify which reporter you want to use to generate the output
-p/--parallel	Run linters in parallel using available CPUs
--fail-fast	Specify whether to fail after the first file with lint
--fail-level	Specify the minimum severity (warning or error) for which the lint should fail
--[no-]color	Whether to output in color
--[no-]summary	Whether to output a summary in the default reporter
--show-linters	Show all registered linters
--show-reporters	Display available reporters
-h/--help	Show command line flag documentation
-v/--version	Show haml-lint version
-V/--verbose-version	Show 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

Option	Description
enabled	If false, this linter will never be run. This takes precedence over any other option.
include	List of files or glob patterns to scope this linter to. This narrows down any files specified via the command line.
exclude	List 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.
severity	The 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 

ECS: Residential & Commercial Cleaning Services in London

Specializing in commercial cleaning, office cleaning, hospital & GP surgery cleaning, residential cleaning, washroom cleaning, school cleaning, Covid cleaning and sanitization, ECS Commercial Cleaning Company London has built up a large, experienced team of highly-skilled team of professionals who ensures work is delivered to highest standards, on time and on budget.

At ECS Commercial Cleaning, we provide a safe, cost-effective and efficient service that covers all your commercial cleaning needs. From residential cleaning, washroom cleaning, school cleaning to office cleaning, hospital & GP surgery cleaning, we cater it all. We have years of experience with all kinds of projects and know the best approach to save you time and money. Our professional knowledge and skills has enabled us to provide high quality cleaning solutions throughout London.

We’ve been delivering commercial cleaning services throughout London with the help of trained and experienced professionals, using only the finest equipment and cleaning solutions. Our team starts cleaning project from initial consultation through to completion on budget and schedule.

ECS Commercial Cleaning strives to keep people first, investing in their professional training and safety. We work hard to create and sustain an environment that helps us to achieve clients’ expectations through consistently excellent service and minimal downtime.

Our Services

With 10 years of market experience, a resource of professional employees and coverage throughout the London, ECS Commercial Cleaning has established itself as one of the leading commercial cleaning company, offering valuable cleaning solutions including:

• commercial cleaning
• office cleaning
• hospital & GP surgery cleaning
• residential cleaning
• washroom cleaning
• school cleaning
• covid cleaning and sanitization

Our clients are the London’s leading retail outlets, office buildings and office premises, schools, hospitals, production and industrial premises and others. Our cleaning solutions offers peace of mind to clients and most importantly ensure that workers are able to do their jobs comfortably and efficiently without compromising safety. Over the years of industry experience, we remain at the forefront of our industry due to our unparalleled customer dedication and unrivalled experience in providing safe, and cost-effective cleaning solutions.

Our Expert Team

ECS Commercial Cleaning provides you with an expert team that completes your cleaning project professionally and efficiently. No matter what cleaning service you require, our aim is to work closely with our clients in order to comprehend their needs and fulfil their specific requirements through tailored cleaning solutions.

With our eco-friendly cleaning products and a team of experienced professionals, we can provide timely cleaning solutions to our clients. Contact ECS Commercial Cleaning on 0161 5462235.

#cleaning #commercial cleaning #office cleaning #residential cleaning #washroom cleaning #covid cleaning and sanitization

An Outstanding Office Cleaning and Commercial Cleaning Services London

Do you need to turn to a reputable company that offers an outstanding office cleaning and commercial cleaning services London? Maybe you need a DBS checked cleaners London? In either case, ECS Commercial Cleaning is the right choice for you. We are one of the best cleaning company ready to meet all your cleaning needs and will do so in a timely and efficient manner.

We offer office cleaning, commercial cleaning, and sanitisation and specialist cleaning London to our customers for either their home or business. We take pride in providing customized office cleaning and commercial cleaning services London, regardless the size of your facility. Our goal is to provide a 100% satisfactory experience and ensure your facility is sanitized, providing a productive and safe environment for employees and customers. We constantly stay on the cutting edge of technology to provide you with the best quality and most efficient cleaning services.

Skilled Cleaning Services

Our company has been providing skilled office and commercial cleaning services across London for over 10 years. Our experience, coupled with DBS checked cleaners London, has allowed us to make efficient use of the best processes, cleaning products, and supplies to get the job done quickly and effectively without any disruption. Whether you require regular or one-time cleaning services, we will customize cleaning program specifically according to your needs. ECS Commercial Cleaning has the resources and expertise to get the job done right the first time.

Professional Experts and Advanced Technology

We have DBS checked cleaners who are thoroughly trained and experienced in providing high quality cleaning services that dramatically decrease dust and bacteria, from your home and business. ECS Commercial Cleaning team is committed to making your home and business a cleaner and healthier place. With more than 10 years’ experience with providing office cleaning and commercial cleaning services, you can be confident that our team have all the skills required to provide hassle-free services.

Pursue the Highest Standards in Cleaning

At ECS Commercial Cleaning, we persistently follow the highest standards in sanitisation and specialist cleaning with customized programs designed to meet your needs. We have the tools and cleaning supplies to handle your cleaning and disinfecting responsibilities. Our customized cleaning plans make sure that you are getting the best service for the best price.

Our cleaning team is equipped to handle any project, big or small, at any time of day. Call us today at 0161 5462235 to learn more about how, ECS Commercial Cleaning can handle all your office cleaning and commercial cleaning responsibilities in London.

#office cleaning #commercial cleaning #cleaning #cleaning team

What You Can Learn about Setting from Classic Sitcoms

Giving your novel a strong sense of place is vital to doing your part to engage the readers without confusing or frustrating them. Setting is a big part of this (though not the whole enchilada — there is also social context and historic period), and I often find writing students and consulting clients erring on one of two extremes.

**Either: **Every scene is set in a different, elaborately-described place from the last. This leads to confusion (and possibly exhaustion and impatience) for the reader, because they have no sense of what they need to actually pay attention to for later and what’s just…there. Are the details of that forest in chapter 2 important? Will I ever be back in this castle again? Is there a reason for this character to be in this particular room versus the one she was in the last time I saw her? Who knows!

Or: There are few or no clues at all as to where the characters are in a scene. What’s in the room? Are they even in a room? Are there other people in th — ope, yes, there are, someone just materialized, what is happening? This all leads to the dreaded “brains in jars” syndrome. That is, characters are only their thoughts and words, with no grounding in the space-time continuum. No one seems to be in a place, in a body, at a time of day.

Everything aspect of writing a novel comes with its difficulties, and there are a lot of moving pieces to manage and deploy in the right balance. When you’re a newer writer, especially, there’s something to be said for keeping things simple until you have a handle on how to manage the arc and scope of a novel-length work. And whether you tend to overdo settings or underdo them, you can learn something from TV, especially classic sitcoms.

Your basic “live studio audience” sitcoms are performed and filmed on sets built inside studios vs. on location. This helps keep production expenses in check and helps the viewer feel at home — there’s a reliable and familiar container to hold the story of any given episode. The writers on the show don’t have to reinvent the wheel with every script.

Often, a show will have no more than two or three basic sets that are used episode to episode, and then a few other easily-understood sets (characters’ workplaces, restaurants, streets scenes) are also used regularly but not every episode.

#creative-writing #writing-exercise #writing-craft #writing #writing-tips #machine learning

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 Flag	Description
-c/--config	Specify a configuration file to use
-e/--exclude	Exclude one or more files from being linted
-f/--format	Output format (see Formatters)
-o/--out	Write output to a file instead of STDOUT
-r/--require	Require file/library (mind $LOAD_PATH, uses Kernel.require)
-i/--include-linter	Specify which linters you specifically want to run
-x/--exclude-linter	Specify which linters you don't want to run
--stdin-file-path	When linting a file passed via standard input, treat it as having the specified path to apply the appropriate configuration
--[no-]color	Whether to output in color
-h/--help	Show command line flag documentation
--show-formatters	Show all available formatters
--show-linters	Show all available linters
-v/--version	Show 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 Status	Description
0	No lints were found
1	Lints with a severity of warning were reported (no errors)
2	One or more errors were reported (and any number of warnings)
64	Command line usage error (invalid flag, etc.)
66	One or more files specified were not found
69	Required library specified via -r/--require flag was not found
70	Unexpected error (i.e. a bug); please report it
78	Invalid configuration file; your YAML is likely incorrect
80	Files 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