@MDG: Please support SASS officially!

Just updated one of my apps to Meteor 1.2 and the latest version of fourseven:scss - just to see that all of my Sass files were broken due to changes in the build system and breaking changes in the package. This is really annoying and costs a lot of unneccessary patch-work.

So, PLEASE, MDG - if you happen to read this: Here’s my official request for an official Sass support. It just does not make sense to support a lot of completely different front-end technologies (React, Angular, Blaze) on one hand, but forget about the basic technologies on the other hand. I understand that you want to delegate some specials to the community, but in my opinion Sass is too core to ignore.

EDIT: Just happened to read that [auto-prefixing isn’t supported anymore either] (https://github.com/meteor/meteor/issues/5219), due to constraints in the new build system. To be honest, it is not easy to stay calm with all these unexpected breaking changes. It’s just sad that guys like fourseven are doing an awesome job and then some change in Meteor breaks a lot of it. :-/


I hear you man & I agree with you that basic things like auto-prefix shouldn’t just break!

However, what’s about using a preprocessor like Prepros to convert your sass files into CSS, and then just feed those files into Meteor’s compiling ?

Prepros is a terrible idea. It’s actually funny, that we can’t do such an easy task as compiling sass/scss.

Here is the issue in the Meteor repository.

And here is the issue in the fourseven repository to become the official sass/scss maintainer for meteor. But it was renamed with weird title.

I suggest you to write +1 or smth in this issues to show, that we need it and hope it will happen soon.

1 Like

I’m the co-maintainer of fourseven:scss. There’s a couple of reason some files do not work anymore

  1. There’s a new build system. The less and stylus packages leverage this to make cross-package imports possible and we’ve updated fourseven:scss to be more in line with the less and stylus package, however, this requires some changes to the way you add files to your package.js file or how your files are named.
  2. The decision not to support some options and autoprefixer anymore. I can’t speak for Mathew (fourseven), but IMO, these shouldn’t have been in the package in the first place. The options because they do not play well together with the meteor build system and autoprefixing because it should be a different package. We should do only sass compilation, nothing more, nothing less.
  3. Some bugs in node-sass that were discovered too late.

Try version 3.4.0-beta1 read through the readme of fourseven:scss and your scss files should work again.

Breaking changes are not fun, but sometimes they are necessary.

Sorry, but tools like Prepos or Koala are workarounds for people who are not able to set-up a working automatic pre-compilation environment. I want everything tightly integrated, and I would also like to have others participate in the development of my app. If I have to tell everybody how to install a 3rd party tool, this is not the best idea.

Before I had Meteor, I was using grunt or gulp for these pre-compilation tasks. But since MDG tends to re-invent the wheel (due to good reasons) and build their own build tools, I think I can expect from them that at least such core functionality is still available. And even more since fourseven:scss did work just fine and did offered auto-prefixing - until Meteor 1.2 came out and broke this working stuff due to changes in the build process.

First of all, let me thank you @seba for maintaining this great package. My criticism was not directed at fourseven:scss, on the contrary: I wanted to support your great work by clearly stating that the community (or: at least me?) needs a good and strong SCSS support, preferably in the core.

I agree with you that auto-prefixing could be a separate package. But what I’ve learned in the issue thread on auto-prefixing in the fourseven:scss repo, the main reason why it is not working anymore is that the new build system broke it and there’s no way ATM to workaround these limitations. And this is, at lesat IMHO, unacceptable. A build system is such a core thing, as well is post-processing of files, that you just cannot expect post-processing capabilities to break from one minor version to another.

Yeah, but we (I) actually deserve part of the critcism. We found out about the bugs in node-sass a bit too late, which is the reason for some of the errors.

However, most of the errors is because of the hacky ways in which people tried to import scss files from other packages, and it is exactly this that is now much easier, at the cost of BC break. Being in core probably wouldn’t have changed this, except maybe for a better warning in the release notes.

I do agree there are some shortcomings to the build system, and I’ve already started a discussion here: https://github.com/meteor/meteor/issues/5219


Not really. They are actually great if you don’t want to wait around 20seconds for each compile change.