Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.
opened this issue · comments
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
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
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?
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.
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 trueThe 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.
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?
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.
@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:
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.
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.
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.
Ah. I was mistaken. Thanks for clarification!
It seems as though we may be talking about two different things in this thread, and it is causing confusion.
- Using
@import "file";to import a.cssfile 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. - 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.cssextension if they would like for the code to be imported in the same manner as.sassand.scssfiles. 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.
- 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');- If your intention is to have the CSS imported and inlined in the same manner as a
.sassor.scssfile, then you should remove the.cssfile extension, like so:
@import "file";To read more about this change and the discussion around it, see Issue #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.
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.
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.
I think @xzyfer's points are valid.
My opinion:
- 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.
- Node-Sass shouldn't have allowed @import of CSS files to be inline (as convenient as this "feature" was).
- 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';
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
@importto 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
@importof 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.
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.
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.
@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.
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.
@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.
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.
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.
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?
@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).
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.
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?
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.
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 !
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: linkedin/eyeglass#177
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.
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.
Isn't the importer that workaround?
Users would have to update their stylesheets in the case where they explicitly wrote .css, but that shouldn't be too difficult.
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.
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>".
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
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.
@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.
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?
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.
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 node-sass@4.10 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.
The revert has landed in LibSass. We expect a new node-sass release sometime this weekend.
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."
@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.
Ok thanks!
@xzyfer Any news on when libsass will be released with the fix? 😄
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';
If I understand everything I've just read (spent a good hour), then the fix as of June 11th is to wait for node-sass@4.10. Any ETA on that? Thanks.
We'll run into the same problem with v5. What is the proper way of including a global css file?
Dart Sass supports importing plain CSS files as of 1.11.0. You can work around this by using it.
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.
No feedback received during beta. This fix has been promoted to stable in 4.11.0