Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.

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.

What's the recommend way to import .css files now ? "Use a custom importer to maintain this behaviour." Can't find this in the documentation of SASS or here.

Regards

[xzyfer]

Our recommendation is to not import .css files. Doing so makes you're code non-portable and tightly couples you to a specific implementation.

In node-sass@v5 (as with all other Sass implementations):

@import "foo.css";

Will be transformed to

@import url(foo.css);

This output instructs the browser to download the file foo.css.

If you wish to inline the contents of foo.css into the output CSS file then we recommending using a CSS minification step in you build process.

All popular CSS minification libraries will inline @imports see

• https://github.com/css/csso
• https://github.com/jakubpawlowicz/clean-css
• https://github.com/matthiasmullie/minify

[webdevan]

I don't really see the value in deprecating this behavior. Is there a technical constraint?

I work on a few projects which import css files directly from npm modules because they aren't written in scss. In my use case, I have a separate scss file for each of my components and some of them extend third party npm modules by importing the css. So I can't easily rename them to scss.

@import url() is a nice option to have, but I think there are still good reasons to be able to import css as if it is scss. The syntax is compatible after all. That's why everyone adopted scss over sass in the first place because it was backwards compatible. And now it's not?

[ezze]

I still want third-party CSS files to be a part of my final single CSS built with SASS. When you use module bundlers such as Webpack relying on @import url(third-party.css) is not a good option because you have to care about copying CSS files to destination by yourself... It introduces an additional headache, especially, when your visual components styled with SASS are splitted into separate npm modules.

[xzyfer]

We don't make the rules. We are an implementator of the Sass language specification which does not allow this feature in its current form. Please direct all language feature requests to https://github.com/sass/sass

…

On Sun., 6 May 2018, 2:03 am Dmitriy Pushkov, ***@***.***> wrote: I still want third-party CSS files to be a part of my final single CSS built with SASS. When you use module bundlers such as Webpack relying on @import url(third-party.css) is not a good option because you have to care about copying CSS files to destination by yourself... It introduces an additional headache, especially, when your visual components styled with SASS are splitted into separate npm modules. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2362 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWLPNY8zGBJOojnALMllncKS3VLciks5tvelZgaJpZM4TvR3E> .

[xzyfer]

We would like to understand the use cases for this feature with in our community. So far it seems the primary use case is importing CSS from node_modules. We can provide a custom importer for this use cases relatively easily.

…

On Sun., 6 May 2018, 6:29 am Michael Mifsud, ***@***.***> wrote: We don't make the rules. We are an implementator of the Sass language specification which does not allow this feature in its current form. Please direct all language feature requests to https://github.com/sass/sass On Sun., 6 May 2018, 2:03 am Dmitriy Pushkov, ***@***.***> wrote: > I still want third-party CSS files to be a part of my final single CSS > built with SASS. When you use module bundlers such as Webpack relying on @import > url(third-party.css) is not a good option because you have to care about > copying CSS files to destination by yourself... It introduces an additional > headache, especially, when your visual components styled with SASS are > splitted into separate npm modules. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#2362 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAjZWLPNY8zGBJOojnALMllncKS3VLciks5tvelZgaJpZM4TvR3E> > . >

[jhildenbiddle]

Why not ship v5 spec-compliant by default with a flag that provides the current CSS import behavior for those of us who depend on it?

node-sass file.scss --import-css true

The flag could be added to a 4.x release with an updated deprecation warning that suggests setting the new flag to ensure 4.x => 5.x updates go smoothly.

I tried transferring @import inlining duties from node-sass to a separate minification library per @xzyfer 's suggestion. It works as expected for the final CSS, but adding yet-another-processor to the CSS toolchain broke sourcemaps. I am also using postcss, so identifying the issue(s) will take time and may be challenging to resolve. This is my main concern with removing the existing behavior: it breaks things, adds complexity, and the fix won't always be as simple as just adding a new lib/plugin.

All that said, I appreciate the need to align with the Sass specification. I just think a lot of people would prefer to set a flag and keep their working build working instead being forced to make changes that won't necessarily provide any benefit.

[xzyfer]

Setting a flag to allow the non-standard behaviour as suggested defeats the purpose of aligning with the Sass spec. Users are still locked into non-portable solutions and must instruct anyone who uses their code to also set the flag. Alternatively using the importer API allows for the same behaviour in a portable way. We will create an official CSS importer for the Sass JS API with v5 so that there is a non breaking path forward for those who need it. We'll also update the deprecation warning in v4 offer the importer as a solution.

…

On Sun., 6 May 2018, 8:57 am John Hildenbiddle, ***@***.***> wrote: Why not ship v5 spec-compliant by default with a flag that provides the current CSS import behavior for those of us who depend on it? node-sass file.scss --import-css true The flag could be added to a 4.x release with an updated deprecation warning that suggests setting the new flag to ensure 4.x => 5.x updates go smoothly. I tried transferring @import inlining duties from node-sass to a separate minification library per @xzyfer <https://github.com/xzyfer> 's suggestion. It works as expected for the final CSS, but adding yet-another-processor to the CSS toolchain broke sourcemaps. I am also using postcss, so identifying the issue(s) will take time and may be challenging to resolve. This is my main concern with removing the existing behavior: it breaks things, adds complexity, and the fix won't always be as simple as just adding a new lib/plugin. All that said, I appreciate the need to align with the Sass specification. I just think a lot of people would prefer to set a flag and keep their working build working instead being forced to make changes that won't necessarily provide any benefit. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2362 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWBCDWls7y69xckhgOBHco_BBo3Bxks5tvkp_gaJpZM4TvR3E> .

[xzyfer]

We appreciate everyone's feedback on making this transition as painless as painless possible.

…

On Sun., 6 May 2018, 9:11 am Michael Mifsud, ***@***.***> wrote: Setting a flag to allow the non-standard behaviour as suggested defeats the purpose of aligning with the Sass spec. Users are still locked into non-portable solutions and must instruct anyone who uses their code to also set the flag. Alternatively using the importer API allows for the same behaviour in a portable way. We will create an official CSS importer for the Sass JS API with v5 so that there is a non breaking path forward for those who need it. We'll also update the deprecation warning in v4 offer the importer as a solution. On Sun., 6 May 2018, 8:57 am John Hildenbiddle, ***@***.***> wrote: > Why not ship v5 spec-compliant by default with a flag that provides the > current CSS import behavior for those of us who depend on it? > > node-sass file.scss --import-css true > > The flag could be added to a 4.x release with an updated deprecation > warning that suggests setting the new flag to ensure 4.x => 5.x updates go > smoothly. > > I tried transferring @import inlining duties from node-sass to a > separate minification library per @xzyfer <https://github.com/xzyfer> 's > suggestion. It works as expected for the final CSS, but adding > yet-another-processor to the CSS toolchain broke sourcemaps. I am also > using postcss, so identifying the issue(s) will take time and may be > challenging to resolve. This is my main concern with removing the existing > behavior: it breaks things, adds complexity, and the fix won't always be as > simple as just adding a new lib/plugin. > > All that said, I appreciate the need to align with the Sass > specification. I just think a lot of people would prefer to set a flag and > keep their working build working instead being forced to make changes that > won't necessarily provide any benefit. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#2362 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAjZWBCDWls7y69xckhgOBHco_BBo3Bxks5tvkp_gaJpZM4TvR3E> > . >

[webdevan]

I'm lacking in the background knowledge to understand why the change, but to me it just sounds like the "Sass spec" is the problem and it should just be adjusted to allow @import of css again. I found this issue: sass/sass#556 (comment) which has been locked since 2015 and on Apr 5 it got tagged as "planned feature".

Not sure what the best approach is to handle this, but I think that any changes to syntax, cli flags or additional modules is going to cause headaches for a lot developers. Ideally, we want Sass spec to change to treat .css as .scss?

[badtant]

At first I used https://www.npmjs.com/package/node-sass-css-importer
I use webpack and then realized that even though node-sass won't import my css-files, css-loader will. So if you use that, there is no need to worry.

[TheJaredWilcurt]

@xzyfer
You tell us to go discuss it in sass/sass, but don't link to an existing thread. There is one, but it's been locked:

• Importing CSS as Sass files sass#556 (comment)

The last comment on there from @hcatlin is "We should let people use this feature".

The last comment from @chriseppstein is "I don't care if LibSass allows importing of extensionless CSS files, I only care when it contains the extension".

That thread discusses a solution that has not been implemented yet. Why remove this feature before the official solution is implemented? You have not done a good job of explaining the harm that is done by leaving this feature as is until official Sass-language support is added for a new way of doing this.

Though, like Chris, I personally see nothing wrong with the current implementation of just using an extensionless path. Extensionless paths are not supported in regular CSS, so it does not override any existing CSS syntax. I always assumed that was an intentional design decision to allow importing of CSS files in that manner, ever since I first started using Sass 4 years ago. I thought it was a clever and intuitive solution, which has worked in every Sass processor I've ever used.

Note: The error/warning mentioned in the first post of this issue occurs when using this:

@import "../node_modules/normalize.css/normalize";

Also, I will say that a solution that only supports node_modules is pretty stupid, just continue supporting CSS imports via extensionless paths. It's such a good feature from a usability standpoint.

[joemaller]

I agree that CSS-as-Sass imports have been terribly confusing. Still, I've been relying upon them for years. (Mostly just pulling in Normalizer from node_modules)

However, all our CSS pipelines also use Autoprefixer via PostCSS, and adding PostCSS-Import for inlining CSS imports is really trivial.

After an initial WTF moment, I actually prefer this. It's obvious that CSS imports are different from Sass imports and inlining via PostCSS makes sense.

There are a couple caveats: First, Sass hoists native CSS @imports to the top of output files, which might differ from where the imports occur -- doesn't change how it all works though. Second, as mentioned above, Sass minification obviously doesn't affect inlined imports, so production pipelines should use a separate minifier, I just added cssnano to the list of PostCSS plugins.