17

The site I'm working on uses the rails asset pipeline and an application.scss file to import and process different CSS files.

However, some stylesheets are used in specific places, and for those, it makes little sense to import them into the global manifest. But not so importing them requires importing variables.scss, and possibly mixins.scss into the sheet itself (so they'll process correctly), resulting in duplicate code in the final CSS.

Is there a way to basically tell the preprocessor - "trust me, the variable/mixin you're seeing will be defined by the time everything gets processed"?

Otherwise, I don't see how to avoid importing every sheet into a single manifest, which seems bloated.

Thanks.

RBZ
  • 2,034
  • 17
  • 34
Gabe Friedman
  • 171
  • 1
  • 1
  • 6
  • Possible duplicates: http://stackoverflow.com/questions/17976140/false-positive-undefined-variable-error-when-compiling-scss, http://stackoverflow.com/questions/18408324/how-can-one-import-only-variables-and-mixins-from-scss-stylehsheets, http://stackoverflow.com/questions/24182734/how-to-avoid-duplication-of-styles-in-scss – cimmanon Jun 28 '15 at 19:46
  • i'm not quite sure I get this, if you have files that only include mixins and variables you should be able to include them as often as you like without any bloat? Neither thing results in compiled css – Toni Leigh Jun 30 '15 at 11:48
  • So using e.g. @import "/mixins"; at the start of an css file results in no more compiled code than not using the import? So it simply allows the css to get compiled? If so. great and thanks! – Gabe Friedman Jul 01 '15 at 15:27
  • 1
    As far as I'm aware importing just one or all of your mixin/variables files multiple times won't make a difference as it's all compiled into one css file in a logical order by the pre-processor. – thecraighammond Jul 16 '15 at 08:38
  • @thecraighammond so if i have two imports `@import mixins` and `@import variables` but mixins file itself imports variables already. would it be redundant to import both files in a new file like `component.scss`? theres no performance benefit? – Akin Hwan Sep 23 '19 at 16:41

4 Answers4

2

The short answer to your question is no. The variables need to be defined in a logical order from when they are called in compilation. It's like a "chicken and the egg" scenario.

From what I can ascertain in your description, the project you're working on is not compiling into a unified workflow, but chunking out into modular portions relational to your file structure. IF this is the case, what you can do at the beginning of each file is reference the variables file from the root.

In a normal workflow, you would import your scss files based on your defined hierarchy like so:

sass/style.scss

/* Main Stylesheet */

@import "variables";
@import "mixins";

/* Modular Sections */
@import "layout/header";
@import "layout/body";
@import "layout/footer";

would compile out to one stylesheet style.css with a command sass sass/style.scss:style.css

What I'm assuming your project does is have all the /* Modular Sections */ files compile out into their own CSS files.

layout/header.scss 

/* Header Stylesheet */
@import "../variables";
@import "../mixins";

Given a files structure that resembles:

/root

  style.scss
  variables.scss
  mixins.scss

  /layouts

    header.scss
    body.scss
    footer.scss

This all seems kinda silly though. I don't know all the parameters that go into your current sass compilation, but I'd recommend using a unified workflow.

Plummer
  • 6,522
  • 13
  • 47
  • 75
2

You can use Partials so the compiler will not try to interpret variables etc.

Basically, rename the files that you do not want the compiler to interpret -- but will be available when compiled -- with an underscore before the filename.

eg. _filename.scss

Derry Birkett
  • 46
  • 4
0

If I understood well you want to avoid copies of the same css in css files caused by using @import in scss. I solved this problems by doing a hierarchical three.

For exemple consider the home.scss file, where you import header.scss and footer.scss. Both header.scss and footer.scss use specific colors that you import from a file named colors.scss:

// colors.scss

$MidnightBlue: #00478f;
$RedOrange: #ff5d00;
$MistyBlue: #d8e1e7;
$Ebony: #2a231f;

Now you could import colors in header.scss, footer.scss and maybe even in home.scss. The result is that in home.css the code of colors.scss is repeated 3 times. A solution is importing colors.scss only in header.scss. Then in home.scss the first @import that you specify is @import "header.scss"; and then @import "footer.scss";, thus you can use the colors variables in footer.scss and in home.scss even if you don't import them directly in footer.scss and home.scss. That's because the variables of colors are imported before the footer and compiled before the rest of the code in home.scss. Now if you check home.css you shouldn't see repeated code

When at first you write the color variables in footer you will receive an error because they are not defined, but it disappear when you import footer in home.scss

Alessandro
  • 99
  • 2
  • 9
0

If you @import the same SASS file (e.g. variables.sass) in multiple files and then @import those files in the one main.sass file, the resulting main.css file will contain the content of variables multiple times.

A good way of structuring SASS files is to obey the rule of importing each file only once. Iconic architecture is the 7-1 Pattern. You basically decompose your SASS files into atomic parts and then import those in appropriate order only once in the main file.

BlueManCZ
  • 417
  • 6
  • 12