3.5.3 regression: importing `.css` files fails instead of warning (as the release notes indicate)

[asottile]

Originally reported here: sass/libsass-python#245

input.scss

@import 'cssfile';

cssfile.css

a { b: c; }

libsass 3.5.2 (via libsass-python)

$ pysassc --version
pysassc 0.14.2 (sass/libsass 3.5.2)
$ pysassc input.scss 
a {
  b: c; }

libsass 3.5.3 (via libsass-python)

$ pysassc --version
pysassc 0.14.3 (sass/libsass 3.5.3)
$ pysassc input.scss 
pysassc: error: Error: File to import not found or unreadable: cssfile.
        on line 1 of input.scss
>> @import 'cssfile';

   ^

I expect the warning noted in the release notes

[samuelcolvin]

I think this can be closed, this is exactly what was expected by #1963.

Personally, I think it should have been depreciated via a warning first and caused a minor release rather than patch, but it's too late now.

[xzyfer]

Sorry this was an unintended breaking change for this patch release.

My preference is to roll forward with change and update the release notes.

You'll need to use the sass_option_push_import_extension API to re-enable .css imports as I see you've done in sass/libsass-python#246.

Note: doing so will result in deprecation warning for .css files. The deprecation warning will be removed in 3.6.0.

[samuelcolvin]

I'm very confused by the depreciation, nowhere seems clear:

The deprecation warning will be removed in 3.6.0.

vs.

Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass. Use a custom importer to maintain this behaviour. Check your implementations documentation on how to create a custom importer.

Will the depreciation warning be removed in 3.6.0 and sass_option_push_import_extension continue to work or will the functionality of importing css be completely removed?

Personally, I would say it would be a big step back for libsass to stop supporting css imports, this will either mean:

• libraries using libsass each have to implement their own custom importers for supporting css
• or the average user (who I guess has no idea about custom importers or how to implement them) loses the right to import css into their sass, thereby losing all the benefits of checking and compressing css.

I don't use ruby, I'm not going to and I couldn't care less what it does and doesn't do. Please can we keep sass_option_push_import_extension.

[xzyfer]

Apologies for not being clear. The release notes have since been updated to hopefully be more clear.

I don't use ruby, I'm not going to and I couldn't care less what it does and doesn't do

Firstly this isn't us vs Ruby. Sass is a language with a specification like any other. The Ruby implementation is the source of truth for the Sass language specification.

Raw CSS imports is a feature that violates the Sass language spec, and should never have been in LibSass. It must be removed.

---

Since people have become so dependant on it we need to remove it in a responsible way.

As such we're making it an opt-in behaviour via sass_option_push_import_extension. This API is not going away until there is a Sass language compliant way to do this. Such a feature is planned for the 4.0 modules system.

The deprecation warning was added in 3.5.x because there aren't sufficient hooks in LibSass for an implementor to performantly produces the correct deprecation warning. It is the deprecation warning that will be removed in 3.6.

This is where we would expect implementors to bump their majors should the desire to maintain spec compliance.

[samuelcolvin]

Thanks for clarifying.

I've just read the module proposal for sass 4 and it looks great.

[raxod502]

See also sass/node-sass#2362 for dealing with this on the node-sass end.