New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One time imports #139

Open
chriseppstein opened this Issue Jul 15, 2011 · 76 comments

Comments

Projects
None yet
@chriseppstein
Member

chriseppstein commented Jul 15, 2011

We need a way to import library files just a single time. The @import statement is basically like ruby's load directive, but I think we need an import with ruby's require semantics (does nothing if it's been imported already).

What do you think about @depend?

@MarioRicalde

This comment has been minimized.

Show comment
Hide comment
@MarioRicalde

MarioRicalde Jul 15, 2011

This would be for performance, right?

I can think of this being useful on big packages that have one file that does lots of includes.

MarioRicalde commented Jul 15, 2011

This would be for performance, right?

I can think of this being useful on big packages that have one file that does lots of includes.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Jul 15, 2011

Member

Yes. performance is a big part, it allows each module to be used in isolation without a performance penalty. It also makes it easier to override mixins because they won't be re-parsed later if you define the override after the first time it's loaded.

Member

chriseppstein commented Jul 15, 2011

Yes. performance is a big part, it allows each module to be used in isolation without a performance penalty. It also makes it easier to override mixins because they won't be re-parsed later if you define the override after the first time it's loaded.

@MarioRicalde

This comment has been minimized.

Show comment
Hide comment
@MarioRicalde

MarioRicalde Jul 15, 2011

I like that last part.. making overriding easier would be great.

MarioRicalde commented Jul 15, 2011

I like that last part.. making overriding easier would be great.

@anthonyshort

This comment has been minimized.

Show comment
Hide comment
@anthonyshort

anthonyshort Aug 16, 2011

Definitely. This is something I've been seeing a need for lately as well. It would be super handy.

anthonyshort commented Aug 16, 2011

Definitely. This is something I've been seeing a need for lately as well. It would be super handy.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 16, 2011

Member

Marked #156 as a duplicate of this issue.

Member

chriseppstein commented Aug 16, 2011

Marked #156 as a duplicate of this issue.

@seanofw

This comment has been minimized.

Show comment
Hide comment
@seanofw

seanofw Aug 17, 2011

Copying my proposal from the other thread: I propose adding an @import-once directive that can be dropped into the imported file, as the first statement in that file. It takes no parameters:

@import-once;

This is a safer directive than the @import-vs-@require solution, since it ensures that the imported file can't be accidentally imported wrong; if it was designed to be imported only once, it can assert that itself, and a caller need not know its behavior to be able to use it correctly.

seanofw commented Aug 17, 2011

Copying my proposal from the other thread: I propose adding an @import-once directive that can be dropped into the imported file, as the first statement in that file. It takes no parameters:

@import-once;

This is a safer directive than the @import-vs-@require solution, since it ensures that the imported file can't be accidentally imported wrong; if it was designed to be imported only once, it can assert that itself, and a caller need not know its behavior to be able to use it correctly.

@seanofw

This comment has been minimized.

Show comment
Hide comment
@seanofw

seanofw Aug 18, 2011

Oh, the other thing in the other thread: If anybody needs it, I have a cute workaround involving adding a @function and an @if statement in the right places; it produces results that are very much like @import-once would produce. It's not perfect, but it does work. You can find my solution here: #156

seanofw commented Aug 18, 2011

Oh, the other thing in the other thread: If anybody needs it, I have a cute workaround involving adding a @function and an @if statement in the right places; it produces results that are very much like @import-once would produce. It's not perfect, but it does work. You can find my solution here: #156

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 22, 2011

Member

@seanofw Can you please provide the use case of a file that is "designed to be imported only once"?

Member

chriseppstein commented Aug 22, 2011

@seanofw Can you please provide the use case of a file that is "designed to be imported only once"?

@ZeeAgency

This comment has been minimized.

Show comment
Hide comment
@ZeeAgency

ZeeAgency commented Sep 29, 2011

+1 for @depend

@seanofw

This comment has been minimized.

Show comment
Hide comment
@seanofw

seanofw Sep 30, 2011

@chriseppstein: The best example I can give is a diamond-style dependency pattern, which occurs in larger software.

So let's say you have these four files in a big system that's been well-factored into small units:

  • _DropDownMenu.scss
  • _CarModelPicker.scss: @import "DropDownMenu";
  • _ColorPicker.scss: @import "DropDownMenu";
  • FindACarPage.scss: @import "CarModelPicker"; @import "ColorPicker";

So "DropDownMenu" has the stylings for general, shared dropdown menus that appear when somebody clicks a dropdown button. "CarModelPicker" is the layout for a frequently-reused blob of markup that, say, lets a user choose a car by its year and make and model, and that markup contains dropdown menus. "ColorPicker" is the layout for a frequently-reused blob of markup that lets a user choose a color, and that markup also contains dropdown menus. Finally, the "FindACar" page displays both a model-picker and a color-picker to let a user find a car.

See the problem? On the "FindACar" page, if you don't design "DropDownMenu" to be imported only once, you'll get the same dropdown-menu CSS generated twice --- two different places in the same resulting FindACar.css file. You don't need to use @Mixins or anything fancier than @import to demonstrate the problem.

In a large system where the CSS has been heavily sliced-and-diced like this --- like our flagship application with 1.2 million lines of code in it --- the @imports of a single page can end up both broad and deep. It's possible for the same page to unknowingly import, say, "_Links.scss" twenty times, because from the page's perspective, it's listing out its dependencies, and each of those dependencies are listing theirs, and so on until you get to a few base styles that nearly everybody needs.

For a small application, this isn't an issue anyone would notice; but for a big application like ours, avoiding redundant imports is absolutely critical.

seanofw commented Sep 30, 2011

@chriseppstein: The best example I can give is a diamond-style dependency pattern, which occurs in larger software.

So let's say you have these four files in a big system that's been well-factored into small units:

  • _DropDownMenu.scss
  • _CarModelPicker.scss: @import "DropDownMenu";
  • _ColorPicker.scss: @import "DropDownMenu";
  • FindACarPage.scss: @import "CarModelPicker"; @import "ColorPicker";

So "DropDownMenu" has the stylings for general, shared dropdown menus that appear when somebody clicks a dropdown button. "CarModelPicker" is the layout for a frequently-reused blob of markup that, say, lets a user choose a car by its year and make and model, and that markup contains dropdown menus. "ColorPicker" is the layout for a frequently-reused blob of markup that lets a user choose a color, and that markup also contains dropdown menus. Finally, the "FindACar" page displays both a model-picker and a color-picker to let a user find a car.

See the problem? On the "FindACar" page, if you don't design "DropDownMenu" to be imported only once, you'll get the same dropdown-menu CSS generated twice --- two different places in the same resulting FindACar.css file. You don't need to use @Mixins or anything fancier than @import to demonstrate the problem.

In a large system where the CSS has been heavily sliced-and-diced like this --- like our flagship application with 1.2 million lines of code in it --- the @imports of a single page can end up both broad and deep. It's possible for the same page to unknowingly import, say, "_Links.scss" twenty times, because from the page's perspective, it's listing out its dependencies, and each of those dependencies are listing theirs, and so on until you get to a few base styles that nearly everybody needs.

For a small application, this isn't an issue anyone would notice; but for a big application like ours, avoiding redundant imports is absolutely critical.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Sep 30, 2011

Member

@seanofw I totally understand this pattern and complex structure. My own site is quite complex. but I don't understand why _DropDownMenu.scss should be the one to declare it's importing behavior instead of the caller.

Member

chriseppstein commented Sep 30, 2011

@seanofw I totally understand this pattern and complex structure. My own site is quite complex. but I don't understand why _DropDownMenu.scss should be the one to declare it's importing behavior instead of the caller.

@seanofw

This comment has been minimized.

Show comment
Hide comment
@seanofw

seanofw Oct 5, 2011

@chriseppstein: The answer is because of the potential for misuse. I work in a large software shop, and believe me, even among really smart, capable coders, if somebody can do it wrong, they will do it wrong.

By making _DropDownMenu.scss the one to declare "You can only import me once," you don't give anybody the option of screwing it up and importing it six times; you can't do it wrong even if you want to. But if _CarModelPicker.scss and _ColorPicker.scss are the ones that are responsible for saying, "Only import DropDownMenu once," that provides two points for failure instead of one: It's two different places where somebody can --- and will --- screw it up. And in a large system, two points for failure quickly become twenty, and those twenty quickly become two hundred.

Putting it inside _DropDownMenu.scss is a form of encapsulation, to use an OO term; _DropDownMenu.scss is then guarding itself against misuse.

Another thing to consider: Is there ever a scenario when it makes sense for a single .scss file to be able to both be imported many times by some callers and only once by others? Is there any scenario where that's sane, desirable behavior? If the answer is no (and I think it's no), then the system should guard against it, because that then must be an accident --- undesirable behavior --- if it happens.

seanofw commented Oct 5, 2011

@chriseppstein: The answer is because of the potential for misuse. I work in a large software shop, and believe me, even among really smart, capable coders, if somebody can do it wrong, they will do it wrong.

By making _DropDownMenu.scss the one to declare "You can only import me once," you don't give anybody the option of screwing it up and importing it six times; you can't do it wrong even if you want to. But if _CarModelPicker.scss and _ColorPicker.scss are the ones that are responsible for saying, "Only import DropDownMenu once," that provides two points for failure instead of one: It's two different places where somebody can --- and will --- screw it up. And in a large system, two points for failure quickly become twenty, and those twenty quickly become two hundred.

Putting it inside _DropDownMenu.scss is a form of encapsulation, to use an OO term; _DropDownMenu.scss is then guarding itself against misuse.

Another thing to consider: Is there ever a scenario when it makes sense for a single .scss file to be able to both be imported many times by some callers and only once by others? Is there any scenario where that's sane, desirable behavior? If the answer is no (and I think it's no), then the system should guard against it, because that then must be an accident --- undesirable behavior --- if it happens.

@jacobrask

This comment has been minimized.

Show comment
Hide comment
@jacobrask

jacobrask Mar 16, 2012

Contributor

Is depend used in any other language? Using require or import-once would make it familiar to developers from other languages, the latter being the most obvious and very unlikely for anyone to use by mistake.

Contributor

jacobrask commented Mar 16, 2012

Is depend used in any other language? Using require or import-once would make it familiar to developers from other languages, the latter being the most obvious and very unlikely for anyone to use by mistake.

@verekia

This comment has been minimized.

Show comment
Hide comment
@verekia

verekia Apr 3, 2012

This feature seems fundamental for having clean re-usable code in an architecture with inheritance. I wish I had it even for this very simple use case.

Plus, I agree with @jacobrask, and think require and import-once are particularly clear and intuitive.

verekia commented Apr 3, 2012

This feature seems fundamental for having clean re-usable code in an architecture with inheritance. I wish I had it even for this very simple use case.

Plus, I agree with @jacobrask, and think require and import-once are particularly clear and intuitive.

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Apr 3, 2012

What about @import "stuff" !once; ?

MoOx commented Apr 3, 2012

What about @import "stuff" !once; ?

@ianstormtaylor

This comment has been minimized.

Show comment
Hide comment
@ianstormtaylor

ianstormtaylor Jul 31, 2012

+1 for require, this would make working with modules much easier
-1 for forcing the callee to declare its import preference

ianstormtaylor commented Jul 31, 2012

+1 for require, this would make working with modules much easier
-1 for forcing the callee to declare its import preference

@arbales

This comment has been minimized.

Show comment
Hide comment
@arbales

arbales Sep 14, 2012

Being unable to do this in a large modular codebase is a bummer. We ship different combinations of "modules" to our primary web client that we do to secondary clients (widgets, gadgets, etc).

When _buttons.css.sass begins to depend on _gradients.css.sass, but _gradients.css.sass is included on a per-package level (application.sass, gadget.sass,…) to avoid multiple imports, every change in dependencies requires tabulation by the developer or building every package.

I also think allowing the callee to specify this behavior would be interesting, if not expected.

arbales commented Sep 14, 2012

Being unable to do this in a large modular codebase is a bummer. We ship different combinations of "modules" to our primary web client that we do to secondary clients (widgets, gadgets, etc).

When _buttons.css.sass begins to depend on _gradients.css.sass, but _gradients.css.sass is included on a per-package level (application.sass, gadget.sass,…) to avoid multiple imports, every change in dependencies requires tabulation by the developer or building every package.

I also think allowing the callee to specify this behavior would be interesting, if not expected.

@ianstormtaylor

This comment has been minimized.

Show comment
Hide comment
@ianstormtaylor

ianstormtaylor Sep 15, 2012

The more I try to develop modular components in SASS the more this feature becomes necessary to not have to deal with the order of dependencies by hand in my main.sass which is easy to screw up and no one wants to maintain comments for.

Letting files require whatever dependencies they need makes things much more obvious than having everything imported once into main.sass. It's the equivalent of storing all of your components as globals in Javascript instead of using something modular like AMD—which makes over-reaching/tight-coupling easy to do by accident, and in general just leads to more tangled code.

So, +1 this a lot.

ianstormtaylor commented Sep 15, 2012

The more I try to develop modular components in SASS the more this feature becomes necessary to not have to deal with the order of dependencies by hand in my main.sass which is easy to screw up and no one wants to maintain comments for.

Letting files require whatever dependencies they need makes things much more obvious than having everything imported once into main.sass. It's the equivalent of storing all of your components as globals in Javascript instead of using something modular like AMD—which makes over-reaching/tight-coupling easy to do by accident, and in general just leads to more tangled code.

So, +1 this a lot.

@zakness

This comment has been minimized.

Show comment
Hide comment
@zakness

zakness Oct 24, 2012

Having to include @import-once; in the importee would theoretically reduce the points of possible failure, but it also has the (in my opinion, huge) downside of making the behavior of @import inconsistent. The developer importing files now has to know whether or not the files they're importing expect to be imported once or N times.

I like @depend because it conveys a dependency, which I believe is the main use case for this feature. When I see @require I think of PHP's require function, which does not convey onceness (but that’s probably just because I’m not a Ruby guy :P).

I’m curious, what are some example use cases for importing files multiple times? I’ve worked on large and small projects and this was never something I or my team wanted. Would you consider changing the @import directive itself to always import once?

zakness commented Oct 24, 2012

Having to include @import-once; in the importee would theoretically reduce the points of possible failure, but it also has the (in my opinion, huge) downside of making the behavior of @import inconsistent. The developer importing files now has to know whether or not the files they're importing expect to be imported once or N times.

I like @depend because it conveys a dependency, which I believe is the main use case for this feature. When I see @require I think of PHP's require function, which does not convey onceness (but that’s probably just because I’m not a Ruby guy :P).

I’m curious, what are some example use cases for importing files multiple times? I’ve worked on large and small projects and this was never something I or my team wanted. Would you consider changing the @import directive itself to always import once?

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Dec 18, 2012

+1000 for this.

thejase commented Dec 18, 2012

+1000 for this.

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jan 18, 2013

I'm with @zakness, importing a file more than once is the odd scenario. Makes more sense to me going with changing @import to only import once and make @include "filename" include the file no matter what.

svallory commented Jan 18, 2013

I'm with @zakness, importing a file more than once is the odd scenario. Makes more sense to me going with changing @import to only import once and make @include "filename" include the file no matter what.

@neekey

This comment has been minimized.

Show comment
Hide comment
@neekey

neekey Jan 29, 2013

+1 for this feature like @import-once, because when you import a extend-only class multiple times( by mistake... ) , than it will be compiled multiple times... which is exactly not what we want.

neekey commented Jan 29, 2013

+1 for this feature like @import-once, because when you import a extend-only class multiple times( by mistake... ) , than it will be compiled multiple times... which is exactly not what we want.

@Snugug

This comment has been minimized.

Show comment
Hide comment
@Snugug

Snugug Jan 29, 2013

Contributor

@svallory except that @include is already a keyword for mixins in the Scss format and absolutely should not be repurposed for @import-once or some such.

Contributor

Snugug commented Jan 29, 2013

@svallory except that @include is already a keyword for mixins in the Scss format and absolutely should not be repurposed for @import-once or some such.

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Jan 29, 2013

+1 to @MoOx's suggestion: @import 'file' !once;

thejase commented Jan 29, 2013

+1 to @MoOx's suggestion: @import 'file' !once;

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jan 31, 2013

@Snugug That's kinda the motive behind my suggestion. You see, mixins can be included multiple times. It's already known how @include 'mixing' works. So, by analogy, @include 'file' would work the same way. You may think conflicting files and mixin names would be a problem, but since the context is mutually exclusive, i.e. you always use a @include mixin inside a rule and @include file outside one, it shouldn't be a problem at all.

svallory commented Jan 31, 2013

@Snugug That's kinda the motive behind my suggestion. You see, mixins can be included multiple times. It's already known how @include 'mixing' works. So, by analogy, @include 'file' would work the same way. You may think conflicting files and mixin names would be a problem, but since the context is mutually exclusive, i.e. you always use a @include mixin inside a rule and @include file outside one, it shouldn't be a problem at all.

@Snugug

This comment has been minimized.

Show comment
Hide comment
@Snugug

Snugug Jan 31, 2013

Contributor

@svallory That's a dangerous, and in fact incorrect, assumption to make. Mixins absolutely do not need to be included inside a rule, and there are many many "setup" mixins that you in fact specifically do not include inside a rule. Take, for example, Compass' establish-baseline mixin which writes the selectors it needs.

Moreover, I firmly believe that the mental model behind a mixin and a file are different enough that context alone isn't a good enough indicator alone of what you mean to do, especially in the case of files that include mixins of the same name. Take a CSS Normalize file as a for instance. The logical name of the file would probably _normalize.s*ss, and that file contains @mixin normalize and @mixin normalize-legacy. When I call @include normalize, what should I expect to happen? Should I expect the file to be imported again? Should it be the mixin? Both should really only be imported/used once, and both should be written at doc root (outside of a selector).

I personally like @MoOx's !once suggestion as it's a common enough pattern throughout Sass that I think it's a good fit (we've got !default for variables and !optional for extends).

Contributor

Snugug commented Jan 31, 2013

@svallory That's a dangerous, and in fact incorrect, assumption to make. Mixins absolutely do not need to be included inside a rule, and there are many many "setup" mixins that you in fact specifically do not include inside a rule. Take, for example, Compass' establish-baseline mixin which writes the selectors it needs.

Moreover, I firmly believe that the mental model behind a mixin and a file are different enough that context alone isn't a good enough indicator alone of what you mean to do, especially in the case of files that include mixins of the same name. Take a CSS Normalize file as a for instance. The logical name of the file would probably _normalize.s*ss, and that file contains @mixin normalize and @mixin normalize-legacy. When I call @include normalize, what should I expect to happen? Should I expect the file to be imported again? Should it be the mixin? Both should really only be imported/used once, and both should be written at doc root (outside of a selector).

I personally like @MoOx's !once suggestion as it's a common enough pattern throughout Sass that I think it's a good fit (we've got !default for variables and !optional for extends).

@arbales

This comment has been minimized.

Show comment
Hide comment
@arbales

arbales Jan 31, 2013

The @include debate isn't relevant for me since I use (and will forever
use) indented Sass, but for the sake of simplicity, clarity, and
universality, @require seems like the right call to me.

I'm more interested in seeing this happen than I am attached to any
specific implementation or semantics though!

On Thursday, January 31, 2013, Snugug wrote:

@svallory https://github.com/svallory That's a dangerous, and in fact
incorrect, assumption to make. Mixins absolutely do not need to be included
inside a rule, and there are many many "setup" mixins that you in fact
specifically do not include inside a rule. Take, for example, Compass'
establish-baseline mixinhttp://compass-style.org/reference/compass/typography/vertical_rhythm/#mixin-establish-baselinewhich writes the selectors it needs.

Moreover, I firmly believe that the mental model behind a mixin and a file
are different enough that context alone isn't a good enough indicator alone
of what you mean to do, especially in the case of files that include mixins
of the same name. Take a CSS Normalize file as a for instance. The logical
name of the file would probably _normalize.s*ss, and that file contains @mixin
normalize and @mixin normalize-legacy. When I call @include normalize,
what should I expect to happen? Should I expect the file to be imported
again? Should it be the mixin? Both should really only be imported/used
once, and both should be written at doc root (outside of a selector).

I personally like @MoOx https://github.com/MoOx's !once suggestion as
it's a common enough pattern throughout Sass that I think it's a good fit
(we've got !default for variables and !optional for extends).


Reply to this email directly or view it on GitHubhttps://github.com/sass/sass/issues/139#issuecomment-12947011.

arbales commented Jan 31, 2013

The @include debate isn't relevant for me since I use (and will forever
use) indented Sass, but for the sake of simplicity, clarity, and
universality, @require seems like the right call to me.

I'm more interested in seeing this happen than I am attached to any
specific implementation or semantics though!

On Thursday, January 31, 2013, Snugug wrote:

@svallory https://github.com/svallory That's a dangerous, and in fact
incorrect, assumption to make. Mixins absolutely do not need to be included
inside a rule, and there are many many "setup" mixins that you in fact
specifically do not include inside a rule. Take, for example, Compass'
establish-baseline mixinhttp://compass-style.org/reference/compass/typography/vertical_rhythm/#mixin-establish-baselinewhich writes the selectors it needs.

Moreover, I firmly believe that the mental model behind a mixin and a file
are different enough that context alone isn't a good enough indicator alone
of what you mean to do, especially in the case of files that include mixins
of the same name. Take a CSS Normalize file as a for instance. The logical
name of the file would probably _normalize.s*ss, and that file contains @mixin
normalize and @mixin normalize-legacy. When I call @include normalize,
what should I expect to happen? Should I expect the file to be imported
again? Should it be the mixin? Both should really only be imported/used
once, and both should be written at doc root (outside of a selector).

I personally like @MoOx https://github.com/MoOx's !once suggestion as
it's a common enough pattern throughout Sass that I think it's a good fit
(we've got !default for variables and !optional for extends).


Reply to this email directly or view it on GitHubhttps://github.com/sass/sass/issues/139#issuecomment-12947011.

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jan 31, 2013

@Snugug thank you for your comment. I missed that point. I have nothing more to say than I totally agree with you.

svallory commented Jan 31, 2013

@Snugug thank you for your comment. I missed that point. I have nothing more to say than I totally agree with you.

@kottenator

This comment has been minimized.

Show comment
Hide comment
@kottenator

kottenator Feb 15, 2013

Besides, LESS has both @import and @import-once, but from v.1.4 they want to make default @import logic as @import-once (and to remove the second one).

Maybe it's good to do the same in SASS / SCSS?

kottenator commented Feb 15, 2013

Besides, LESS has both @import and @import-once, but from v.1.4 they want to make default @import logic as @import-once (and to remove the second one).

Maybe it's good to do the same in SASS / SCSS?

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Feb 15, 2013

I agree. Does anybody use @import "file" more than one time ?!

On Friday, February 15, 2013, Rostyslav Bryzgunov wrote:

Besides, LESS has both @import https://github.com/import and
@import-once, but from v.1.4 they want to make default @importhttps://github.com/importlogic as @import-once (and to remove the second one).

Maybe it's good to do the same in SASS / SCSS?


Reply to this email directly or view it on GitHubhttps://github.com/sass/sass/issues/139#issuecomment-13602694.

MoOx commented Feb 15, 2013

I agree. Does anybody use @import "file" more than one time ?!

On Friday, February 15, 2013, Rostyslav Bryzgunov wrote:

Besides, LESS has both @import https://github.com/import and
@import-once, but from v.1.4 they want to make default @importhttps://github.com/importlogic as @import-once (and to remove the second one).

Maybe it's good to do the same in SASS / SCSS?


Reply to this email directly or view it on GitHubhttps://github.com/sass/sass/issues/139#issuecomment-13602694.

@zakdances

This comment has been minimized.

Show comment
Hide comment
@zakdances

zakdances Mar 12, 2013

Sass definitely needs an "@require" or something equivalent. It shouldn't force the "_name.scss" convention just to avoid duplicates. It's been 2 years...

zakdances commented Mar 12, 2013

Sass definitely needs an "@require" or something equivalent. It shouldn't force the "_name.scss" convention just to avoid duplicates. It's been 2 years...

@octplane

This comment has been minimized.

Show comment
Hide comment
@octplane

octplane Mar 15, 2013

In my case, the main application CSS is 8000 lines long and contains more or less 1092 selectors, of which 400 are repeated twice or more once sass has run. This is partly due to the way @import works by reimporting all its dependencies everytime we call it on a scss.

I'd have expected some kind of way to prevent that. My concerns are:

  • generated size of the computed css
  • ability to debug the generated css: right now, because of the inclusion, most of my element matchs the same selector twice in the final css, the second one overriding every attribute of the first one, leading to poor visibility and high WAT-attitude among developpers.

octplane commented Mar 15, 2013

In my case, the main application CSS is 8000 lines long and contains more or less 1092 selectors, of which 400 are repeated twice or more once sass has run. This is partly due to the way @import works by reimporting all its dependencies everytime we call it on a scss.

I'd have expected some kind of way to prevent that. My concerns are:

  • generated size of the computed css
  • ability to debug the generated css: right now, because of the inclusion, most of my element matchs the same selector twice in the final css, the second one overriding every attribute of the first one, leading to poor visibility and high WAT-attitude among developpers.
@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen Apr 23, 2013

👍 aside from being able to perform a nested import:

.foo
  @import bar

I don't see many reasons that @import should behave the way it does. I'd be fine switching to @require or @import-once but I would imagine that I and most people would just replace all of them. In other words, I think we should swap to "import once" behavior by default.

aaronjensen commented Apr 23, 2013

👍 aside from being able to perform a nested import:

.foo
  @import bar

I don't see many reasons that @import should behave the way it does. I'd be fine switching to @require or @import-once but I would imagine that I and most people would just replace all of them. In other words, I think we should swap to "import once" behavior by default.

@cimmanon

This comment has been minimized.

Show comment
Hide comment
@cimmanon

cimmanon Apr 23, 2013

@aaronjensen What would be the benefit to breaking cases where importing a file multiple times is exactly what is expected (because that's how it worked before) by making "import once" the default behavior? In a perfect world, a user shouldn't upgrade Sass and find out that it broke all of their code.

cimmanon commented Apr 23, 2013

@aaronjensen What would be the benefit to breaking cases where importing a file multiple times is exactly what is expected (because that's how it worked before) by making "import once" the default behavior? In a perfect world, a user shouldn't upgrade Sass and find out that it broke all of their code.

@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen Apr 23, 2013

@cimmanon It's obviously up to the breaking change policy of the project. Maybe that's a major version thing, maybe it doesn't make sense to break ever. I doubt there are too many people that rely on that behavior knowingly but I'm sure given the nature of css there are plenty that rely on it unknowingly and it would be a hard to figure out thing in that case. If the desire is to go for the non-breaking change that's no skin off my back, but I'd recommend updating docs and examples to use that as the default.

aaronjensen commented Apr 23, 2013

@cimmanon It's obviously up to the breaking change policy of the project. Maybe that's a major version thing, maybe it doesn't make sense to break ever. I doubt there are too many people that rely on that behavior knowingly but I'm sure given the nature of css there are plenty that rely on it unknowingly and it would be a hard to figure out thing in that case. If the desire is to go for the non-breaking change that's no skin off my back, but I'd recommend updating docs and examples to use that as the default.

@beresmate

This comment has been minimized.

Show comment
Hide comment
@beresmate

beresmate commented May 28, 2013

+1

@marquis

This comment has been minimized.

Show comment
Hide comment
@marquis

marquis May 31, 2013

+1. The redundant CSS not only affects performance and debugging, but for us pushed our total selector count past IE's max, breaking our site for those users.

marquis commented May 31, 2013

+1. The redundant CSS not only affects performance and debugging, but for us pushed our total selector count past IE's max, breaking our site for those users.

@alecperkins

This comment has been minimized.

Show comment
Hide comment
@alecperkins

alecperkins Jun 8, 2013

+1. The @extend and %placeholder capabilities beg for an import-once feature. It's unintuitive for the rewritten selectors to be duplicated (though makes sense after thinking about how import and placeholders work). Also, it's sloppy to need a different file describe the dependencies of a module to avoid duplication. @require is a good name, keeping @import consistent with how it is now (both in Sass and CSS).

alecperkins commented Jun 8, 2013

+1. The @extend and %placeholder capabilities beg for an import-once feature. It's unintuitive for the rewritten selectors to be duplicated (though makes sense after thinking about how import and placeholders work). Also, it's sloppy to need a different file describe the dependencies of a module to avoid duplication. @require is a good name, keeping @import consistent with how it is now (both in Sass and CSS).

@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen commented Jun 24, 2013

@svallory that'd be great.

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jun 24, 2013

Ok, here it goes: https://gist.github.com/svallory/5850711 But I really can't tell you how well it will work now. Also, I don't remember how to replace the sass default importer by this one, but it shouldn't be too hard. It's fundamental that this is the only importer in use.

svallory commented Jun 24, 2013

Ok, here it goes: https://gist.github.com/svallory/5850711 But I really can't tell you how well it will work now. Also, I don't remember how to replace the sass default importer by this one, but it shouldn't be too hard. It's fundamental that this is the only importer in use.

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jun 24, 2013

Btw, liftr is a half-way project I had to stop working on. Don't bother by the references to the name in the code. I left it there because it shows how you can customize path resolution inside the importer.

svallory commented Jun 24, 2013

Btw, liftr is a half-way project I had to stop working on. Don't bother by the references to the name in the code. I left it there because it shows how you can customize path resolution inside the importer.

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Jun 25, 2013

If anyone is able to get this working, can you post the steps?

On Mon, Jun 24, 2013 at 8:12 AM, Saulo Vallory notifications@github.com
wrote:

Btw, liftr is a half-way project I had to stop working on. Don't bother by the references to the name in the code. I left it there because it shows how you can customize path resolution inside the importer.

Reply to this email directly or view it on GitHub:
#139 (comment)

thejase commented Jun 25, 2013

If anyone is able to get this working, can you post the steps?

On Mon, Jun 24, 2013 at 8:12 AM, Saulo Vallory notifications@github.com
wrote:

Btw, liftr is a half-way project I had to stop working on. Don't bother by the references to the name in the code. I left it there because it shows how you can customize path resolution inside the importer.

Reply to this email directly or view it on GitHub:
#139 (comment)

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Jun 26, 2013

I just pushed a working command line tool to https://github.com/theblacksmith/smartsass tested with Sass 3.2.9. In other setups, like compass or rails, you'll need another way to pass the :filesystem_importer option.

I'm sure the tool is pretty rough around the edges and it would be great if someone could review the code. I'm not a ruby developer, I learned it just to create this importer so forgive me for any sins I may have committed in the code.

Cheers!

svallory commented Jun 26, 2013

I just pushed a working command line tool to https://github.com/theblacksmith/smartsass tested with Sass 3.2.9. In other setups, like compass or rails, you'll need another way to pass the :filesystem_importer option.

I'm sure the tool is pretty rough around the edges and it would be great if someone could review the code. I'm not a ruby developer, I learned it just to create this importer so forgive me for any sins I may have committed in the code.

Cheers!

@fedotxxl

This comment has been minimized.

Show comment
Hide comment
@fedotxxl

fedotxxl Jul 4, 2013

+1. Pls implement this feature

fedotxxl commented Jul 4, 2013

+1. Pls implement this feature

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Aug 29, 2013

Contributor

I can't express how critical this feature is for developing large, modular frameworks without duplicate output.

The current @import semantics aren't intuitive and, I may be wrong here, I believe web browsers dedupe @import's in css.

Contributor

xzyfer commented Aug 29, 2013

I can't express how critical this feature is for developing large, modular frameworks without duplicate output.

The current @import semantics aren't intuitive and, I may be wrong here, I believe web browsers dedupe @import's in css.

@benschwarz

This comment has been minimized.

Show comment
Hide comment
@benschwarz

benschwarz Aug 29, 2013

Aiming at being objective here:

  • Changing @import is a seriously breaking change, it will not happen.
  • +1ing doesn't add anything to the conversation.

Do we have a clear proposal / suggestion that @chriseppstein or @nex3 have agreed with? Is there an actionable development path?

If you've got an opinion, I suggest that you submit a proposal… if its solid, and simple, it'll get agreed upon.

2 year old issues don't resolve themselves without buy-in, folks.

benschwarz commented Aug 29, 2013

Aiming at being objective here:

  • Changing @import is a seriously breaking change, it will not happen.
  • +1ing doesn't add anything to the conversation.

Do we have a clear proposal / suggestion that @chriseppstein or @nex3 have agreed with? Is there an actionable development path?

If you've got an opinion, I suggest that you submit a proposal… if its solid, and simple, it'll get agreed upon.

2 year old issues don't resolve themselves without buy-in, folks.

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Aug 29, 2013

Contributor

As it stands the current work arounds aren't all the great as they stand if your intending to distribute you project in a similar fashion to the bootstrap sass port.

People looking for a solution now may want to look at https://gist.github.com/courtsimas/1167053.
Someone kindly built an implementation of the above solution https://github.com/wilsonpage/sass-import-once/blob/master/sass-import-once.scss. Hopefully these will ease the pain of waiting for 4.x.

What could make these approaches cleaner is existences checks (#821) 👍

Contributor

xzyfer commented Aug 29, 2013

As it stands the current work arounds aren't all the great as they stand if your intending to distribute you project in a similar fashion to the bootstrap sass port.

People looking for a solution now may want to look at https://gist.github.com/courtsimas/1167053.
Someone kindly built an implementation of the above solution https://github.com/wilsonpage/sass-import-once/blob/master/sass-import-once.scss. Hopefully these will ease the pain of waiting for 4.x.

What could make these approaches cleaner is existences checks (#821) 👍

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 6, 2013

@xzyfer That is an incredible find! I would say the first solution is better (except the lack of a !default suffix), because you can use %placeholders inside it. They aren't allowed inside mixins. That was my main argument for "import-once." Wooooohoooooo!

Totally now using this on JSMACSS!!!!

thejase commented Sep 6, 2013

@xzyfer That is an incredible find! I would say the first solution is better (except the lack of a !default suffix), because you can use %placeholders inside it. They aren't allowed inside mixins. That was my main argument for "import-once." Wooooohoooooo!

Totally now using this on JSMACSS!!!!

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Sep 6, 2013

Contributor

I'd suggest having a quick look at this before going to crazy with place holders https://gist.github.com/xzyfer/6394659. If you take the final sass example and try to use media queries you'll run into a deprecation warning. I personally think deprecating @extending placeholders in media queries is a backwards move, although it makes sense for @extending normal selectors.

There's an example of a workaround here (#905) which from memory works as expected, inserting the placeholder content within the media query context, in 2.3.10 even thought it throws a deprecation warning.

Contributor

xzyfer commented Sep 6, 2013

I'd suggest having a quick look at this before going to crazy with place holders https://gist.github.com/xzyfer/6394659. If you take the final sass example and try to use media queries you'll run into a deprecation warning. I personally think deprecating @extending placeholders in media queries is a backwards move, although it makes sense for @extending normal selectors.

There's an example of a workaround here (#905) which from memory works as expected, inserting the placeholder content within the media query context, in 2.3.10 even thought it throws a deprecation warning.

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 6, 2013

Eh, I generally keep most of my placeholders on a mobile-first context, meaning they apply to all. I try not to complicate that part too much.

thejase commented Sep 6, 2013

Eh, I generally keep most of my placeholders on a mobile-first context, meaning they apply to all. I try not to complicate that part too much.

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 6, 2013

Give it 10 years and we'll see native placeholders for CSS... guaranteed.

thejase commented Sep 6, 2013

Give it 10 years and we'll see native placeholders for CSS... guaranteed.

@xzyfer

This comment has been minimized.

Show comment
Hide comment
@xzyfer

xzyfer Sep 6, 2013

Contributor

Can you please elaborate further?
AFAIK you cannot extend a placeholder inside a media query unless it was defined within that media query. Although sass currently allows this, and does the right thing, it throws deprecation warnings stating it'll no longer function in 3.3

Contributor

xzyfer commented Sep 6, 2013

Can you please elaborate further?
AFAIK you cannot extend a placeholder inside a media query unless it was defined within that media query. Although sass currently allows this, and does the right thing, it throws deprecation warnings stating it'll no longer function in 3.3

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

hello all, this issue is quite old. I've just reported a duplicated of this #928 .
Is there a fix for this in the near future??

brauliobo commented Sep 28, 2013

hello all, this issue is quite old. I've just reported a duplicated of this #928 .
Is there a fix for this in the near future??

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 28, 2013

xzyfer: I just mean that I try not to create placeholders that would need to be overwritten in MQs.

brauliobo: read through for an import-once function.

thejase commented Sep 28, 2013

xzyfer: I just mean that I try not to create placeholders that would need to be overwritten in MQs.

brauliobo: read through for an import-once function.

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

@thejase: @import-once is integrated into the official code?

brauliobo commented Sep 28, 2013

@thejase: @import-once is integrated into the official code?

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

pasting https://gist.github.com/courtsimas/1167053 before including anything isn't nice. this or another solution should be on the sass core code

brauliobo commented Sep 28, 2013

pasting https://gist.github.com/courtsimas/1167053 before including anything isn't nice. this or another solution should be on the sass core code

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 28, 2013

Why is it not nice?  It is actually safer and more specific (you specify you should only include this once in the actual file). 

And no. No official support yet. But I actually feel this is safer than a native @import-once. 


Sent from Mailbox for iPhone

On Sat, Sep 28, 2013 at 9:10 AM, Bráulio Bhavamitra
notifications@github.com wrote:

pasting https://gist.github.com/courtsimas/1167053 before including anything isn't nice. this or another solution should be on the sass core code

Reply to this email directly or view it on GitHub:
#139 (comment)

thejase commented Sep 28, 2013

Why is it not nice?  It is actually safer and more specific (you specify you should only include this once in the actual file). 

And no. No official support yet. But I actually feel this is safer than a native @import-once. 


Sent from Mailbox for iPhone

On Sat, Sep 28, 2013 at 9:10 AM, Bráulio Bhavamitra
notifications@github.com wrote:

pasting https://gist.github.com/courtsimas/1167053 before including anything isn't nice. this or another solution should be on the sass core code

Reply to this email directly or view it on GitHub:
#139 (comment)

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

it is not nice because it adds more than 10 lines of code in each sass file I need it.

brauliobo commented Sep 28, 2013

it is not nice because it adds more than 10 lines of code in each sass file I need it.

@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen Sep 28, 2013

How would it be "safer"? The gist is clever, but it's a total hack in my opinion. For one, it requires you to wrap each file you want to be able to protect in an if, so you couldn't use it w/ any files you don't own, for another it requires you to litter your top level files w/ that function code. I'm holding out for a native version.

aaronjensen commented Sep 28, 2013

How would it be "safer"? The gist is clever, but it's a total hack in my opinion. For one, it requires you to wrap each file you want to be able to protect in an if, so you couldn't use it w/ any files you don't own, for another it requires you to litter your top level files w/ that function code. I'm holding out for a native version.

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

@aaronjensen +1 for a native version. it is very needed. the sass developers are considering this??

brauliobo commented Sep 28, 2013

@aaronjensen +1 for a native version. it is very needed. the sass developers are considering this??

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 28, 2013

Safer because your other devs don't need to remember to use an @import-once over and over (humans are flawed like that). 

And if you don't own the code, just wrap the check around the import instead. 

More specific, less magic. 


Sent from Mailbox for iPhone

On Sat, Sep 28, 2013 at 9:24 AM, Bráulio Bhavamitra
notifications@github.com wrote:

@aaronjensen +1 for a native version. it is very needed. the sass developers are considering this??

Reply to this email directly or view it on GitHub:
#139 (comment)

thejase commented Sep 28, 2013

Safer because your other devs don't need to remember to use an @import-once over and over (humans are flawed like that). 

And if you don't own the code, just wrap the check around the import instead. 

More specific, less magic. 


Sent from Mailbox for iPhone

On Sat, Sep 28, 2013 at 9:24 AM, Bráulio Bhavamitra
notifications@github.com wrote:

@aaronjensen +1 for a native version. it is very needed. the sass developers are considering this??

Reply to this email directly or view it on GitHub:
#139 (comment)

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Sep 28, 2013

@brauliobo it's not a built in solution, but you can use SmartSass. It will use the SSS compiler you have installed but replace the importer by one which makes include import files only once

svallory commented Sep 28, 2013

@brauliobo it's not a built in solution, but you can use SmartSass. It will use the SSS compiler you have installed but replace the importer by one which makes include import files only once

@brauliobo

This comment has been minimized.

Show comment
Hide comment
@brauliobo

brauliobo Sep 28, 2013

@svallory why shouldn't it be built in?

brauliobo commented Sep 28, 2013

@svallory why shouldn't it be built in?

@thejase

This comment has been minimized.

Show comment
Hide comment
@thejase

thejase Sep 28, 2013

@brauliobo He's not saying it shouldn't. He's saying this is a possible solution in the meantime.

thejase commented Sep 28, 2013

@brauliobo He's not saying it shouldn't. He's saying this is a possible solution in the meantime.

@svallory

This comment has been minimized.

Show comment
Hide comment
@svallory

svallory Sep 28, 2013

@brauliobo It's not "built in" because it's not part of the sass compiler. But it's totally transparent for the apps using it. And I sure hope it will be made part of sass someday.

svallory commented Sep 28, 2013

@brauliobo It's not "built in" because it's not part of the sass compiler. But it's totally transparent for the apps using it. And I sure hope it will be made part of sass someday.

@StefanoRausch

This comment has been minimized.

Show comment
Hide comment
@StefanoRausch

StefanoRausch Sep 28, 2013

@brauliobo : I do have a slight variation of the solution mentioned above — see https://gist.github.com/StefanoRausch/6744610 .

I do import it only once at the very beginning —think framework here, no duplication in every Sass file — and from there on I only have to either wrap the code in discussion as content for the mixin or I can use the function, depending on the constraints set by the mixin.

@import file -> @include once( "" ) { ... } OR @if( include-once( "" ) { ... }

Still a workaround, but nice to have ;)

StefanoRausch commented Sep 28, 2013

@brauliobo : I do have a slight variation of the solution mentioned above — see https://gist.github.com/StefanoRausch/6744610 .

I do import it only once at the very beginning —think framework here, no duplication in every Sass file — and from there on I only have to either wrap the code in discussion as content for the mixin or I can use the function, depending on the constraints set by the mixin.

@import file -> @include once( "" ) { ... } OR @if( include-once( "" ) { ... }

Still a workaround, but nice to have ;)

@StefanoRausch

This comment has been minimized.

Show comment
Hide comment
@StefanoRausch

StefanoRausch commented Sep 28, 2013

See #156 too.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
Member

chriseppstein commented Dec 6, 2013

@Frikki

This comment has been minimized.

Show comment
Hide comment
@Frikki

Frikki Oct 13, 2014

Three years... and counting!

Frikki commented Oct 13, 2014

Three years... and counting!

@herringtown

This comment has been minimized.

Show comment
Hide comment
@herringtown

herringtown Dec 11, 2014

Tick, tock.....thought this would have been addressed by now, having read through the entire thread.

Are @StefanoRausch & @courtsimas workarounds still the only viable solution to not have duplicated css when extending a selector from another (imported) file?

herringtown commented Dec 11, 2014

Tick, tock.....thought this would have been addressed by now, having read through the entire thread.

Are @StefanoRausch & @courtsimas workarounds still the only viable solution to not have duplicated css when extending a selector from another (imported) file?

@tmccombs

This comment has been minimized.

Show comment
Hide comment
@tmccombs

tmccombs Jan 5, 2015

Why is this still not fixed? Almost every language has some sort of import-once mechanism, but not sass.

tmccombs commented Jan 5, 2015

Why is this still not fixed? Almost every language has some sort of import-once mechanism, but not sass.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Jan 5, 2015

Member

Because it's a 4.0 feature.

Member

chriseppstein commented Jan 5, 2015

Because it's a 4.0 feature.

@sass sass locked and limited conversation to collaborators Jan 5, 2015

@nex3 nex3 removed this from the 4.0 milestone Jul 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.