10

In sass, the way one imports is by using the import command. I will use Zurb Foundation as an example:

@import "foundation";

This will then import the whole foundation.scss file and all it's relative imports to the top of the current file. This means that the entire foundation.scss file will be compiled and outputted along with the contents of the file to the final <name here>.css file.

Though this is good for customisation, such as custom colors and spacing, it becomes a pain when creating libraries and distributing these libraries as individual droplets for other people to slot into their existing projects.

Is there a way to import files as "references", so that mixins and other variables become available in the scope of the current file, but other css statements are ignored? The LESS css preprocessor has a newly implemented import tag similar to this (appropriately named a reference).

j0k
  • 22,600
  • 28
  • 79
  • 90
user3030670
  • 103
  • 1
  • 4

1 Answers1

1

Taking a look at Foundation demonstrates a good approach to this:

https://github.com/zurb/bower-foundation/blob/master/scss/foundation/components/_breadcrumbs.scss

Here they have one @import "global"; at the top of the file.

That is followed by a bunch of mixins

At the bottom they have:

@include exports("breadcrumbs") {
  @if $include-html-nav-classes {
    .breadcrumbs {
      @include crumb-container;
      @include radius($crumb-radius);

      &>* {
        @include crumbs;
      }
    }
  }
}

The $include-html-nav-classes is set to true by default in the _global.scss file. It can be overridden in any other file by changing it to false. This allows you to both use the mixins and generate html.

If you don't need to generate any css just include mixins only and it will simplify your situation. I believe that they do this to allow for fast customization and optimization of the outputted css.

JAMESSTONEco
  • 2,051
  • 15
  • 21
  • 6
    Actually, the Foundation method is *terrible* and should not be mimicked. No one recommends authoring CSS libraries this way because it doesn't it's more complicated than it needs to be. Code that emits CSS should be segregated from things like mixins, variables, etc. – cimmanon Nov 26 '13 at 13:55
  • Finding *any* Compass extension is a very difficult task at this point in time. The majority of extensions that can be found are purely *building block* style (ie, they only include variables, functions, and mixins: sassy-buttons, modular-scale, etc.). Extensions like resets and normalizations are by far less common. Foundation and Bootstrap are the only extensions I've been able to find that package both CSS *and* their essential building blocks together without segregation. – cimmanon Nov 28 '13 at 15:15
  • This is a good question, and I agree the Foundation method in this answer is a code smell. Ideally, the Sass language would have a special import directive (e.g. "@importReference") so that one could import a file without it writing the CSS. That would be useful (and intuitive) in master page scenarios in which the master page links a Global.css file, and then child pages link to child-specific CSS files that might use references from the master page's CSS file (might make sense if Global.css is larger and should be cached across multiple pages rather than combining into a single CSS file). – lightmotive May 04 '15 at 17:49
  • Looks like others would like the [same thing](https://github.com/nex3/sass/issues/353#issuecomment-5146513). The ability to disable CSS Output is what would answer the OP's question. – lightmotive May 04 '15 at 18:00