Including .css files with @import is non-standard behaviour which will be...
:rainbow: Node.js bindings to libsass
Brought to you by:
imran1012000k
Menu
▾
▴
#2362 Including .css files with @import is non-standard behaviour which will be removed in future versions of LibSass.
Originally created by: coldtelling
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
Originally posted by: 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):
Will be transformed to
This output instructs the browser to download the file
foo.css.If you wish to inline the contents of
foo.cssinto 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
Originally posted by: 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?
Originally posted by: 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.Originally posted by: 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, notifications@github.com
wrote:
Originally posted by: 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, xzyfer@gmail.com wrote:
Originally posted by: 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 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
@importinlining duties fromnode-sassto 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 usingpostcss, 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.
Originally posted by: 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, notifications@github.com
wrote:
Originally posted by: 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, xzyfer@gmail.com wrote:
Originally posted by: 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?
Originally posted by: 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.
Originally posted by: 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:
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.
Originally posted by: 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
@importsto 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.Originally posted by: 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
Originally posted by: xzyfer
The documentation linked to clearly states that if the file being imported
has a .CSS extension then Sass will output an
@importstatement (notinline 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, notifications@github.com
wrote:
Originally posted by: dinandmentink
Ah. I was mistaken. Thanks for clarification!
Originally posted by: 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, notifications@github.com wrote:
Originally posted by: TheJaredWilcurt
It seems as though we may be talking about two different things in this thread, and it is causing confusion.
@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.@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:
:::css
@import "file.css";
to:
:::css
@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::::css
@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.Originally posted by: 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, notifications@github.com
wrote:
Related
Tickets: #2362
Originally posted by: farneman
I believe the relevant lines of the Sass docs are:
From the way I read that last line it seems to indicate that it doesn't matter wether the
@importreference has an extension, only the extension of the actual file that it's pointing to. I could be misinterpreting it though.Originally posted by: xzyfer
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, notifications@github.com
wrote:
Originally posted by: 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.
An extension-less CSS file does not meet this criteria.
An extension-less CSS file does not meet this criteria.
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.
Originally posted by: 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, notifications@github.com
wrote:
Originally posted by: 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';Originally posted by: 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, notifications@github.com wrote:
Originally posted by: chriseppstein
@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
@importto 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.
We agree. Sass 4 will deprecate
@importin favor of@useand Sass 5 will return@importto CSS with no overloaded meaning.Technically, it's a libSass thing. But I agree. I gave hampton a piece of my mind about this quite some time ago ;)
Adding
eyeglassto 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 asscsssyntax.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.