Multiple inclusions of _global.css (SASS 3.4)

[BenMorel]

This commit by @jonathanmelville on Sep 26 is supposed to "fix multiple inclusions of _global.scss when compiling", but for me it does the exact opposite (SCSS 3.4.1 on Windows), and I now get multiple copies of _global.scss in my output .css file.

This commit reverts the modification brought by @noeljackson on Aug 21.

As far as I understand it from the latest release notes, support for SASS 3.4 has been dropped, hence this modification.

Isn't it a bit weird to drop support for the latest version of SASS? Shouldn't it be the opposite?

It's very surprising to see the latest version of a library drop support for the latest version of one of its dependencies. Plus, this broke backward compatibility in a patch release, breaking semantic versioning.

What about releasing a new minor version 5.5 right now, with support for SASS 3.4+?

[BenMorel]

Sorry I got confused: first of all the commit by @jonathanmelville went after the 5.4.5 release, and it's not the only problem, as now !global being removed, the whole thing is broken anyway.

It would be really nice to release a version compatible with SASS 3.4 ASAP, as the whole thing is broken for anyone using an up-to-date global copy of SASS!

[jonathanmelville]

I would be really nice to release a version compatible with SASS 3.4 ASAP

That would be nice, but achieving that in a way that is usable to the largest group of people is pretty complicated. There are so many issues at play right now with Sass.

The main problem I see (and Zurb seems to agree with me) is that you simply cannot cut off libsass users. Yeah, I get that Sass was originally written in Ruby, and the official distribution is still in Ruby, but Ruby is slow as a dead snail at compiling Sass. This makes it virtually unusable for a lot of people. Libsass only supports Sass 3.2, but it's very fast.

So, there are tradeoffs to both. Clearly the ultimate goal is support for the latest version of Sass, but I don't think dropping support for libsass from Foundation is any way an option, too many people depend on it.

[BenMorel]

I'm not talking about dropping libsass support (although they clearly need to update their compatibility to the latest SASS), but rather to release another version (5.5) compatible with the latest SASS only.

Users of libsass (and generally SASS < 3.4) would be advised to stay on 5.4 until libsass catches up.

That would make everyone happy, and at least there would be a clear version bump separation between SASS 3.2-compatible and SASS 3.4-compatible versions: at the moment, I have to use 5.4.4, because 5.4.5 has broken compatibility. This definitely is not semantic versioning!

Final note, I'm on Windows, and I don't know of a Windows command-line libsass port that I could use with my IDE's file watcher. So AFAIK, Windows users have to rely on Ruby, which might be slower, but at least provides a Windows installer.

So at the moment, unless I missed something, Foundation is letting all Windows developers down, which is a bit of a pity!

[gakimball]

The codebase has sort of been in flux for a few weeks while we've tried to sort through this compatibility business, so unfortunately semver is out the window right now. We want to have all of this sorted out before 5.5. Version 5.5 will be our big stability push, and when that rolls around it should be business as usual for us, and then we can be more responsible with our use of version numbers. The problem is there's no way to hotfix a Bower package, and you can't create a minor minor patch so all of these little urgent changes require us to push out a new minor version.

As for the issue of Sass compatibility itself, the author of CodeKit wrote a very good overview that breaks down the whole situation.

We definitely want to support Sass 3.4 eventually, but we're waiting on two things:

• sass-rails to support Sass 3.3. It's at 3.2 right now and they're working on 3.3.
• libsass to add support for the !global keyword, preferably in a stable release.

We've had a few folks recommend we split our codebase, but then that becomes a hassle for our users, who need to understand the right "newest" version they can use based on their stack. Our tradeoff right now is that it's a hassle for Sass 3.4 users to have to use an older version and a Gemfile. But we should have been including a Gemfile in our Compass stack, and advising users to run Bundler, all along. That was our mistake, which we've now rectified. Dependencies and versioning are always an issue, so using Bundler in your Ruby environment just makes sense.

As far as the Windows stuff, you're right that there's no way out of the box to run most node modules from the command line. I think that's by design, because node plugins are designed to accept input and then pass on output to some other plugin. So ordinarily people use these plugins with tools like Grunt and Gulp, which construct that I/O pipe for you.

It is possible to make JS files into executables using node (on Windows as well), so you could write a script that runs node-sass once and outputs it to the filesystem. So your IDE would then be able to call that script as an executable every time a file changes.

[jonathanmelville]

This kind of echoes what Geoff already said but you can install Node on your Windows PC and use grunt-sass in your Grunt build to compile with libsass.

https://github.com/sindresorhus/grunt-sass

[rafibomb]

We plan to move to Sass 3.4 as soon as Libsass and Rails Sass support it. Without supporting multiple versions we have not heard of a better solution yet.

[jonathanmelville]

I think that's the right decision. Forking Foundation into multiple versions is not the answer, and would be confusing for users and a nightmare to maintain.

[ghost]

If you absolutely must use Sass 3.4 then using the compass-import-once extension will prevent multiple inclusions.

[ldexterldesign]

Hey,

So if I understand this situation correctly, in order to run the latest LibSass with the latest Foundation, I have to output a .css file twice the size (multiple global.scss @imports) until one of two issues are resolved?

• sass-rails to support Sass 3.3. It's at 3.2 right now and they're working on 3.3.
• libsass to add support for the !global keyword, preferably in a stable release.

– #5877 (comment)

cc/ @adrianwhite

Thanks,

PS @andy-saint hmm, no luck with this ( #5877 (comment) ) - are there any more docs?

[BenMorel]

@ldexterldesign I've myself reverted to 5.4.4 for now, until SASS 3.4 is supported. No code duplication with this one.

[jonathanmelville]

@ldexterldesign My PR (referenced above) does fix this problem. It's already been merged into master but Zurb hasn't issued a new release yet for some reason.

[gakimball]

@jonathanmelville We're deploying a new version on Thursday, which will indeed include your PR. Sorry for the wait, folks!

[jonathanmelville]

Well there you go, thanks Geoff!

[ldexterldesign]

Cheers ~ https://twitter.com/ldexterldesign/status/519489840770220032

[ldexterldesign]

Hey,

Wondered if - 1 month later - if this issue between the latest SASS and Foundation still exists?

Out of interest will:
bower update

... do the job of:
foundation update

... or should I run them separately?:

1. bower update
2. foundation update

Thanks,

[gakimball]

@ldexterldesign Yep, the issue is still there, but it's a known issue.

This month we're putting out Foundation 5.5, which will finally upgrade the codebase to Sass 3.4. For our Rails users we'll need to tell them not to upgrade, or roll the dice and use sass-rails 5.0.0.beta1 in their Rails project.

[ldexterldesign]

Hey @gakimball,

Thanks

And the commands?

Kind thanks,

[gakimball]

@ldexterldesign foundation update just runs bower update, so you can do whichever.

[ldexterldesign]

@gakimball thanks :)

[swampthang]

I'm working in a rails app that I've just upgraded from Foundation 3.25 to Foundation 5. Major undertaking but the company doesn't want to use bower, instead strictly using bundler as follows:

gem "rails", "~> 4.1.8"
# more gems here
gem "sass-rails"
# for Foundation framework
gem 'compass-rails'
gem 'foundation-rails', '~> 5.5.0'

I don't have the bower option at this point so I can't just pop open the _functions.scss file and edit it plus, there's no combination of rails gems that allow me to drop back in versions from 2.0. Stuck in a dependency rubix cube.

I see the reference above to compass-import-once but that didn't solve the issue. Has anyone else run into this and found a solution where you weren't using a bower directory?

[gakimball]

@swampthang If you don't need it for anything else, you can drop compass-rails, as the framework doesn't use Compass at all anymore. (The exports() function is borrowed from the import-once library, but we just wrote it ourselves.) And set sass-rails to 5.0.1 to make sure you're on the newest version.