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

Support for @import globbing ala Sass-globbing #156

Closed
benfrain opened this Issue Aug 30, 2013 · 43 comments

Comments

Projects
None yet
@benfrain

benfrain commented Aug 30, 2013

Would it be possible to support file globbing import statements?

E.g.

@import "_partials/custom/**/*";
@import "_partials/_modules/**/*";

I tend to make LOT'S of low specificity partials where import order is unimportant and Globbing let's me easily create them without having to continually specify another import.

Any chance we could see support of import globbing?

@xiwcx

This comment has been minimized.

Show comment
Hide comment
@xiwcx

xiwcx commented Sep 3, 2013

+1

@hcatlin

This comment has been minimized.

Show comment
Hide comment
@hcatlin

hcatlin Sep 3, 2013

Member

Hey, always up for a patch! ;) +1

Though, might have to be in the driver due to OS differences, etc.

On Monday, September 2, 2013, welch wrote:

+1


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-23687563
.

Member

hcatlin commented Sep 3, 2013

Hey, always up for a patch! ;) +1

Though, might have to be in the driver due to OS differences, etc.

On Monday, September 2, 2013, welch wrote:

+1


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-23687563
.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Sep 3, 2013

Member

This is explicitly not a feature of sass. So it should not be merged.

On Sep 3, 2013, at 5:48 AM, Hampton Catlin notifications@github.com wrote:

Hey, always up for a patch! ;) +1

Though, might have to be in the driver due to OS differences, etc.

On Monday, September 2, 2013, welch wrote:

+1


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-23687563
.


Reply to this email directly or view it on GitHub.

Member

chriseppstein commented Sep 3, 2013

This is explicitly not a feature of sass. So it should not be merged.

On Sep 3, 2013, at 5:48 AM, Hampton Catlin notifications@github.com wrote:

Hey, always up for a patch! ;) +1

Though, might have to be in the driver due to OS differences, etc.

On Monday, September 2, 2013, welch wrote:

+1


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-23687563
.


Reply to this email directly or view it on GitHub.

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Sep 3, 2013

I understand globbing it's not part of Sass 'as is' (although I wouldn't complain if it was ;)). THerefore, as there is no equivalence with the Ruby 'require' method in libsass (as I understand it) does that mean there is likely to be no way of facilitating globbing imports?

Or, perhaps the better question may therefore be, is there likely to be any changes that will bring globbing support into Ruby Sass?

benfrain commented Sep 3, 2013

I understand globbing it's not part of Sass 'as is' (although I wouldn't complain if it was ;)). THerefore, as there is no equivalence with the Ruby 'require' method in libsass (as I understand it) does that mean there is likely to be no way of facilitating globbing imports?

Or, perhaps the better question may therefore be, is there likely to be any changes that will bring globbing support into Ruby Sass?

@justnorris

This comment has been minimized.

Show comment
Hide comment
@justnorris

justnorris Oct 5, 2013

+1 for this to be added.

I don't care if it's "not pure sass", if it makes Sass better, why not ?

If this isn't merged, does libsass offer the same way of extending Sass like "Ruby Sass" (gems) does ? If not, then libsass isn't pure Sass, is it ?

justnorris commented Oct 5, 2013

+1 for this to be added.

I don't care if it's "not pure sass", if it makes Sass better, why not ?

If this isn't merged, does libsass offer the same way of extending Sass like "Ruby Sass" (gems) does ? If not, then libsass isn't pure Sass, is it ?

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Oct 8, 2013

@justnorris I don't think there was ever a patch there for the taking. Don't want to speak for @hcatlin but I think he was indicating that if someone could write the patch he would be happy to pull it in.

benfrain commented Oct 8, 2013

@justnorris I don't think there was ever a patch there for the taking. Don't want to speak for @hcatlin but I think he was indicating that if someone could write the patch he would be happy to pull it in.

@justnorris

This comment has been minimized.

Show comment
Hide comment
@justnorris

justnorris Oct 8, 2013

Yeah, I misunderstood at the beginning the "always up for a patch". Still it would be nice to see this implemented.

justnorris commented Oct 8, 2013

Yeah, I misunderstood at the beginning the "always up for a patch". Still it would be nice to see this implemented.

@hcatlin

This comment has been minimized.

Show comment
Hide comment
@hcatlin

hcatlin Oct 9, 2013

Member

We've made a promise not to implement things that aren't in the standard
Sass project, so unfortuntaley, you must first convince Chris Eppstein and
@NEXT3 about this before we can implement it.

On Tue, Oct 8, 2013 at 3:24 AM, Norris notifications@github.com wrote:

Yeah, I misunderstood at the beginning the "always up for a patch". Still
it would be nice to see this implemented.


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-25878951
.

Member

hcatlin commented Oct 9, 2013

We've made a promise not to implement things that aren't in the standard
Sass project, so unfortuntaley, you must first convince Chris Eppstein and
@NEXT3 about this before we can implement it.

On Tue, Oct 8, 2013 at 3:24 AM, Norris notifications@github.com wrote:

Yeah, I misunderstood at the beginning the "always up for a patch". Still
it would be nice to see this implemented.


Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/156#issuecomment-25878951
.

@bdkjones

This comment has been minimized.

Show comment
Hide comment
@bdkjones

bdkjones Feb 5, 2014

I strongly agree with @chriseppstein and @nex3 --- Sass-globbing should definitely not be a thing.

It introduces very subtle, very difficult-to-track bugs by affecting the cascade in unpredictable ways. I vote for closing this issue.

bdkjones commented Feb 5, 2014

I strongly agree with @chriseppstein and @nex3 --- Sass-globbing should definitely not be a thing.

It introduces very subtle, very difficult-to-track bugs by affecting the cascade in unpredictable ways. I vote for closing this issue.

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Feb 5, 2014

@bdkjones do you mean bugs as in it actually creates compile bugs? Or do you just mean it can affect the cascade in a way that doesn't suit the way some people write CSS?

If the former I'd be more inclined to agree with you.

If the latter I'd argue it simply doesn't match the way you/that person is writing CSS. I'm using it on projects with 80+ partials, all with very flat selector specificity and hence never get any issues because I'm not reliant on cascade order - where I believe Sass globbing earns its keep. It's certainly not something to be used trivially on all projects but that doesn't mean it shouldn't be 'a thing'.

Can you confirm what you mean by bugs in this respect?

benfrain commented Feb 5, 2014

@bdkjones do you mean bugs as in it actually creates compile bugs? Or do you just mean it can affect the cascade in a way that doesn't suit the way some people write CSS?

If the former I'd be more inclined to agree with you.

If the latter I'd argue it simply doesn't match the way you/that person is writing CSS. I'm using it on projects with 80+ partials, all with very flat selector specificity and hence never get any issues because I'm not reliant on cascade order - where I believe Sass globbing earns its keep. It's certainly not something to be used trivially on all projects but that doesn't mean it shouldn't be 'a thing'.

Can you confirm what you mean by bugs in this respect?

@bdkjones

This comment has been minimized.

Show comment
Hide comment
@bdkjones

bdkjones Feb 5, 2014

I mean the latter definition.

The trouble is that users are inclined to believe the former definition. They will almost always fire off an email or open an issue arguing, "Sass is broken in X!" And then the developer spends hours trying to track down what's going on, only to discover that the user's cascade was messed up due to globbing. It's a headache.

bdkjones commented Feb 5, 2014

I mean the latter definition.

The trouble is that users are inclined to believe the former definition. They will almost always fire off an email or open an issue arguing, "Sass is broken in X!" And then the developer spends hours trying to track down what's going on, only to discover that the user's cascade was messed up due to globbing. It's a headache.

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Feb 5, 2014

@bdkjones I feel your pain but that's a case of don't hate the game, hate the player ;)

Sass globbing works exactly as it should and has clear use cases. It serves the needs of larger projects especially because it allows fragmentation of the Sass code base across many partials for better maintainability without the need to continually declare each with an @import statement.

If a user is getting issues, as you have pointed out, it's the way they are writing CSS and using the feature that is at fault, not the feature.

I know the Sass devs are looking at a new @import mechanism for v4 so maybe they have a way to cater for both camps but for now I think Globbing is a great tool. I'm not sure that keeping it from users because 'some use it incorrectly' is the right thing to do.

benfrain commented Feb 5, 2014

@bdkjones I feel your pain but that's a case of don't hate the game, hate the player ;)

Sass globbing works exactly as it should and has clear use cases. It serves the needs of larger projects especially because it allows fragmentation of the Sass code base across many partials for better maintainability without the need to continually declare each with an @import statement.

If a user is getting issues, as you have pointed out, it's the way they are writing CSS and using the feature that is at fault, not the feature.

I know the Sass devs are looking at a new @import mechanism for v4 so maybe they have a way to cater for both camps but for now I think Globbing is a great tool. I'm not sure that keeping it from users because 'some use it incorrectly' is the right thing to do.

@akhleung

This comment has been minimized.

Show comment
Hide comment
@akhleung

akhleung Feb 5, 2014

Just to clarify, is a feature like this already accessible in Ruby Sass (e.g., via a custom Ruby extension or something), or is it just a Ruby feature that you'd like LibSass to support?

akhleung commented Feb 5, 2014

Just to clarify, is a feature like this already accessible in Ruby Sass (e.g., via a custom Ruby extension or something), or is it just a Ruby feature that you'd like LibSass to support?

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Feb 5, 2014

It's usually accessed in Ruby Sass as a require. The plugin itself is at this repo: https://github.com/chriseppstein/sass-globbing

On 5 Feb 2014, at 18:53, Aaron Leung notifications@github.com wrote:

Just to clarify, is a feature like this already accessible in Ruby Sass (e.g., via a custom Ruby extension or something), or is it just a Ruby feature that you'd like LibSass to support?


Reply to this email directly or view it on GitHub.

benfrain commented Feb 5, 2014

It's usually accessed in Ruby Sass as a require. The plugin itself is at this repo: https://github.com/chriseppstein/sass-globbing

On 5 Feb 2014, at 18:53, Aaron Leung notifications@github.com wrote:

Just to clarify, is a feature like this already accessible in Ruby Sass (e.g., via a custom Ruby extension or something), or is it just a Ruby feature that you'd like LibSass to support?


Reply to this email directly or view it on GitHub.

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 5, 2014

Contributor

The reference implementation of Sass doesn't and will not support globbing, for the reasons @bdkjones outlined. It makes the order that rules are emitted very difficult to reason about and contingent on non-local factors. There does exist a Ruby plugin for it, but I personally discourage its use.

Contributor

nex3 commented Feb 5, 2014

The reference implementation of Sass doesn't and will not support globbing, for the reasons @bdkjones outlined. It makes the order that rules are emitted very difficult to reason about and contingent on non-local factors. There does exist a Ruby plugin for it, but I personally discourage its use.

@benfrain

This comment has been minimized.

Show comment
Hide comment
@benfrain

benfrain Feb 5, 2014

On reflection I probably asked the wrong question as the merits (or not) of Sass globbing are unlikely to agreed upon between the participants here and really not the important factor.

I'll ask a different question: could a 'require' or similar plugin facility make it's way to libsass? That way it would provide the potential for plugins like globbing to be added outside of the features core Sass provides. That way those that love the feature can hopefully find a means to make use of it.

benfrain commented Feb 5, 2014

On reflection I probably asked the wrong question as the merits (or not) of Sass globbing are unlikely to agreed upon between the participants here and really not the important factor.

I'll ask a different question: could a 'require' or similar plugin facility make it's way to libsass? That way it would provide the potential for plugins like globbing to be added outside of the features core Sass provides. That way those that love the feature can hopefully find a means to make use of it.

@mgreter

This comment has been minimized.

Show comment
Hide comment
@mgreter

mgreter Feb 5, 2014

Contributor

I wonder why nobody hasn' yet mentioned sorting the list of files returned by glob, so you can predict the order. I always tend to prefix my css files with numbers anyway (%02d-file.css), so I get the correct order in any file listening. Was that already suggested for ruby sass? IMO that could be a usefull and well defined feature (at least for those who want to use it).

Contributor

mgreter commented Feb 5, 2014

I wonder why nobody hasn' yet mentioned sorting the list of files returned by glob, so you can predict the order. I always tend to prefix my css files with numbers anyway (%02d-file.css), so I get the correct order in any file listening. Was that already suggested for ruby sass? IMO that could be a usefull and well defined feature (at least for those who want to use it).

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Feb 6, 2014

Contributor

@mgreter An alphabetic sort would mean that renaming a file could affect the styling of your site in subtle and difficult-to-track ways. This is just the sort of non-local effect that we don't want.

Contributor

nex3 commented Feb 6, 2014

@mgreter An alphabetic sort would mean that renaming a file could affect the styling of your site in subtle and difficult-to-track ways. This is just the sort of non-local effect that we don't want.

@mgreter

This comment has been minimized.

Show comment
Hide comment
@mgreter

mgreter Feb 6, 2014

Contributor

@nex3 I agree, although I think one could argue if that is really a big problem (I mean if you document it properly, this is the behaviour you would expect). As long as there is no undefined behaviour possible (which would be true if you would not sort it), I would personally not vote against this feature (even if I have no use case for it, as I really like to reference the needed files explicitly). But that's just my personal opinion :)

Contributor

mgreter commented Feb 6, 2014

@nex3 I agree, although I think one could argue if that is really a big problem (I mean if you document it properly, this is the behaviour you would expect). As long as there is no undefined behaviour possible (which would be true if you would not sort it), I would personally not vote against this feature (even if I have no use case for it, as I really like to reference the needed files explicitly). But that's just my personal opinion :)

@akhleung akhleung added the feature label Feb 20, 2014

@ry5n

This comment has been minimized.

Show comment
Hide comment
@ry5n

ry5n Apr 6, 2014

Our team is looking to switch to libsass as it nears feature parity. One thing I would miss is globbing. Like Ben, I’d like to know if a plugin system could reasonably exist for libsass to make non-core features like this possible.

ry5n commented Apr 6, 2014

Our team is looking to switch to libsass as it nears feature parity. One thing I would miss is globbing. Like Ben, I’d like to know if a plugin system could reasonably exist for libsass to make non-core features like this possible.

@uglymunky

This comment has been minimized.

Show comment
Hide comment
@uglymunky

uglymunky Apr 10, 2014

Sass is a great tool but It's frustrating not being able to do this.

Our team has two primary sets of scss files: core.scss and views.scss (we also have vendor.scss but that's not related to this post)

core.scss rarely changes and views.scss is where we do 90% of our work. Each time we create a new view we create a new scss file for that view. The views all depend on core.scss and they are all independent from each other.

Because it's not an option to have our engineers go in and manually add an @import each time they create a new view our workaround for not being able to import a folder has been to concatenate all views scss files into one, and then compile that one file. I then have a master.scss that does:

@import 'core'
@import 'views'

I should be able to skip the concatenation step and simply do:

@import 'core'
@import 'path/to/views'

uglymunky commented Apr 10, 2014

Sass is a great tool but It's frustrating not being able to do this.

Our team has two primary sets of scss files: core.scss and views.scss (we also have vendor.scss but that's not related to this post)

core.scss rarely changes and views.scss is where we do 90% of our work. Each time we create a new view we create a new scss file for that view. The views all depend on core.scss and they are all independent from each other.

Because it's not an option to have our engineers go in and manually add an @import each time they create a new view our workaround for not being able to import a folder has been to concatenate all views scss files into one, and then compile that one file. I then have a master.scss that does:

@import 'core'
@import 'views'

I should be able to skip the concatenation step and simply do:

@import 'core'
@import 'path/to/views'
@dustinhorton

This comment has been minimized.

Show comment
Hide comment
@dustinhorton

dustinhorton Apr 10, 2014

Just want to +1.

As someone admittedly completely ignorant to writing software this complex, it seems like a really bizarre line to draw. I feel like there's many things more complex about the most basic of Sass features.

I'd be curious if the Grunt team has experienced issues...globbing is very popular in Gruntfiles. Different language obviously, but some of the same concerns.

Also would hate to see a language kept simplistic because of support requests for an app that leverages the tech...that complaint seems irrelevant. And it could be combatted by adding to the UI messaging to explain/warn, or a UI to build the import statements that visualizes what's actually happening.

(Sorry that this thread is taking place on the libsass repo, but just chiming in where it seems it'll be heard.)

dustinhorton commented Apr 10, 2014

Just want to +1.

As someone admittedly completely ignorant to writing software this complex, it seems like a really bizarre line to draw. I feel like there's many things more complex about the most basic of Sass features.

I'd be curious if the Grunt team has experienced issues...globbing is very popular in Gruntfiles. Different language obviously, but some of the same concerns.

Also would hate to see a language kept simplistic because of support requests for an app that leverages the tech...that complaint seems irrelevant. And it could be combatted by adding to the UI messaging to explain/warn, or a UI to build the import statements that visualizes what's actually happening.

(Sorry that this thread is taking place on the libsass repo, but just chiming in where it seems it'll be heard.)

@iki

This comment has been minimized.

Show comment
Hide comment
@iki

iki Apr 15, 2014

+1 for alphabetically sorted globbing, or require-like feature to add plugins

@nex3 file rename changes the order? yes that's a feature if we use sorted globbing, we can work with that just fine

iki commented Apr 15, 2014

+1 for alphabetically sorted globbing, or require-like feature to add plugins

@nex3 file rename changes the order? yes that's a feature if we use sorted globbing, we can work with that just fine

@josephspens

This comment has been minimized.

Show comment
Hide comment
@josephspens

josephspens Apr 16, 2014

+1

I guess I'm still unclear about the concerns with regards to adding some sort of globbing mechanism. From reading this thread so far, it seems the main and only concern is the inconsistent ordering of globbed partials could cause unintended cascade issues after compile. Is that a fair assessment?

If so, that would be an architectural design flaw of the implementing project, not of the underlying tools.

If I wanted to import some partials in this manner...

@import "partials/a";
@import "partials/b";
@import "partials/c";

... however I mistakenly ordered them like so...

@import "partials/c";
@import "partials/a";
@import "partials/b";

... and the reordering of the cascade created some unintended side effects, would you place blame on the developer who imported the partials in the wrong order, or Sass for not catching a mistake which is impossible for anyone but the developer to recognize?

Correct me if I'm wrong, but this scenario seems the same as glob importing all the partials with @import "partials/*"; and blaming Sass for the incorrect ordering, should the order matter.

Globbing is intended to include partials which are independent of each other, meaning the order in which they are imported does not matter. Using a globbing mechanism outside that context is the fault of the user, not the library.

josephspens commented Apr 16, 2014

+1

I guess I'm still unclear about the concerns with regards to adding some sort of globbing mechanism. From reading this thread so far, it seems the main and only concern is the inconsistent ordering of globbed partials could cause unintended cascade issues after compile. Is that a fair assessment?

If so, that would be an architectural design flaw of the implementing project, not of the underlying tools.

If I wanted to import some partials in this manner...

@import "partials/a";
@import "partials/b";
@import "partials/c";

... however I mistakenly ordered them like so...

@import "partials/c";
@import "partials/a";
@import "partials/b";

... and the reordering of the cascade created some unintended side effects, would you place blame on the developer who imported the partials in the wrong order, or Sass for not catching a mistake which is impossible for anyone but the developer to recognize?

Correct me if I'm wrong, but this scenario seems the same as glob importing all the partials with @import "partials/*"; and blaming Sass for the incorrect ordering, should the order matter.

Globbing is intended to include partials which are independent of each other, meaning the order in which they are imported does not matter. Using a globbing mechanism outside that context is the fault of the user, not the library.

@ry5n

This comment has been minimized.

Show comment
Hide comment
@ry5n

ry5n Apr 16, 2014

“The reference implementation of Sass doesn't and will not support globbing” – @ nex3 (see above).

I like and use glob imports, but I respect the language designer’s decision here. I think we should stop asking libsass to support non-reference features. It would be nice to have some way of adding such features to non-Ruby implementations, but that’s probably a separate issue.

ry5n commented Apr 16, 2014

“The reference implementation of Sass doesn't and will not support globbing” – @ nex3 (see above).

I like and use glob imports, but I respect the language designer’s decision here. I think we should stop asking libsass to support non-reference features. It would be nice to have some way of adding such features to non-Ruby implementations, but that’s probably a separate issue.

@josephspens

This comment has been minimized.

Show comment
Hide comment
@josephspens

josephspens Apr 16, 2014

@ry5n That's fair. Feel free to apply my arguments in support of your earlier comment to promote a plugin system, that way these discussions can happen outside the core. As was already pointed out by @benfrain, globbing already exists as a ruby gem.

josephspens commented Apr 16, 2014

@ry5n That's fair. Feel free to apply my arguments in support of your earlier comment to promote a plugin system, that way these discussions can happen outside the core. As was already pointed out by @benfrain, globbing already exists as a ruby gem.

@jezen

This comment has been minimized.

Show comment
Hide comment
@jezen

jezen Aug 1, 2014

Globbing may exist as a ruby gem, but I’m only interested in using LibSass to sever the Ruby dependency. Defeats the purpose.

jezen commented Aug 1, 2014

Globbing may exist as a ruby gem, but I’m only interested in using LibSass to sever the Ruby dependency. Defeats the purpose.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 1, 2014

Member

LibSass can and should implement a similar abstraction to Sass's importer system. On that framework, a globbing plugin can be created for libsass similar to sass-globbing.

Member

chriseppstein commented Aug 1, 2014

LibSass can and should implement a similar abstraction to Sass's importer system. On that framework, a globbing plugin can be created for libsass similar to sass-globbing.

@hannahhoward

This comment has been minimized.

Show comment
Hide comment
@hannahhoward

hannahhoward Aug 14, 2014

+1 for implementing this, or creating a way for a plugin to do it if not. my team relies heavily on globbing in ruby and it's a bummer to not have it as we try to switch to libsass

hannahhoward commented Aug 14, 2014

+1 for implementing this, or creating a way for a plugin to do it if not. my team relies heavily on globbing in ruby and it's a bummer to not have it as we try to switch to libsass

@renestalder

This comment has been minimized.

Show comment
Hide comment
@renestalder

renestalder Aug 14, 2014

+1

People are always concerned about the ordering. In fact, I realised about 3 Projects with up to 40 SCSS files and hadn't any problems. Thus it's always up to the developer how to use a system.

renestalder commented Aug 14, 2014

+1

People are always concerned about the ordering. In fact, I realised about 3 Projects with up to 40 SCSS files and hadn't any problems. Thus it's always up to the developer how to use a system.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 14, 2014

Member

#NotAllDevelopers

Member

chriseppstein commented Aug 14, 2014

#NotAllDevelopers

@mgreter

This comment has been minimized.

Show comment
Hide comment
@mgreter

mgreter Aug 14, 2014

Contributor

@renestalder The ordering of glob per se is IMHO not predictable. Therefore it may have been pure luck that you haven't run into any issues (or you made sure that the include order doesn't matter). It really depends on the OS and probably the filesystem (reiserfs, ext3, ntfs, fat32, etc.).

Unfortunately glob is not a c++ standard and implementations differ from system to system. So I can see why it would be a "pain" to add this to libsass (since each OS may need a different/specific implementation to guarantee the same result). I guess ruby sass can hide behind the glob implementation of ruby, which does all the normalization behind the scene to get the same results on windows, linux, mac, etc. (not even sure if ruby guarantees that).

I would personally not vote against this feature, if implemented properly! I guess a c++ glob library that works consistently on all platforms might help to get this implemented.

Contributor

mgreter commented Aug 14, 2014

@renestalder The ordering of glob per se is IMHO not predictable. Therefore it may have been pure luck that you haven't run into any issues (or you made sure that the include order doesn't matter). It really depends on the OS and probably the filesystem (reiserfs, ext3, ntfs, fat32, etc.).

Unfortunately glob is not a c++ standard and implementations differ from system to system. So I can see why it would be a "pain" to add this to libsass (since each OS may need a different/specific implementation to guarantee the same result). I guess ruby sass can hide behind the glob implementation of ruby, which does all the normalization behind the scene to get the same results on windows, linux, mac, etc. (not even sure if ruby guarantees that).

I would personally not vote against this feature, if implemented properly! I guess a c++ glob library that works consistently on all platforms might help to get this implemented.

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 14, 2014

Member

This feature has been fully debated and rejected as a Sass feature. At this
point, adding +1's is not going to change our mind. It adds only marginal
benefit and introduces large debugging costs for users who make incorrect
assumptions about ordering or fail to understand the cascade's importance.

On Thu, Aug 14, 2014 at 12:47 PM, Marcel Greter notifications@github.com
wrote:

@renestalder https://github.com/renestalder The ordering of glob per se
is IMHO not predictable
http://stackoverflow.com/questions/8977441/does-readdir-guarantee-an-order.
Therefore it may have been pure luck that you haven't run into any issues
(or you made sure that the include order doesn't matter). It really depends
on the OS and probably the filesystem (reiserfs, ext3, ntfs, fat32, etc.).

Unfortunately glob is not a c++ standard and implementations differ from
system to system. So I can see why it would be a "pain" to add this to
libsass (since each OS may need a different/specific implementation to
guarantee the same result). I guess ruby sass can hide behind the glob
implementation of ruby, which does all the normalization behind the scene
to get the same results on windows, linux, mac, etc. (not even sure if ruby
guarantees that).

I would personally not vote against this feature, if implemented properly!
I guess a c++ glob library that works consistently on all platforms
http://stackoverflow.com/questions/5211752/implementing-a-platform-independent-glob
might help to get this implemented.


Reply to this email directly or view it on GitHub
#156 (comment).

Member

chriseppstein commented Aug 14, 2014

This feature has been fully debated and rejected as a Sass feature. At this
point, adding +1's is not going to change our mind. It adds only marginal
benefit and introduces large debugging costs for users who make incorrect
assumptions about ordering or fail to understand the cascade's importance.

On Thu, Aug 14, 2014 at 12:47 PM, Marcel Greter notifications@github.com
wrote:

@renestalder https://github.com/renestalder The ordering of glob per se
is IMHO not predictable
http://stackoverflow.com/questions/8977441/does-readdir-guarantee-an-order.
Therefore it may have been pure luck that you haven't run into any issues
(or you made sure that the include order doesn't matter). It really depends
on the OS and probably the filesystem (reiserfs, ext3, ntfs, fat32, etc.).

Unfortunately glob is not a c++ standard and implementations differ from
system to system. So I can see why it would be a "pain" to add this to
libsass (since each OS may need a different/specific implementation to
guarantee the same result). I guess ruby sass can hide behind the glob
implementation of ruby, which does all the normalization behind the scene
to get the same results on windows, linux, mac, etc. (not even sure if ruby
guarantees that).

I would personally not vote against this feature, if implemented properly!
I guess a c++ glob library that works consistently on all platforms
http://stackoverflow.com/questions/5211752/implementing-a-platform-independent-glob
might help to get this implemented.


Reply to this email directly or view it on GitHub
#156 (comment).

@mgreter

This comment has been minimized.

Show comment
Hide comment
@mgreter

mgreter Aug 14, 2014

Contributor

@chriseppstein maybe the feature label/tag should then be removed/changed to won't do ;)

Contributor

mgreter commented Aug 14, 2014

@chriseppstein maybe the feature label/tag should then be removed/changed to won't do ;)

@chriseppstein

This comment has been minimized.

Show comment
Hide comment
@chriseppstein

chriseppstein Aug 15, 2014

Member

@mgreter The open issue is, IMO, is for libsass to create an importer abstraction like Ruby Sass has so that this can be a plugin.

Member

chriseppstein commented Aug 15, 2014

@mgreter The open issue is, IMO, is for libsass to create an importer abstraction like Ruby Sass has so that this can be a plugin.

@nschonni

This comment has been minimized.

Show comment
Hide comment
@nschonni

nschonni Aug 15, 2014

Collaborator

@chriseppstein since the title and most of the discussion aren't about the scripting systems, maybe it should be closed and a new issue specific to the scripting system be opened (can't remember if there already is one)

Collaborator

nschonni commented Aug 15, 2014

@chriseppstein since the title and most of the discussion aren't about the scripting systems, maybe it should be closed and a new issue specific to the scripting system be opened (can't remember if there already is one)

@renestalder

This comment has been minimized.

Show comment
Hide comment
@renestalder

renestalder Aug 15, 2014

@mgreter @chriseppstein Not "luck", a good file structure, that's it. There are several things you can do.

For example you could structure your files in a atomic design manner with following folder structure

  • util
  • quarks
  • atoms
  • molecules

Then make a root level stylesheet, first importing all files from util, then from quarks, then from atoms,... etc.

Or as I used it in some projects

  • settings
  • shared
  • specific
    • photogallery
      • _base.scss
      • _medium.scss
      • _large.scss

Where settings are mixins and config variables. Shared are global used styles or general elements. And specific are page specific elements as in the example above.

In the root level stylesheet I have my media queries, importing the correct sizes of each component in the right media query.

@import 'settings/**/*';

@media #{$medium} { 
  @import "shared/**/_medium.scss", "specific/**/_medium.scss";
}

The components on the same level have no dependency to each other. They can be used uncoupled, with a dependency to settings or shared components, if needed.

So it's always up to the developer to use this the right way.

renestalder commented Aug 15, 2014

@mgreter @chriseppstein Not "luck", a good file structure, that's it. There are several things you can do.

For example you could structure your files in a atomic design manner with following folder structure

  • util
  • quarks
  • atoms
  • molecules

Then make a root level stylesheet, first importing all files from util, then from quarks, then from atoms,... etc.

Or as I used it in some projects

  • settings
  • shared
  • specific
    • photogallery
      • _base.scss
      • _medium.scss
      • _large.scss

Where settings are mixins and config variables. Shared are global used styles or general elements. And specific are page specific elements as in the example above.

In the root level stylesheet I have my media queries, importing the correct sizes of each component in the right media query.

@import 'settings/**/*';

@media #{$medium} { 
  @import "shared/**/_medium.scss", "specific/**/_medium.scss";
}

The components on the same level have no dependency to each other. They can be used uncoupled, with a dependency to settings or shared components, if needed.

So it's always up to the developer to use this the right way.

@hcatlin

This comment has been minimized.

Show comment
Hide comment
@hcatlin

hcatlin Oct 3, 2014

Member

This project is a sub-project to the main Sass project. The discussion on that list is the main one. I'm going to close this unless there is a change of status at the other project.

Member

hcatlin commented Oct 3, 2014

This project is a sub-project to the main Sass project. The discussion on that list is the main one. I'm going to close this unless there is a change of status at the other project.

@hcatlin hcatlin closed this Oct 3, 2014

Melros added a commit to Melros/sassline that referenced this issue Oct 31, 2014

Import modules directly
Globbing is not a feature of sass.

A direct import makes it possible to use it with libsass.

See Issue: sass/libsass#156
@DennisBecker

This comment has been minimized.

Show comment
Hide comment
@DennisBecker

DennisBecker Nov 7, 2014

As a workaround solution for the missing globbing feature I have written https://github.com/DennisBecker/grunt-sass-globbing today for use with grunt-sass plugin.

At the moment, it lacks of correct documentation (I will complete it next week).

You can migrate from Ruby sass-globbing to grunt-sass-globbing as follows:

When you have an import like this one:

@import "partials/variables";
@import "my/folder/**/*";

Then you add the following config to your gruntfile:

sass_globbing: {
  dist: {
    files: {
      'my/_folder.scss': 'my/folder/**/*.scss',
    }
  },

And execute this task right before the sasstask.

I would expect you add my/_folder.scss as empty file to your repository. grunt-sass-globbing will overwrite it. Have a deeper look at it on the tests on https://github.com/DennisBecker/grunt-sass-globbing/tree/master/test

This grunt plugin is not finished, so when you want to install it, use npm install https://github.com/DennisBecker/grunt-sass-globbing/tarball/masterfor now. Feedback / pull requests on this plugin much appreciated.

DennisBecker commented Nov 7, 2014

As a workaround solution for the missing globbing feature I have written https://github.com/DennisBecker/grunt-sass-globbing today for use with grunt-sass plugin.

At the moment, it lacks of correct documentation (I will complete it next week).

You can migrate from Ruby sass-globbing to grunt-sass-globbing as follows:

When you have an import like this one:

@import "partials/variables";
@import "my/folder/**/*";

Then you add the following config to your gruntfile:

sass_globbing: {
  dist: {
    files: {
      'my/_folder.scss': 'my/folder/**/*.scss',
    }
  },

And execute this task right before the sasstask.

I would expect you add my/_folder.scss as empty file to your repository. grunt-sass-globbing will overwrite it. Have a deeper look at it on the tests on https://github.com/DennisBecker/grunt-sass-globbing/tree/master/test

This grunt plugin is not finished, so when you want to install it, use npm install https://github.com/DennisBecker/grunt-sass-globbing/tarball/masterfor now. Feedback / pull requests on this plugin much appreciated.

@stubar

This comment has been minimized.

Show comment
Hide comment
@stubar

stubar Dec 11, 2014

I'm using gulp and was concating everything before my sass call and was getting all sorts of issues with them running asynchronously, even though I was using the recommended dependency patterns. I ended up using this to generate 1 included index file, https://www.npmjs.com/package/gulp-concat-filenames/. This doesn't have to be in your watch task, only needs to be run when you create new files.

stubar commented Dec 11, 2014

I'm using gulp and was concating everything before my sass call and was getting all sorts of issues with them running asynchronously, even though I was using the recommended dependency patterns. I ended up using this to generate 1 included index file, https://www.npmjs.com/package/gulp-concat-filenames/. This doesn't have to be in your watch task, only needs to be run when you create new files.

@DennisBecker

This comment has been minimized.

Show comment
Hide comment
@DennisBecker

DennisBecker Dec 11, 2014

This lacks of some features, like removing the underscore before filenames if they are just partials or using the correct relative path. And I think it is not really obvious when you look for an alternative for sass-globbing.

DennisBecker commented Dec 11, 2014

This lacks of some features, like removing the underscore before filenames if they are just partials or using the correct relative path. And I think it is not really obvious when you look for an alternative for sass-globbing.

@stubar

This comment has been minimized.

Show comment
Hide comment
@stubar

stubar Dec 11, 2014

The root option is for setting relativity, I'm not sure about the underscore, I'm leaving the underscore in the import and it seems to work, is this going to bite me in the bum?

stubar commented Dec 11, 2014

The root option is for setting relativity, I'm not sure about the underscore, I'm leaving the underscore in the import and it seems to work, is this going to bite me in the bum?

@tschwartz

This comment has been minimized.

Show comment
Hide comment
@tschwartz

tschwartz Jan 5, 2015

I would suggest using something like https://www.npmjs.com/package/gulp-include (there's most likely something similar for Grunt). I use it for all of my dependency management so that my Gulp setup doesn't need to have that logic baked into it and the mechanism for doing so is consistent across HTML, SCSS and JavaScript. For example:

common.scss

//= require ../../../bower_components/normalize.css/normalize.css
//= require '_helpers.scss';
//= require '_base.scss';
//= require '_typography.scss';
//= include ../components/common/**/_*.scss

scss.js

gulp.task('scss', function() {
  return gulp.src([
      './src/public/scss/**/*.scss'
    ])
    .pipe(plugins.include())
    .pipe(plugins.sass())
    .pipe(plugins.autoprefixer())
    .pipe(plugins.cssmin())
    .pipe(plugins.rename(function(path) {
      path.extname = '.min.css';
    }))
    .pipe(gulp.dest('./dist/public/css/'));
});

tschwartz commented Jan 5, 2015

I would suggest using something like https://www.npmjs.com/package/gulp-include (there's most likely something similar for Grunt). I use it for all of my dependency management so that my Gulp setup doesn't need to have that logic baked into it and the mechanism for doing so is consistent across HTML, SCSS and JavaScript. For example:

common.scss

//= require ../../../bower_components/normalize.css/normalize.css
//= require '_helpers.scss';
//= require '_base.scss';
//= require '_typography.scss';
//= include ../components/common/**/_*.scss

scss.js

gulp.task('scss', function() {
  return gulp.src([
      './src/public/scss/**/*.scss'
    ])
    .pipe(plugins.include())
    .pipe(plugins.sass())
    .pipe(plugins.autoprefixer())
    .pipe(plugins.cssmin())
    .pipe(plugins.rename(function(path) {
      path.extname = '.min.css';
    }))
    .pipe(gulp.dest('./dist/public/css/'));
});

anlutro pushed a commit to alprs/libsass that referenced this issue Feb 2, 2015

Merge pull request #156 from xzyfer/feat/issue-652
Add and activate specs for issue 652

@sass sass locked and limited conversation to collaborators Jul 18, 2017

@sass sass deleted a comment from notrealdev Jul 18, 2017

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