Add option to control CSS inline import behaviour

[xzyfer]

We've added the ability to inline @import CSS partials. This is significantly different from the Ruby Sass behaviour (which does not allow this at all) and is understandable causing pain.

We need a context option to enable/disable this feature. It should be disabled by default.

[mgreter]

I think the wording is a bit misleading. We only allow imports of css partials (stuff ending with .css will left as an actual import in the code). Also Ruby Sass does not allow this by default, but a few tools (AFAIK compass too) enable this by default for Ruby Sass. I'm also not sure if we really want to disable it by default, since this would be another potentially breaking change.

class CSSImporter < Sass::Importers::Filesystem
  def extensions
    super.merge('css' => :scss)
  end
end
Sass::Plugin.options[:filesystem_importer] = CSSImporter

[xzyfer]

Full disclosure I still think this feature should be removed. Our directive is to do what Ruby Sass does. Anything deviation from their implementation breaks portability, and is indistinguishable from a bug.

Also Ruby Sass does not allow this by default, but a few tools (AFAIK compass too) enable this by default for Ruby Sass

This isn't our job. This belongs in the realm of tools like wellington and eyeglass.

I'm also not sure if we really want to disable it by default

I vehemently believe it should.

this would be another potentially breaking change

The current behaviour is broken as far as Sass users are concerned.

[mgreter]

I guess it's clear that I'm in favor of having this feature and just wanted to point out that the breakage is mainly only because I've implemented the error message for ambigous imports for libsass 3.3.0. Beside that we only differ by default in partial resolving (also includeing css extension), and I would argue that normally you don't generate or have a css with the same name beside a partial import. Unsure when I will come around to implement that as an option on the C-API. Contributers welcome ;)

[esr360]

I think the ideal situation would be that they both support this features. The next best thing would be as @xzyfer says and to at least have them be consistent, even if that means neither of them supporting it.

You should be able to switch from libsass to ruby sass in theory without anything breaking. Having something which would knowingly prevent this from happening imo is a bad thing.

[xzyfer]

You should be able to switch from libsass to ruby sass in theory without anything breaking

Exactly.

The next best thing would be as @xzyfer says and to at least have them be consistent

This is what we will do.

[xzyfer]

Sass 4.0 will bring in a way to do this properly.

[esr360]

Fantastic! Can't wait.

[xzyfer]

@mgreter I've talked to @chriseppstein and @nex3 about this problem. We've decided that even though inline of CSS imports breaks Ruby Sass compatibility in a big way, removing this feature is likely to upset users. This has been a long requested feature in Ruby Sass which wasn't possible due the limitations of being a CSS superset. As a result almost certain people are depending on this behaviour.

Let's instead aim to remove this in 4.0 since users are more accepting of breaking changes in major releases, and because we'll have an official way to inline CSS imports.

[atalis]

We recently switched to the latest version of Node from a much older version and had to upgrade a 3rd party library we are using, to be compatible with the current Node version. Now things are broken all over the place because of this bug. I understand this issue is not resolved in libsass yet, so I'm trying to figure out recursively what versions of our dependencies we'd need to go back to in order to get rid of this issue.

So, a few questions (apologies, if I missed this info here, this thread is a bit convoluted):

1. What version of libsass was this bug introduced?
2. What version is the fix going into - 3.5? 4.0?
3. When is that version scheduled to release? (Or has it already been released, perhaps?)

[xzyfer]

What version of libsass was this bug introduced?

I can't be certain. I think it was around 3.3.0 which is in [email protected].

What version is the fix going into - 3.5? 4.0?

This will be fixed in 4.0 once @use lands. It will allow people explicitly opt-in to CSS imports.

When is that version scheduled to release?

Impossible to say unfortunately. Not likely to be this year.

---

As an aside if you're using node-sass you can write a custom importer to noop imports for .css files.

[steveworkman]

As @xzyfer said, try a custom importer, I had an issue where we had .scss files and .css files in the same directory, and here's the importer I made for node-sass

importer: function(url, prev, done) {
	// Use this to import scss files, instead of css ones
	let updatedUrl = url;
	if (!url.endsWith('.scss') && !url.endsWith('.css')) { // Also don't change ones already explicitly set to .css
		updatedUrl += '.scss';
	}
	grunt.verbose.writeln(`Changed ${url} into ${updatedUrl}`);
	done({file: updatedUrl});
}

Tested with node-sass 4.5.2 libsass 3.5.0-beta2