Sass compile errors

[reinos]

According this #551 (comment) Angular Cli is compiling all the files.

Currently i have this setup

sass/mixins/_pulls.sass (the mixin himself)

@mixin pull-left
    float: left !important

@mixin pull-right 
    float: right !important

sass/mixins/index.sass (the file that load all the mixins)

//this is the main entry point for all Mixins files
@import "_pulls"

sass/utils/pulls.sass (the file that call the pull mixin)

.pull-left
    @include pull-left()

.pull-right
    @include pull-right()

sass/utils/index.sass (the file that load all utils files)

//this is the main entry point for all utils files
@import '_pulls'

sass/_variables.sass (the variable file)
sass/index.sass ( the file that load the files together)

//this is the main entry point for all default sass files
@import "variables"
@import "mixins/index"
@import "utils/index"

Now the point is that Angular cli is compiling every file and not respect the import rule and create one file for it.

so the compiler is triggering an error on the file that call the mixin utils/_pulls.sass because the mixin file himself is compiled and not loaded into the _pull.sass file.

Is there something that i missed or does the sass compiler does not handle those structure. And how i can make this structure work.

[reinos]

Update:
To let the import works, you have to include the needed mixin files into your file where you`re working in.

For example:
in the mixin folder i have _pull.sass with a mixin. When i need this mixin, i have to import this file in the file where i need it.

Because the sass (perhaps also less) compiles every file, the mixin is not in the scope. Therefore you need to load it per file when needed. Also for the variable folder.

[nareshbhatia]

I don't understand why #551 is closed. This and #551 are real issues with Sass support. _*.sass or _*.scss files should never be compiled by the Sass compiler directly - they should be excluded from compiles. These files are only meant to be imported by main sass files (files without a leading underscore).

Also I have a related question - what is the correct place to specify sassOptions (see ember-cli-sass for example). Should I modify angular-cli-build.js or angular-cli.json? How?

TIA.

[steveblue]

@reinos including mixins in the same file is not an acceptable solution IMHO, we need the ability to leverage SASS imports from other files. The compiler should respect files prepended with underscore and not compile them. That is the nature of SASS. I am also disappointed I cannot easily use PostCSS in the CLI, which handles vendor prefixing in the most elegant way possible.

[reinos]

@steveblue agree, but thats for now my solution...

[hpop]

Just for reference: Even the SASS docs are saying that files with an underscore will not be compiled: http://sass-lang.com/guide#topic-4

[steveblue]

Sass in the public folder does not compile to css in the dist folder, the files are just being straight copied and now these .scss in the dist. This issue has been reported by others. These minor bugs are prohibiting us from adopting the cli at the moment.

[Madd]

I stumbled across this problem myself. So my suggestion is to add an option and a regex in angular-cli/lib/broccoli/angular-broccoli-sass.js:

constructor(inputNodes, options) {
  super(inputNodes, {});

  options = options || {};
  Plugin.call(this, inputNodes, {
    cacheInclude: options.cacheInclude || [/\.scss$/, /\.sass$/],
    cacheExclude: options.cacheExclude || undefined,
    compilePartials: options.compilePartials || true
  });
  this.options = options;
}

build() {
  this.listFiles().forEach(fileName => {
    // We skip compiling partials if options.compilePartials is false
    if (this.options.compilePartials ||
      !new RegExp(/^_+.*.s[ac]ss$/i).test(path.basename(fileName))) {

      // Normalize is necessary for changing `\`s into `/`s on windows.
      this.compile(path.normalize(fileName),
                   path.normalize(this.inputPaths[0]),
                   path.normalize(this.outputPath));
    }
  });
}

This way the partials are not compiled into separate .css files and does not require you to import variables and mixins in every file. And the best thing is that they are watched, unlike the cacheExclude option, so you can enjoy the live reload while building cool stuff. :)

[filipesilva]

@Madd would you be interested in making a PR that adds this functionality?

[Madd]

@filipesilva I can do that. Will go through CONTRIBUTING.md and make a PR as soon as I can.

[filipesilva]

Basically make the proposed change, add a test on e2e_workflow.ts that confirms this, and use as commit message something like fix(sass): don't compile partials.

I think that's all that matters. If you have trouble running the tests in your machine, Travis will run them anyway.