Renaming "sass" and "scss" more accurately

The language Sass has two syntaxes (and filetypes to denote which is used):

• .sass - Syntactically Awesome Stylesheets - Whitespace dependent, strict, built in linting, shorthand, enforced consistency across all files, removes curly braces ({}) and semi-colons (;) in favor of indentation and end-of-line characters. Good for writing CSS Rules, nested rules, mixins, and functions.
• .scss - Sassy Cascading Stylesheets - All valid .css files are valid .scss files, more familiar for beginners, complete control over formatting and white space. Good for writing single-line table-like rules, and long or deeply nested lists/maps.

---

Style-Dictionary has many format output options. These are the ones related to the Sass language:

• scss/variables
• scss/icons
• sass/map-flat
• sass/map-deep

The naming of these is confusing as all of them output to the scss syntax and .scss files.

To avoid confusion these should be renamed to:

• scss/variables
• scss/icons
• scss/map-flat
• scss/map-deep

Also, documentation says things like Creates a Sass file, which is technically true if using “Sass” to refer to the language, but it is confusing as the actual file produced ends with .scss. People may misunderstand “Creates a Sass file” for “Creates a .sass file”. It would be less ambiguous to say “Creates a .scss file”.

---

This change does the following:

• Avoids confusion
• Sets proper expectations
• Makes naming consistent and predictable
• Frees up the name space to allow expanding to sass syntax in the future
  • Ideally to the point that all scss/* items will have a sass/* alternative that outputs the same format but with the indented syntax. However, that work can’t really begin if the existing formats are using the wrong name.

---

---

On the same topic, scss is the name used for the “platform” and “transformGroup”. Platform doesn’t make sense as scss is just a syntax, and not a platform. The Sass language should be considered the platform, since .sass and .scss files can interact with each other in the same project. I’m new to Style-Dictionary, so I’m not certain what value "transformGroup" holds, but the same logic should be applied there.

As it stands currently, without spending a bunch of time in the docs, the following is very confusing and unintuitive to those familiar with Sass. When I saw scss as the platform I assumed that I could rename it to sass to get .sass syntax.

{
  "platforms": {
    "scss": {
      "transformGroup": "scss",
      "buildPath": "build/scss/",
      "files": [{
        "destination": "_variables.scss",
        "format": "sass/map-flat"
      }]
    }
  }
}

The first thing I tried was renaming everything to sass to see if I could get .sass output:

{
  "platforms": {
    "sass": {
      "transformGroup": "sass",
      "buildPath": "build/sass/",
      "files": [{
        "destination": "_variables.sass",
        "format": "sass/variables"
      }]
    }
  }
}

I think that’s a fairly natural thing to try, before going to the docs.

[didoo]

@TheJaredWilcurt I understand your concerns about the double sass/scss reference in the codebase (and probably documentation). I was the one that added the sass/map-xxx formats, so totally my fault. I’ll create a PR to rename them correctly, if @dbanksdesign is OK with using scss/map-xxx for them.

That said, we should also consider that the “indented” syntax is considered “old” even by the official Sass documentation:

There are two syntaxes available for Sass. The first, known as SCSS (Sassy CSS) and used throughout this reference, is an extension of the syntax of CSS. […] Files using this syntax have the .scss extension. The second and older syntax, known as the indented syntax (or sometimes just “Sass”), provides a more concise way of writing CSS. […] Files using this syntax have the .sass extension.

I think nowadays has become quite common to refer to Sass as the way to write .scss files (hence, my mistake). So I think it would be better to keep this formats, and leave the “old sass” syntax to the developers to implement, if needed, as custom formats.

[dbanksdesign]

Apologies for the delay on this, the PR to fix the issues should be ready to go, and will go out in the next release.