Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/tjw-lint/tjw-sasslint-rules below:

tjw-lint/tjw-sasslint-rules: The Jared Wilcurt's very aggressive Sass Linting rules for obsessives

These linting rules are designed to be very strict. Much thought has been placed in every rule, and a comment has been added over each explaining what it does. The rules work on both .sass and .scss files, though if you are using these rules, you should probably be using .sass files primarily as they are stricter by default and less error proned (see pros/cons at the bottom). These rules include a strict ordering of CSS properties, detailed below.

Much care and thought has gone into every rule, and each has been documented. This rule set is by far the most comprehensive currently in existence. Take, for example, the "property sort order" detailed below:

Property Sort Order:

The order by which you sort properties matters for consistency, predictability, and compression (gzip). I have carefully analyzed the most popular approaches, found their flaws, and improved on them.

• Improvements made over SMACSS/Recess/Concentric:
  • Be comprehensive: I've included all CSS properties supported by (or intended to be supported by) current major browsers. Meaning every single CSS property from W3C and MDN.
  • Include Vendor-Prefixes: I only include modern (2019) vendor prefixes - Desktop: Chrome/FF/Safari/Edge/IE11, Android: Chrome/FF, iOS: Safari
  • Remove Outdated/deprecated properties: Old vendor prefixes that are not required anymore, or deprecated CSS properties no longer supported by any browser are not included in my set.
  • Out-of-order errors: In my set vendor-prefixes always occur on the line prior to their native counterparts.
  • No dupes!: A duplicate property introduces confusion for the linter and the developer. I have an automated test to insure no dupes ever enter this set.
  • Consensus and versioning: There is only one official version of these rules. There are no competing versions of the TJW ruleset. It is versioned on GitHub and published to npm.

For the purposes of linting, the more properties you have documented the better.

(? - It is hard to denote dupes as there are competing versions of Concentric)

If you find you are using a CSS property that is not in the list, please create an issue on GitHub to report it and it will be added into the ruleset.

1. npm install --save-dev tjw-sasslint-rules sass-lint sass-lint-auto-fix node-sass
2. Create a file called .sass-lint.yml and set it up like so:

   options:
     config-file: node_modules/tjw-sasslint-rules/tjwsasslint.yml
   files:
     # Note: You can change the '**/*.s+(a|c)ss' to be specific to your project's Sass folder. Example: 'src/sass/**/*.s+(a|c)ss'
     include: '**/*.s+(a|c)ss'

3. In the "scripts": section of your package.json add in these two lines:
   • "sasslint": "sass-lint -c .sass-lint.yml -v -f table",
   • "sassfix": "sass-lint-auto-fix -c .sass-lint.yml"
4. npm run sassfix - This will automatically fix anything it can in accordance with the rules.
5. npm run sasslint - This will show you the remaining lines of code in violation of the linting rules for you to manually correct.

1. It doesn't autofix very much, if you know of a better sass-lint auto-fixer, let me know.
2. Keep running it until you get the same results back. Each re-run may fix additional things.

Benefits of Sass over SCSS:

• Enforced coding format (indented syntax)
• Consistency across all files
• Less error proned especially during refactoring (due to lack of {})
• Faster to write due removal of {} and ;( which can cause errors)
• Easier to read as it forces all files to look the same
• Better for writing rules and nested rules (90+% of your style codebase, most likely)

  .animals
      +myMixin
      border: 1px solid $myColor
      margin: 10px
      padding: 5px
      .kitten
          background: $myColor
          font-family: $secondaryFont
          font-size: $fontSizeMedium
          text-align: center

Benefits of SCSS over Sass:

• All valid CSS files are valid SCSS files
• Allows for variety of control for how to display or structure rules (particularly useful for tabular-like data in rules)

  .icon {
      display: inline-block;
      width: 16px;
      height: 16px;
      background-image: url('sprite-sheet.png');
  }
  .icon-bat { background-position:   0px   0px; }
  .icon-cat { background-position:   0px -16px; }
  .icon-cow { background-position:   0px -32px; }
  .icon-dog { background-position: -16px   0px; }
  .icon-pig { background-position: -16px -16px; }
  .icon-rat { background-position: -16px -32px; }
  .icon-bee { background-position: -32px   0px; }
  .icon-ant { background-position: -32px -16px; }
  .icon-ape { background-position: -32px -32px; }

• Better for long or heavily nested lists/maps
• More familiar for beginners (though beginners tend to have little to no trouble learning the .sass syntax)

Benefits of Sass or SCSS over CSS:

• Automatic concatenation and minification on save
• Modular/Reusable code
• Nesting (possibly coming to native CSS in the future)
• Precomputed Variables (Live variables already exist in Sass/SCSS/CSS via custom properties)
• Mixins and Mixin Libraries (See: family.scss for a good example)
• Precomputed Math (width: $height / 2;)
• Built in color functions (color: desaturate(#F00, 20%); or color: rgba(#FCE, 0.5);)
• Custom Functions
• Loops

Other Info:

• Sass can be converted to SCSS with no loss, or processed to CSS
• SCSS can be converted to Sass with no loss, or processed to CSS
• Sass, SCSS, and CSS all have auto-complete and syntax highlighting in all editors of merit

1. First and foremost, contribute to the other tools that this uses:
   • https://github.com/sasstools/sass-lint
   • https://github.com/srowhani/sass-lint-auto-fix
   • Specifically, see if you can fix this bug, or improve any part of the auto-fixer to fix more things, or to not require being re-ran multiple times.
2. If you find any CSS properties missing from this rule-set, report it.
3. Use .sass syntax in your code examples online.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4