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

[ghost]

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, [e-mail]
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
https://github.com/sass/node-sass/issues/2362#issuecomment-386824151,
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, [e-mail] 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, [e-mail]
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
https://github.com/sass/node-sass/issues/2362#issuecomment-386824151,
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, [e-mail]
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
https://github.com/sass/node-sass/issues/2362#issuecomment-386845715,
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, [e-mail] 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, [e-mail]
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
https://github.com/sass/node-sass/issues/2362#issuecomment-386845715,
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: https://github.com/sass/sass/issues/556#event-1557715138 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:

• https://github.com/sass/sass/issues/556#event-1557715138

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.

[ryanelian]

IMHO this feature / bug should not be deprecated before the official Sass module system is developed...

https://github.com/sass/language/blob/master/proposal/module-system.md

These are goals that are based less on philosophy than on practicality. For the most part, they're derived from user feedback that we've collected about @import over the years.

• Using CSS files. People often have CSS files that they want to bring into their Sass compilation. Historically, @import has been unable to do this due to its overlap with the plain-CSS @import directive and the requirement that SCSS remain a CSS superset. With a new directive name, this becomes possible.

[xzyfer]

The documentation linked to clearly states that if the file being imported
has a .CSS extension then Sass will output an @import statement (not
inline the import). This is exactly what the new behaviour will be. In
order to match the documentation

On Fri., 11 May 2018, 11:14 am Dinand Mentink, [e-mail]
wrote:

Not sure about this, but importing .css using the @import
https://github.com/import rule is documented (sass behaviour)[
https://sass-lang.com/documentation/file.SASS_REFERENCE.html#import].
Also, the backwards compatibility is what makes scss as usefull as it is.

I myself rely heavily on this behaviour, as do others, to compile css
files from node_modules into my app.css in a large number of projects.

Why is this behaviour (documented, expected, used in practice) being
phased out? Is it technically complex? Does it lead to other issues?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388308890,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWBIe_KDS-TfEZIO-OS_CmAmpltFOks5txVaEgaJpZM4TvR3E
.

[dinandmentink]

Ah. I was mistaken. Thanks for clarification!

[xzyfer]

There's is no room for compromise. The issue is simple. The current
behaviour violates the language specification. The focus now is easing the
transition in a portable way.

For the record this bug is a real problem that has caused significant pain.
It causes infinite loops when the output directory is the same as the
input directory.

On Sat., 12 May 2018, 12:30 am webdevan, [e-mail] wrote:

What about a compromise. If no extension is specified in the @import
https://github.com/import and no scss or sass file exists, then make
the exception and inline the css file as if it were scss?

But if I am understanding this correctly, sass spec should never have used
the @import https://github.com/import keyword to inline styles. by
doing so they are not honoring the css spec. They ought to use a different
keyword for inlining scss or they could compile the import to a separate
css file which then gets the @import https://github.com/import in the
css. I just find it odd that this is suddenly a problem after so long and I
am not convinced that it is worth deprecating the feature until actually
necessary.

What about adding a /* dont-inline */ comment if you want the @import
https://github.com/import to remain as @import
https://github.com/import after css compilation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388501390,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWFiDiRmUy-3W9Sihv63td_GZ9oqIks5txhEDgaJpZM4TvR3E
.

[TheJaredWilcurt]

It seems as though we may be talking about two different things in this thread, and it is causing confusion.

1. Using @import "file"; to import a .css file and have it inlined. Doing this is in accordance with the @import documentation, and should continue to be allowed. However the documentation should make this more explicitly clear. This functionality should remain intact as it is part of most developer's workflows, solves a common problem, and adheres to the language specification. We should stop displaying warning/error messages in node-sass when people import extensionless CSS files.
2. Using @import "file.css"; and expecting it to inline the styles. This functionality violates the Sass language specification. It should be removed. The expected behavior should be that the outputted CSS file contains the same original import code @import "file.css";. This will keep node-sass in line with the Sass language specification, and the goal of being a superset of CSS. Those currently relying on importing CSS in this manner for the purpose of inlining the styles should continue to see the warning/error message in node-sass. However the message should be udpated to be more helpful, by advising developers to remove the .css extension if they would like for the code to be imported in the same manner as .sass and .scss files. I think linking to an online explanation page may be good as well (could be a closed and locked GitHub issue with a link to this one for discussion). Something that gives more information behind why they are seeing the message and what steps to take to resolve it.

Here is a rough example of the explanation text that could be used:

---

Node-sass has detected you are importing a CSS file in your Sass code. Soon we will change how we handle the importing of CSS files in node-sass. You should update your code to follow one of these two patterns depending on your intention.

1. If your intention is to have the browser make a network request to retrieve this CSS file at page load, then you should update your code from:

@import "file.css";

to:

@import url('file.css');

1. If your intention is to have the CSS imported and inlined in the same manner as a .sass or .scss file, then you should remove the .css file extension, like so:

@import "file";

To read more about this change and the discussion around it, see Issue https://github.com/sass/node-sass/issues/2362.

---

Node-sass should be updated so that the warning messages do not occur on extensionless imports, and on imports using url(). The remaining warning should be updated to be more helpful and point to additional information, like the suggestion above.

[xzyfer]

Can you please reference the documentation for your first point? To my
knowledge these two cases are the same case and that Sass never inlines
anything that isn't a .scss or .sass file on disk.

On Sun., 13 May 2018, 5:24 pm The Jared Wilcurt, [e-mail]
wrote:

It seems as though we may be talking about two different things in this
thread, and it is causing confusion.

1. Using @import "file"; to import a .css file and have it inlined.
   Doing this is in accordance with the @import documentation
   https://sass-lang.com/documentation/file.SASS_REFERENCE.html#import,
   and should continue to be allowed. However the documentation should make
   this more explicitly clear. This functionality should remain intact as it
   is part of most developer's workflows, solves a common problem, and adheres
   to the language specification. We should stop displaying
   warning/error messages in node-sass when people import extensionless CSS
   files.
2. Using @import "file.css"; and expecting it to inline the styles.
   This functionality violates the Sass language specification. It should be
   removed. The expected behavior should be that the outputted CSS file
   contains the same original import code @import "file.css";. This will
   keep node-sass in line with the Sass language specification, and the goal
   of being a superset of CSS. Those currently relying on importing CSS in
   this manner for the purpose of inlining the styles should continue to see
   the warning/error message in node-sass. However the message should be
   udpated to be more helpful, by advising developers to remove the .css
   extension if they would like for the code to be imported in the same manner
   as .sass and .scss files. I think linking to an online explanation
   page may be good as well (could be a closed and locked GitHub issue with a
   link to this one for discussion). Something that gives more information
   behind why they are seeing the message and what steps to take to resolve it.

Here is a rough example of the explanation text that could be used:

Node-sass has detected you are importing a CSS file in your Sass code.
Soon we will change how we handle the importing of CSS files in node-sass.
You should update your code to follow one of these two patterns depending
on your intention.

1. If your intention is to have the browser make a network request to
   retrieve this CSS file at page load, then you should update your code from:

@import "file.css";

to:

@import url('file.css');

1. If your intention is to have the CSS imported and inlined in the
   same manner as a .sass or .scss file, then you should remove the .css
   file extension, like so:

@import "file";

To read more about this change and the discussion around it, see Issue

#2362 https://github.com/sass/node-sass/issues/2362.

Node-sass should be updated so that the warning messages do not occur on
extensionless imports, and on imports using url(). The remaining warning
should be updated to be more helpful and point to additional information,
like the suggestion above.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388634848,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWAhteLqbZemhfv8JmI_mXob2cKY_ks5tyFAegaJpZM4TvR3E
.

[farneman]

I believe the relevant lines of the Sass docs are:

@import takes a filename to import. By default, it looks for a Sass file to import directly, but there are a few circumstances under which it will compile to a CSS @import rule:

• If the file's extension is .css.
• If the filename begins with http://.
• If the filename is a url().
• If the @import has any media queries.

If none of the above conditions are met and the extension is .scss or .sass, then the named Sass or SCSS file will be imported. If there is no extension, Sass will try to find a file with that name and the .scss or .sass extension and import it.

From the way I read that last line it seems to indicate that it doesn't matter wether the @import reference has an extension, only the extension of the actual file that it's pointing to. I could be misinterpreting it though.

[xzyfer]

If there is no extension, Sass will try to find a file with that name and
the .scss or .sass extension and import it.

If no extension is given only .scss and .sass files will be considered.
Sass will not even try to find .css file on disk. So the import will not be
found.

On Sun., 13 May 2018, 9:22 pm Josh Farneman, [e-mail]
wrote:

@xzyfer https://github.com/xzyfer Is there an issue or anything to
track progress/help contribute to the custom importer solution that was
mentioned above?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388649806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWJAH2E6aH0q5WAz09R9-k4KjV2M6ks5tyIfygaJpZM4TvR3E
.

[jhildenbiddle]

Based on @farneman 's quote from the Sass docs, I'd argue that the spec is ambiguous as to how extension-less CSS files will be handled.

@import takes a filename to import. By default, it looks for a Sass file to import directly, but there are a few circumstances under which it will compile to a CSS @import rule:

• If the file's extension is .css.
• If the filename begins with http://.
• If the filename is a url().
• If the @import has any media queries.

An extension-less CSS file does not meet this criteria.

If none of the above conditions are met and the extension is .scss or .sass, then the named Sass or SCSS file will be imported.

An extension-less CSS file does not meet this criteria.

If there is no extension, Sass will try to find a file with that name _and the .scss or .sass extension_ and import it.

Note the emphasis (mine). An extension-less CSS file meets none of the above criteria, so it's left up to interpretation as to how they should be handled.

[xzyfer]

That is not the spec, it is just documentation. The spec is contained in
the sass/sass-spec repository. The sass/ruby-sass implementation is the
reference. Any ambiguous or us spec'd behaviour deferrers to the reference
implementation.

I'll reiterate again, the change in behaviour is non negotiable. There are
established rules we must follow. Discussion should be aimed at
understanding the current use cases for this existing incorrect behaviour
and how to mitigate the impact to the ecosystem.

On Sun., 13 May 2018, 9:51 pm John Hildenbiddle, [e-mail]
wrote:

Based on @farneman https://github.com/farneman 's quote from the Sass
docs, I'd argue that the spec is ambiguous as to how extension-less CSS
files will be handled.

@import https://github.com/import takes a filename to import. By
default, it looks for a Sass file to import directly, but there are a few
circumstances under which it will compile to a CSS @import
https://github.com/import rule:

• If the file's extension is .css.
• If the filename begins with http://.
• If the filename is a url().
• If the @import https://github.com/import has any media queries.

An extension-less CSS file does not meet any of these criteria.

If none of the above conditions are met and the extension is .scss or
.sass, then the named Sass or SCSS file will be imported.

An extension-less CSS file does not meet this criteria.

If there is no extension, Sass will try to find a file with that name and
the .scss or .sass extension and import it.

Note the emphasis (mine). An extension-less CSS file meets none of the
above criteria, so it's left up to interpretation as to how they should be
handled.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388651521,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWNULgZ4pYmJffL-IyINe27lo8cNkks5tyI6tgaJpZM4TvR3E
.

[webdevan]

I think @xzyfer's points are valid.

My opinion:
1) SASS shouldn't have used @import to mean something different to what CSS @import means. They should have used a different keyword to inline imports vs network request.
2) Node-Sass shouldn't have allowed @import of CSS files to be inline (as convenient as this "feature" was).
3) Discussion should be aimed at understanding the current use cases and how to mitigate the impact of the change.

The current use cases are importing inline .css files from places (usually ./node_modules/) where SASS was not used.

Personally, I think the easiest way to mitigate this would be to have one extra npm module that we have to install when we upgrade to the new node-sass, if we want all of our @imports to be inline instead of network requested. Perhaps the deprecation notice could also inform us of this extra npm install that we should do. Then, at least it's a once off fix that we we can easily apply to all projects that ever relied on @import 'css-file';

[xzyfer]

Thanks @webdevan. That appears to be the primary (if not only) widely used
use case for this feature. It's perfectly reasonable for node-sass to
integrate such a library in the form of a custom importer before the
removal of raw CSS imports.

On Sun., 13 May 2018, 11:42 pm webdevan, [e-mail] wrote:

I think @xzyfer https://github.com/xzyfer's points are valid.

My opinion:

1. SASS shouldn't have used @import https://github.com/import to
   mean something different to what CSS @import
   https://github.com/import means. They should have used a different
   keyword to inline imports vs network request.
2. Node-Sass shouldn't have allowed @import https://github.com/import
   of CSS files to be inline (as convenient as this "feature" was).
3. Discussion should be aimed at understanding the current use cases
   and how to mitigate the impact of the change.

The current use cases are importing inline .css files from places (usually
./node_modules/) where SASS was not used.

Personally, I think the easiest way to mitigate this would be to have one
extra npm module that we have to install when we upgrade to the new
node-sass, if we want all of our @imports https://github.com/imports to
be inline instead of network requested. Perhaps the deprecation notice
could also inform us of this extra npm install that we should do. Then, at
least it's a once off fix that we we can easily apply to all projects that
ever relied on @import 'css-file';

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-388658113,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWAgZWgk1Qyo72vHVRGuwofh_ftGFks5tyKjVgaJpZM4TvR3E
.

[chriseppstein]

I'd argue that the spec is ambiguous as to how extension-less CSS files will be handled.

@xzyfer is right that we need the implementations to match for default behavior. If they don't, a sass file will stop being portable across implementations (if a sass file developed on node-sass imports a css file, even sans extension, that file won't work in other implementations).

But, it is ok as an optional feature that defaults to false. So node-sass can be perfectly compliant as a Sass implementation if it decides to provide a configuration option to enable css imports as long as it respects the documented rules about what causes an @import to become a pure css-based import. Then sass authors know when they are depending on a feature that is non-standard and requires some additional set-up.

In the long term, libSass should add a parser mode that imports css files without parsing them with any additional Sass syntax or semantics. this will ensure forward compatibility with CSS if it ever changes in a way that collides with a Sass enhancement. Such changes do not arrive unannounced, so there is ample time to build this and roll it out with appropriate deprecation warnings.

SASS shouldn't have used @import to mean something different to what CSS @import means. They should have used a different keyword to inline imports vs network request.

We agree. Sass 4 will deprecate @import in favor of @use and Sass 5 will return @import to CSS with no overloaded meaning.

Node-Sass shouldn't have allowed @import of CSS files to be inline

Technically, it's a libSass thing. But I agree. I gave hampton a piece of my mind about this quite some time ago ;)

Personally, I think the easiest way to mitigate this would be to have one extra npm module that we have to install when we upgrade to the new node-sass

Adding eyeglass to your node-sass project adds a custom importer that by default allows all imports without an extension to resolve to css files. Plain CSS files are parsed as scss syntax.

Eyeglass also makes it easy to import from node_modules if an npm package is configured as an "eyeglass module" or if you manually configure your project to describe the layout of those node packages that are not specifically designed to work with eyeglass.

Eyeglass is a bit heavy-weight for this single use-case, but it exists now and adds a lot features and useful functionality for distributing Sass files as npm modules. I built it as the successor to Compass, with a focus on helping the community collaborate.

[jhildenbiddle]

There is no argument regarding the need for node-sass to align with the Sass specification. It should. The concern is with how a soon-to-be-released breaking change to behavior that has been in place for years will affect people and what (if anything) can be done to mitigate the issues it will cause.

Sell painkillers, not vitamins.

Aligning with a specification and making Sass code portable are good things. The side effects of doing so are broken builds that may or may not be easy to fix. There would be less pushback on the good things if the bad things were addressed earlier and with less resistance. Knowing that the current behavior will be made available in some form is the painkiller folks are looking for.

Hope that doesn't sound critical. It's just some friendly advise for when people get their shorts twisted over the next breaking change.

Very much appreciate the work, and thanks for landing on a solution.

[webdevan]

Sass 4 will deprecate @import in favor of @use and Sass 5 will return @import to CSS with no overloaded meaning.

I can't seem to find any concrete docs for @use, but if @use will replace @import in Sass 4 then perhaps the best thing to do is implement @use before deprecating @import in node-sass? Or at least add @use as an alias for @import in the interim.

This would offer a solution to the problem. The deprecation warning can say @import is deprecated in Sass v4, please use @use instead. See url for more info.

Doing a find-replace of @import to @use is trivial and probably the best way forward IMO. The developer must be aware they have just installed or upgraded node-sass when the deprecation appeared so they can either change their code or revert to an older version.

Of coarse, this all hinges on @use 'filename'; in Sass 4 having the same meaning as @import 'filename'; has now.

[chriseppstein]

@webdevan https://github.com/sass/language/blob/master/proposal/module-system.md

To be entirely clear, Sass isn't deprecating the use of @import with CSS files. The behavior of Sass with CSS files has been in place since before the first line of libSass was written. There used to be many such incompatibilities, but that number has grown increasingly small thanks to the teams' hard work.

If the libSass and node-sass teams have the cycles to begin working in earnest on Sass 4, I don't think we'd object to waiting on this change to libSass for a while.

But as things stand, it's not clear to me that the teams have the resources to do that Sass 4 release any time soon. It's not a trivial amount of work. So, absent that, I'd rather all the implementations get on the same page even it's a little painful.

To be honest, we really need more people contributing patches in proportion to the number of people filing comments on github issues. Most of Sass's several implementations are maintained by like 4 major contributors. Most of the development on LibSass is done by @mgreter with @xzyfer helping and most of the dev on node-sass is @xzyfer. @nex3 does most of the work on the language and dart implementation. I used to work quite a bit on these projects, but lately I'm building new stuff. Natalie is on vacation right now so I'm helicoptering in to help put out fires.

Given that approximately 65% of web developers use sass it's astounding to me that so few of them are helping build it. It's mostly been 4-6 people who intermittently burn out and then come back to help because there's no one else. And throughout the history of Sass most of that work has been unpaid. I find no fault with @jhildenbiddle's analysis of the Best Possible Way Forward™️. But honestly, with such limited resources, some corners are going to get cut 🤷‍♂️

Please be kind and patient with @xzyfer, he's working hard and doing his best to integrate several teams' projects and bring them together for the JS community. But beyond being kind to him: help him. Do you know that he learned C++ to work on these projects? The man is a fucking hero. 🎖 🙇

We need more heros so that we can stop being heros.

[jhildenbiddle]

Thanks for providing perspective @chriseppstein, and thanks to @xzyfer, @mgreter, @nex3, and others who keep the Sass train moving.

These projects are critical to so many, and it's a safe bet that very few (including myself) are aware of just how small the teams maintaining them are. Please keep up the great work, and don't let "spirited" discussions deter you.

[catamphetamine]

@chriseppstein I guess this means that SASS has grown too big and needs a major rewrite excluding the complexity you mentioned (e.g. dropping features).
Dropping features should not be accompanied with adding any warnings in the console: I'm fine using good-old SASS (whichever version it currently is) and I don't care about the "future version" (whichever version it will be) for the time being if it won't support including CSS by inlining them.
I just don't want my console to be spammed with the warning every time the app is being run.
Yeah, I know i'm including CSS files which might not comply to the spec. Quit bugging me.
Just remove the warning because you're not removing CSS inclusion in the current major version so users must not care.
Just don't overwhelm users with the information they don't need.
And don't force them to panic and run to Google for a solution.
Because they don't need one — their code is perfectly fine in its current state.

"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".

Devs: What happened? Who updated the packages recently? Did John do it again? What does it even mean? Is our app broken now? Will it break in a matter of days? What should one do exactly? Everyone, stop implementing features and go investigate this on the internet.

If you still want to show users the deprecation warning then you should at least make it more meaningful, otherwise you're just wasting people's time and bringing heat upon yourself.

[chriseppstein]

As I've said a few times now: If libSass and node-sass want to add a command line flag and api option to allow the old behavior, they can do so.

I also think node-sass could make a simple plugin system to make installing new importers, functions, etc very trivial.

I think they could reasonably decided to remove the deprecation warning while they build one of those two solutions.

But right now, we have multiple implementations with different default behaviors and that's not acceptable. Sass files need to be portable. We want the community to have the choice to move from one implementation to another. We want the community to share Sass libraries.

Obviously, the alternative is that the other implementations match the current node-sass behavior. Natalie has valid and specific concerns about future css compatibility with the current approach, that make matching node-sass's behavior problematic.

For the time being, you can lock node-sass to 4.8.3 until this issue is resolved with a straightforward evolution path.

[webdevan]

Thank you to the devs who build and maintain such great tools like this. I depend heavily on node-sass and I am only trying to help by offering some suggestions and feedback.

Two weeks ago these deprecation warnings caused me to go searching for a fix, which led me here, only to find out that there isn't a fix. Today a team member checked out a project and they were concerned by the same warnings filling their terminal. Npm console warnings/errors can feel quite daunting if you don't understand what they want you to do.

I would like if/when I see a warning, if I can immediately do something that will fix it and 10 minutes later I can get on with my work. That is the kind of solution I was hoping this discussion would uncover.

If I look in the package.json of an Angular project there is no node-sass which I can lock down to any specific version. It's probably a dependency of a dependency of Angular.

The reason I don't like the CLI flag approach is because lots of devs use build tools and they don't even know where to find the CLI commands. Take ng serve for example, I assume its using Webpack which I assume is using node-sass, but I have no idea how/where I could add the flag if I wanted to. Grunt, Gulp, Webpack, Parcel, and Angular are just some of the ways my projects have used node-sass and it's not always straight forward (or possible?) to add a CLI flag or lock down the version in many cases.

Personally I think the devs who use node-sass daily deserve some consideration when settling on a solution as there are simply so many of us affected.

If at all possible it would be really great if you could remove the the deprecation warning, then figure out a practical way to handle it, then if still needed add it back together with the suggested course of action to prevent the warnings from appearing.

[chriseppstein]

I will leave the decisions about how to proceed to @xzyfer. I hope that I've been able to provide enough flexibility so that node-sass can find a reasonable path forward that aligns the implementation to the spec without making it too onerous for existing node-sass users.

it's not always straight forward (or possible?) to add a CLI flag or lock down the version in many cases.

Ultimately, node-sass cannot be constrained by decisions outside their control. Most build integrations provide straight-forward access to the compilation options. If the node-sass and/or libsass teams decide to add an option and ng serve doesn't provide a path to customizing the sass build options, that is an issue you'll need to take up with the angular team.

I think the devs who use node-sass daily deserve some consideration when settling on a solution as there are simply so many of us affected.

We do too. If that weren't true, this issue would be closed, wouldn't it?

[catamphetamine]

@thibaudcolas Yes, this was also a breaking change for us which broke the website's CSS.
The library authors should have incremented the major version number according to the semver spec instead of releasing this as just a "feature" release (which it isn't).

We had to rewrite *.css inclusion with direct Webpack require()s to preserve the original import order (we're using Webpack in our project).

[nex3]

I'd like to push for creating an importer package that supports this behavior, rather than adding a flag. Such a flag won't be supported by Dart Sass, so it's just pushing the implementation incompatibilities up another layer. An importer will work across all implementations.

[chriseppstein]

I'd like to push for creating an importer package that supports this behavior, rather than adding a flag. Such a flag won't be supported by Dart Sass, so it's just pushing the implementation incompatibilities up another layer.

@nex3 sass spec does not specify cli options or language-specific APIs as part of the language specification at this time. I agree that it is pushing the incompatibilities "up a layer" but that is a layer that is implementation specific and reasonable differences are expected and we've been pretty clear that to implementors that API surface is not governed by sass-spec.

An importer will work across all implementations.

Importers as a concept, yes. But importers are specific to the implementation's api. I'm not sure I understand your point here. Are you saying that thanks to the extra compatibility that dart sass provides against node-sass's public API that a single importer will work with those two implementations?

[xzyfer]

I'd like to push for creating an importer package that supports this behavior, rather than adding a flag

This is also my preference. Adding a flag will require adding additional functionality to LibSass opening the door for all implementors to introduce this incompatibility.

Projects like libsass-python have already baked in a custom importer into their core as a way to maintain the ability to import .css files transparently to their users.

a single importer will work with those two implementations?

I believe this to be the case, at the very least the intention.

[adrienWeiss]

I've been trying to find a way to correctly inline normalize.css file after seeing the deprecation warnings, and this is what I came up with :
in SCSS file : @import '~normalize.css/normalize.css'; (I had @import 'normalize.css/normalize'; before, with node_modules added to the includePaths option)

in my gulpfile (or any node-sass config object)

importer: (url, prev, done) => {
  if (url.startsWith('~')) {
    return done({
      contents: fs.readFileSync(path.resolve(__dirname, 'node_modules', url.slice(1)), 'utf8'),
    });
  }
  return done({ file: url });
},

I honestly have no idea if it is the right way to do it, but so far it seems to work.
If anyone has a better way of doing it, please share !

[xzyfer]

That's certainly a way. The full implementation is a bit more complex
because node_modules can be nested. We'll supply an official importer
shortly.

On Tue., 22 May 2018, 12:01 pm Adrien Weissberg, [e-mail]
wrote:

I've been trying to find a way to correctly inline normalize.css file
after seeing the deprecation warnings, and this is what I came up with :
in SCSS file : @import '~normalize.css/normalize.css'; (I had @import
'normalize.css/normalize'; before, with node_modules added to the
includePaths option)

in my gulpfile (or any node-sass config object)

importer: (url, prev, done) => {
if (url.startsWith('~')) {
return done({
contents: fs.readFileSync(path.resolve(__dirname, 'node_modules', url.slice(1)), 'utf8'),
});
}
return done({ file: url });
},

I honestly have no idea if it is the right way to do it, but so far it
seems to work.
If anyone has a better way of doing it, please share !

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-390934934,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWDpEAXFa4cufI3wQvnO_RnpAYeSGks5t0-HtgaJpZM4TvR3E
.

[chriseppstein]

I honestly have no idea if it is the right way to do it, but so far it seems to work.
If anyone has a better way of doing it, please share

@xzyfer @adrienWeiss importers should not be invoked when the import argument triggers the css @import logic. The import of '~normalize.css/normalize.css' should cause a deprecation warning because it ends in .css and the old argument of 'normalize.css/normalize' should not give a deprecation warning if it’s resolved by an importer (but should if it’s resolved by the builtin resolver).

The custom importer should resolve the css extension. @xzyfer can you confirm that the deprecated behavior includes the situation where libSass is calling importers on css imports? We have a bug in eyeglass related to this: https://github.com/sass-eyeglass/eyeglass/issues/177

[xzyfer]

I can't say for sure. I'll need to do some experiments. I don't believe
LibSass makes a distinction between Sass and CSS imports.

https://github.com/sass/libsass/issues/2096

I _think_ importers are invoked for any import that isn't a url() or a
URL.

On Tue., 22 May 2018, 7:04 pm Chris Eppstein, [e-mail]
wrote:

I honestly have no idea if it is the right way to do it, but so far it
seems to work.
If anyone has a better way of doing it, please share

@xzyfer https://github.com/xzyfer @adrienWeiss
https://github.com/adrienWeiss importers should not be invoked when the
import argument triggers the css @import https://github.com/import
logic. The import of '~normalize.css/normalize.css' should cause a
deprecation warning because it ends in .css and the old argument of
'normalize.css/normalize' should not give a deprecation warning if it’s
resolved by an importer (but should if it’s resolved by the builtin
resolver).

The custom importer should resolve the css extension. @xzyfer
https://github.com/xzyfer can you confirm that the deprecated behavior
includes the situation where libSass is calling importers on css imports?
We have a bug in eyeglass related to this: sass-eyeglass/eyeglass#177
https://github.com/sass-eyeglass/eyeglass/issues/177

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-391066934,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWHfR5K2UBsuPcr0OQXw14Zn_sNL1ks5t1EUIgaJpZM4TvR3E
.

[nex3]

@chriseppstein

Are you saying that thanks to the extra compatibility that dart sass provides against node-sass's public API that a single importer will work with those two implementations?

Yep, that's exactly right.

@xzyfer

I _think_ importers are invoked for any import that isn't a url() or a URL.

As Chris said, this is incorrect behavior. Any import ending with .css should always be considered a plain CSS import, and importers should not be able to override this.

[xzyfer]

Yes, I understand. The issue above is about changing that behaviour.

Unfortunately doing so would give us no work around for the issue people
here are experiencing until @use lands.

On Tue., 22 May 2018, 10:04 pm Natalie Weizenbaum, [e-mail]
wrote:

@chriseppstein https://github.com/chriseppstein

Are you saying that thanks to the extra compatibility that dart sass
provides against node-sass's public API that a single importer will work
with those two implementations?

Yep, that's exactly right.

@xzyfer https://github.com/xzyfer

I think importers are invoked for any import that isn't a url() or a
URL.

As Chris said, this is incorrect behavior. Any import ending with .css
should always be considered a plain CSS import, and importers should not be
able to override this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-391122625,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWMxTvjOqZlGn5D1Pg17WIN86Q7tzks5t1G9qgaJpZM4TvR3E
.

[nex3]

Isn't the importer that workaround?

[xzyfer]

Only for the case where the .CSS extension is omitted from the import. The
point I was making is that currently LibSass does not care differentiate
between importing foo.css and foo (that resolves to foo.css)

On Tue., 22 May 2018, 11:44 pm Natalie Weizenbaum, [e-mail]
wrote:

Isn't the importer that workaround?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-391150674,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWAkHtElE-lk7iloOD864Gqn27R9iks5t1IafgaJpZM4TvR3E
.

[nex3]

Users would have to update their stylesheets in the case where they explicitly wrote .css, but that shouldn't be too difficult.

[xzyfer]

Yep completely agree.

The npm ecosystem could make it non-trivial because 3rd packages may
reference imports as .css.

Removing the extension could break other tools like postcss plugins or
minifiers that inline imports.

In summary, adding an importer will really this pain point whiksty
maintaining BC. That means that .css imports will be resolved regardless of
whether the extension is present in the import directive.

The additional fix in LibSass to not execute importers for import
directives with a .css extension is an additional breaking change.
(Assuming I am correct about the current importer behaviour in LibSass.
This needs to be verified)

On Wed., 23 May 2018, 12:28 am Natalie Weizenbaum, [e-mail]
wrote:

Users would have to update their stylesheets in the case where they
explicitly wrote .css, but that shouldn't be too difficult.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-391160838,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWDRxPI_pzZQAWmcpkBn77GlOp7lwks5t1JENgaJpZM4TvR3E
.

[nschonni]

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.

Right, this matches the CSS spec, which doesn't allow imports after any rules https://developer.mozilla.org/en-US/docs/Web/CSS/@import

The more I read this, I think the solution isn't an @import plug-in to redo the old non-standard behaviour, but a custom function like inline-file(path/file.css) that is still a separate package. This may have been discussed on the old libsass thread about removing this behaviour.

[chriseppstein]

I think the solution isn't an @import plug-in to redo the old non-standard behaviour

Right. What I've been trying to say is that the if libSass is compliant with how sass-spec works then there is no way to provide a transparent change with no backwards incompatibility if a user is expecting to import a css file for some subset of arguments to @import. But it is possible to provide a migration path that allows importing CSS with changes to some stylesheets and only minor updates to project config and code.

a custom function like inline-file(path/file.css)

@nschonni I don't understand what this means. Are you suggesting @import inline-file(path/file.css)?

In ruby sass I provided an importer that has provided this capability for the last 5 years:
https://github.com/chriseppstein/sass-css-importer#sass-css-importer-plugin

The syntax is @import "CSS:<path-without-extension>".

[nschonni]

I was thinking of https://github.com/sass/node-sass#functions--v300---experimental, but I think what you describe in your other plug-in makes more sense

[remotezygote]

After reading this long thread, I still have no idea what to do about these warnings I'm all of a sudden getting. Is there a "here's what you do to make these warnings go away" thread anywhere? I have not seen an actual solution put forth to BOTH 1) keep your CSS imports working (people rely heavily on this) AND 2) make these warnings go away. If there is no such solution, these warnings are clearly premature. #1 seems to not be an issue, yet, as it does still work, but #2 seems to be impossible other than drastic and vast changes to completely separate your CSS from your SASS, which seems extremely dumb to me. Am I missing something? I'd be really happy if I'm just being dumb and missing something obvious... I have tried many variations on the custom importer suggestion, but it seems to have no effect at all on these warnings.

[nex3]

@xzyfer I think you need to create and package a custom importer to address this as soon as possible, and link to that importer in the deprecation warning.

Another strange aspect of CSS imports in Node Sass that I just ran into is that an importer can return a file name ending with .css and convert a dynamic import into a static import. This is also invalid behavior--importers shouldn't be able to convert one type of node into another type. As such, it should be deprecated.

[xzyfer]

I've been trying to find the least thorniest way to remove this feature.

CSS imports are not differentiated from Sass imports any layer in LibSass.

Our motivation for removing CSS imports before @use was ready was to
address an annoyance with the CLI, rather than compatibility. Specifically
it's currently possible to get into an infinite loops when the input and output
directories are the same.

We had previously made the concession to keep CSS imports around until
there was a viable alternative. At this point in time I don't see one that's can
be achieved without some changes to LibSass. I'm also confident we can
address the CLI issue in the CLI.

Given our options I'm leaning towards

Node Sass

• create a custom importer for inlining .css files
• document the custom importer as a solution to the deprecation warning

LibSass

• add a deprecation warning when an importer is being executed on a static import
• add a deprecation warning when an importer converts a dynamic import into a static import
• prioritising @use in the LibSass feature queue

[xzyfer]

As for deprecating the custom importer behaviour, I'll first need to check
how sass-loader is using the API. We've never officially supported
returning both file and data, but it it common in the webpack community to
name Sass files with a .CSS extension. In fact I think this is the
recommendation in create react app

On Fri., 25 May 2018, 6:56 pm Michael Mifsud, [e-mail] wrote:

I've been trying to find the least thorniest way to remove this feature.
CSS imports are not differentiated from Sass imports any layer.

Forcing users to migrate to a custom importer is just shifting the issue
because we still treat the CSS file as a Sass file. Which is an additional
behaviour users will (do) rely on a that we'll again need to deprecate.

Our motivation for removing CSS imports be @use was ready was to address
an annoyance with the CLI, rather than compatibility. Specifically we could
trigger infinite loops when the input and output directories are the same.

We had previously made the concession to keep CSS imports around until
there was a viable alternative. At this point in time I don't see one that
won't cause further unnecessary disruption down the line. I'm also
confident we can address the CLI issue in the CLI.

Given our options I'm leaning towards

• reverting the deprecation warning
• adding a deprecation warning for returning a .css file extension in a
  custom importer
• prioritising @use in the LibSass feature queue

On Fri., 25 May 2018, 6:37 pm Natalie Weizenbaum, <
[email protected]> wrote:

@xzyfer https://github.com/xzyfer I think you need to create and
package a custom importer to address this as soon as possible, and link to
that importer in the deprecation warning.

Another strange aspect of CSS imports in Node Sass that I just ran into
is that an importer can return a file name ending with .css and convert
a dynamic import into a static import. This is also invalid
behavior--importers shouldn't be able to convert one type of node into
another type. As such, it should be deprecated.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2362#issuecomment-392113732,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWGyu6YH1BnDAO8Cp3ER-4Fh4Awyvks5t2DM6gaJpZM4TvR3E
.

[Jeppeskovsgaard]

What's the status on this? Can I continue to use @import for css files? If not - is there any documentation explaining how to import css files inline from now on?

[thibaudcolas]

I appreciate that this thread is getting longer than anyone would like but it would be nice to know why you deleted so many comments @xzyfer. I personally thought my, and other's contributions were constructive. I spent quite a bit of time understanding how best to tackle those CSS imports within the context of Webpack and css-loader, and my comment was the only trace I kept of that troubleshooting.

[xzyfer]

We've had some discussions around the intent of the deprecation, and how to best reach our compliance goals whilst minimising disruption to the community.

As a first step we will be removing this deprecation warning and reverting to the previous behaviour in an upcoming [email protected] release.

We're expecting to introduce some new deprecation warnings in node-sass@5 targeting specific edge case behaviours around import and custom importers. However importing of .css file remain for the time being.

Thanks everyone for your input.

For those currently facing this deprecation warning we highly encourage you stop importing .css files. In circumstances where that is not possible just wait for 4.10.

Please don't ask when it will be released. It'll happen when it's ready.

[xzyfer]

The revert has landed in LibSass. We expect a new node-sass release sometime this weekend.

[curran]

After reading the whole thread, I feel compelled to summarize my findings:

The warning message states:

Use a custom importer to maintain this behaviour. Check your implementations documentation on how to create a custom importer.

There exists a custom importer you can use: https://github.com/sass-eyeglass/eyeglass , which addresses the most common use case of importing .css files, which is from node_modules.

FWIW there's a grammatical error in the warning. It should include an apostrophe: "Check your implementation's documentation on how to create a custom importer."

[xzyfer]

@curran I have removed your "summary" comment because it was factually incorrect, and distracted from the actually summary just 2 comments above.

Additionally if you're compelled to comment my grammar then your pull request is welcome.

[curran]

Ok thanks!

[moonglum]

@xzyfer Any news on when libsass will be released with the fix? 😄

[chovy]

I'm still getting this error. Has it been released yet? I'm on 4.9.3 and I still can't import using:

@import '~bulma-divider';

[fritzmg]

@chovy https://github.com/sass/node-sass/issues/2362#issuecomment-396239814

[halfnibble]

If I understand everything I've just read (spent a good hour), then the fix as of June 11th is to wait for [email protected]. Any ETA on that? Thanks.

[chovy]

We'll run into the same problem with v5. What is the proper way of including a global css file?

[nex3]

Dart Sass supports importing plain CSS files as of 1.11.0. You can work around this by using it.

[xzyfer]

This is the latest 4.11.0 beta release. You can try it now out by installing the beta.

npm install node-sass@beta

This will land in stable next week.

[xzyfer]

No feedback received during beta. This fix has been promoted to stable in 4.11.0