Originally reported here: https://github.com/sass/libsass-python/issues/245
@import 'cssfile';
a { b: c; }
$ pysassc --version
pysassc 0.14.2 (sass/libsass 3.5.2)
$ pysassc input.scss
a {
b: c; }
$ 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
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.
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 https://github.com/sass/libsass-python/pull/246.
Note: doing so will result in deprecation warning for .css
files. The deprecation warning will be removed in 3.6.0.
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:
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
.
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.
Thanks for clarifying.
I've just read the module proposal for sass 4 and it looks great.
See also https://github.com/sass/node-sass/issues/2362 for dealing with this on the node-sass end.
Most helpful comment
I'm very confused by the depreciation, nowhere seems clear:
vs.
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:
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
.