So it looks like the latest update causes an Infinite loop of watch when I import font-awesome.scss
file into my main app.scss
@import '../../plugins/fontawesome/font-awesome';
Same thing happens for summernote & other plugins which work with font files.
I have the same issue https://screencast.com/t/15nTaNVrgZL when using @import "vendor/font-awesome/font-awesome";
That's weird. Does it also happen when you install font-awesome via npm, and import it like this?
@import "node_modules/font-awesome/scss/font-awesome";
@adriaanzon It works fine when imported from node_modules, but fails with custom integration, when for example fonts are copied to specified folder and only scss files are used for font-awesome. Basically it means it can't find fonts, but it should not cause this loop error, maybe just warning message.
im having the same issue :/
Same issue here.
Yeah I've heard about this before with font-awesome only.
I'd be appreciative if someone would drill down and figure out what the issue is.
Make sure you're setting $fa-font-path
, which should point to the location of the fonts in the node_modules directory (they will be automatically copied by the file-loader).
$fa-font-path: '~font-awesome/fonts';
@import "~font-awesome/scss/font-awesome";
This also seems to happen when referencing custom fonts being loaded from the public directory in sass.
I have the same issue and I resolve this by adding mismatch images files use on css background rule with relative url.
My assets was:
In _fileA.scss I have this line:
background: url(../images/sprite-skin-flat.png) repeat-x;
In main.scss I have:
@import "fileA"
To solve the infinite lopp I add the image repository in my assets and it's work well
(sorry for approximate english)
Just ran into same issue.
Images in public/images seem to be the problem, so i moved them to assets/images and webpack would copy them automatically.
Thanks @CODEheures for the solution 馃憤
The issue i've had was because of not using NPM for font-awesome.
@adriaanzon it solved my issue. Thx 馃憤
This just happened to me as well. _I'm using Laravel Mix outside of Laravel (KirbyCMS)_.
The problem was that I was using@font-face
in my Sass with a wrong url()
to the font-file. The correct path would've been url("/assets/fonts/din-medium-webfont.woff2")
but I was just using url("din-medium-webfont")
.
That caused the infinite loop. After correcting the path everything was working fine. Hope that helps.
I had the same problem as @RobertCordes.
I used a wrong path within url(). When I specified the correct path everything worked as normal.
Yes using a wrong path within url() caused the loop. It would be more appropriate maybe to generate an error instead.
I have been having this infinite loop issue quite a bit. I originally determined the first culprit of the infinite loop to be the inclusion of FontAwesome. I discovered as others mentioned that installing via NPM (into node_modules/
) solves that problem.
But I also discovered the second issue later on in my project when attacking a background image via CSS/SASS. But i found something interesting.
Whenever i attach an image that is in the root of the public/images
folder, then the infinite loop problem occurs. Moving the EXACT same image (same filename, everything) into a subfolder of public images folder, then Laravel Mix would run correctly, without entering the infinite loop. So in my case i moved the image from public/images/bar.jpg
to public/images/foo/bar.jpg
and it now compiles correctly.
I have replicated this with about 5 different projects. Linking to an image at the root of the public/images
always causes an infinite loop, but linking from a subfolder (public/images/anything/
) works just fine.
Also of note, the CSS in question:
background-image: url('../images/residential/our-company.jpg');
I wouldn't call this a solution, but its a workaround that is adequate for now. Hopefully this triggers someone's thoughts to why this might be the cause of this bug, and how to fix it.
@jacurtis I can confirm that the same thing worked for me. I had an image in public/images
and moved it to public/images/patterns
then updated my SASS and it fixed it.
Thank you!
@Jared0430 I do understand why this is happening now! It appears that Laravel Mix is set up to copy images automatically to the root of public/images
folder that are accessed via SASS. This seems to be part of the process that occurs during the processing of SASS. So basically any image referenced in CSS (as opposed to those referenced in HTML <img>
tags) such as background-image
, are getting copied to public/images
as part of compiling the SASS.
So the error is occurring because it is trying to copy an image and place it where the image already exists, thus causing a conflict. The two known temporary solutions to this bug is by removing the image from the public/images
folder and putting it elsewhere (either in a subfolder like i originally suggested, or in the resources/images
folder like others have suggested). This eliminates the conflict and allows it to successfully copy and then complete it's process.
I am now noticing that images are being copied if you look at the output of Mix in the terminal. Also, if you are putting images in other places (such as subfolders, or your resources/images
folder) you will notice copies of all the images that are referenced in the SASS files, inside of your public/images
(even though you ironically moved them out of that folder to solve the problem).
Ok, i know why this is happening now (and how to solve it), for both images and fontawesome. There is an option in Laravel Mix to process all files with relative urls. It is not really discussed in the documentation, but its functionality can be inferred through an option I found on this page of the documentation which offers a brief explanation: https://github.com/JeffreyWay/laravel-mix/blob/master/docs/options.md
processCssUrls: true
processCssUrls: Process/optimize relative stylesheet url()'s. By default, Webpack will automatically update these URLs, when relevant. If, however, your folder structure is already organized the way you want it, set this option to false to disable processing.
So this option defaults to true. It then goes forth to copy relative URLs it finds in the SASS file (presumably LESS also, but i have not tested), and copies these to relative locations in the public directory (so the urls will continue to work after moving the processed .css file to the public/css
directory).
To be honest, this functionality actually makes sense, so long as you are not trying to help Webpack, by putting the files in the public directory yourself (as i think we all where) it will work as intended. The idea is to put everything in the resources/
folder and let webpack handle the public/
directory itself.
Because we pull the fontawesome.scss
file into our resources/sass
, it uses relative URLs to link to the font files. If you were putting the font files in the public/fonts
directory (as I was), then it caused a conflict because it is trying to copy the font files from where they already are to where they already are. I think this set it into some sort of infinite loop, instead of causing an actual error.
How to solve: Put the font files inside resources/fonts
and let them copy over to the public folder. After webpack processes, it will have put the files in the same place you wanted them to go anyway (public/fonts/
). As an alternative solution you could opt to install fontawesome via NPM, and require it from the node_modules/
directory. After webpack processes, it will copy the font files from your node_modules/
to your public/fonts/
. _If you prefer to manage the public folder yourself, read below to disable this._
Once again, just like above, the relative urls used in things like background-image
trigger webpack to try to "optimize and copy" the images. It is again trying to move the file from where it already is to replace it again. That is why moving the images to the resources/
folder works and so does putting them into any subfolder inside of public/images/{{subfolder}}
. It works because then webpack can copy the image from the subfolder into the public/images
without a conflict.
How to Solve: Put the images that you call in the SASS files, into resources/images
and then when webpack runs it will "optimize and copy" them into your public/images
folder at the root. _If you prefer to manage the public folder yourself, read below to disable this._
If you prefer to manage your public/
folder yourself and not have webpack attempt to copy and optimize things on your behalf then you can disable this functionality altogether. Simply go into your webpack.mix.js
file and add options onto the end of it to not process the relative urls.
Your file will look like this, with the option disabled (defaults to true):
mix.js('resources/assets/js/app.js', 'public/js')
.sass('resources/assets/sass/app.scss', 'public/css')
.options({
processCssUrls: false
});
I have tested this in a fresh Laravel install. By setting this option to false
, now both fontawesome and images placed in public/images
no longer goes into an infinite loop. When I remove the option or set the option to true
, and i run npm run watch
again, then it enters the loop. It solves this infinite loop problem!!!
Tell your friends 馃槃 ,
happy coding!
_It would be cool if we could have Laravel mix identify this and throw an error instead of going into an infinite loop which confuses new comers. At the very least we should document this in the documentation with the known solutions._
I just went through the exact same thing with icomoon.
Simple solution was to place the font folder in the styles.scss file I created in the resources/assets/sass folder
I had same issue, moving images folder from public to assets fixed it.
Same here @jagadeshanh, thank you. =)
-Let's assume we create two folders for images in "resource". One folder for "dogs", and one folder for "cats":
+1. "resource/assets/images/dogs"
+2. "resource/assets/images/cats"
-If we put two different photos inside them, but with the same name:
+"resource/assets/images/dogs/_example.png_" - this is DOG image
+"resource/assets/images/cats/_example.png_" - this is CAT image
-And, in SASS we reference those images for a background. DOG photo for dog div, and CAT photo for cat div:
+dog{ background-image: url('../images/dogs/example.png'); }
+cat{ background-image: url('../images/cats/example.png'); }
-The problem is, Laravel Mix will now create JUST ONE photo in "public/images" folder(he should create both photos). And because of that, both of those divs will have the same photo
-Referencing hash codes in css is good - so, those two divs reference "example.png" with different hash codes. But because Mix is creating just one physical photo in public folder - both "div dog" and "div cat" show the same one photo
-So, it doesn't matter if we create one or hundred folders for images in "resource", MIX can create just one photo with the same name, because he is coping everything in one folder
-We can't have folder "women" with images "1.png, 2.png, 3.png", AND folder "men" with images "1.png, 2.png, 3.png"
-The problem is, if we have "resource/assets/images/example.png" photo, and we don't need that photo anymore, we will delete that photo in resource folder, but Mix will not delete that photo he created in public folder. So, it doesn't make sense for me. If he is responsible for creating that photo, he should be responsible for deleting it too, right?
-Think if "When you delete sass files, now you must delete css files in the public folder too. And every time you delete sass file, you must go in the public folder to delete that file there too, because Mix is just creating them and not deleting them"
-I am now confused how to handle photos in general? What about photos in views for blade syntax? We can't reference those from resource folder. So, for _SASS_ we add photos in "resource" folder, but for _BLADE_ we add photos in "public" folder?
What is your recommendation for scalable project?
@jacurtis
@JeffreyWay
Thanks a lot guys!
Yeah its definitely confusing. It should be noted that this is only a problem when you are referencing images in your SCSS files. So basically this means background images. If it's a normal image that you are calling in your blade through an <img>
tag or something then you can organize those like normal in your public/images
folder, or in a storage directory for dynamically uploaded content.
Generally i don't have too many images being called through the sass file, but there was one project I dealt with where I had to and I ran into problems like those mentioned. I just had to be careful to name each image uniquely enough to prevent conflict.
The answer to your question is, "There really is no way around it. You have to just be careful." From my understanding this is actually a problem related to _Webpack_ and not _Laravel Mix_ exactly. Without a major rework, I don't think this issue is going anywhere. So our best solution is to work around it. So just keep this in mind while building your applications.
I did note a solution above if you wanted to disable this functionality altogether. Its simple to do (just set an option in your webpack.mix.js
file) to not process SCSS urls. That would be your best bet if you didn't want to "work _around_ it".
@johnylaravel I agree with you when you're talking about different folders images with same name images inside. That's an issue. It shouldn't be that way (but as mentioned by @jacurtis, we just have to understand if this is an issue from Laravel Mix or from Webpack in general (I think it's probably from Mix...).
But, when you, @johnylaravel, said that, a deleted image should also be dealt by Mix, it's just confusing. It'd but good, indeed, everyone wants automation. But when you're talking about SCSS, you also have to go there an delete the generated CSS, it's just the normal flow, isn't it?
Although that, important comment, though it's not the issue commented here. Perhaps just use processCssUrls: false
recommended by @jacurtis and be happy. Otherwise, helps us provide the functionality wanted contributing to the repo.
Peace! 鉁岋笍 馃槈
Thank you @CODEheures that's work for me 馃拑
@jacurtis solution worked for me.
This issue happened to me after creating following style for a div, does someone have an idea?
#bg-image {
background: url('../images/logo.png') no-repeat center center;
width: 100%;
height: 100%;
background-size: 30%;
margin-left: auto;
margin-right: auto;
}
Commenting this line background: url('../images/logo.png') no-repeat center center;
fixed it, but it still does not make sense to me.
This issue does not appear aswell if I run npm run hot
instead of npm run watch
.
I have run into the same issue! Simply placing my images in a different folder solved the problem.
This happens because images are being copied to the same location thus creating an endless loop.
In other words, the image in public/image/default_avatar.png is copied to the same path because it is referenced in the sass as a background URL, and because the compiler sees that something has changed, it copies it again and then compiles again and the loop goes on.
Hey guys!
I had this problem also for long time, i was using fontawesome cdn inside "laravel landingview.php" like this:
I did solve the problem by importing the cdn url from "App.vue" instead, like this:
I wish i helped!
Moving to assets folder fixed the problem. And I think it's more logical then other solutions.
In my case it was an image:
Went from:
background: url('../../public/images/background.jpg');
To:
background: url('../assets/images/background.jpg');
This problem is still existing in the current codebase.
I solved this by fixing the path of certain images, as described above (to the assets folder).
Is there any chance this could be caught as an exception, and throw an error, instead of the infinite loop of recompiling?
Cheers
Got no idea why, but using URL() (uppercase) instead of url() (lowercase) fixed it for me ... :
I have fixed it renaming _icons.scss
to _icon-set.scss
.
This was happening to me because I didn't prepend my filename with a forward slash...
This infinite looped...
@font-face {
font-family: JetBrainsMonoMedium;
src: url(fonts/JetBrainsMono-Medium.woff2) format('woff2'),
url(fonts/JetBrainsMono-Medium.woff) format('woff'),
url(fonts/JetBrainsMono-Medium-Italic.ttf) format('truetype');
font-weight: 500;
font-style: normal;
}
This worked fine...
@font-face {
font-family: JetBrainsMonoMedium;
src: url(/fonts/JetBrainsMono-Medium.woff2) format('woff2'),
url(/fonts/JetBrainsMono-Medium.woff) format('woff'),
url(/fonts/JetBrainsMono-Medium-Italic.ttf) format('truetype');
font-weight: 500;
font-style: normal;
}
This just happened to me as well. _I'm using Laravel Mix outside of Laravel (KirbyCMS)_.
The problem was that I was using
@font-face
in my Sass with a wrongurl()
to the font-file. The correct path would've beenurl("/assets/fonts/din-medium-webfont.woff2")
but I was just usingurl("din-medium-webfont")
.That caused the infinite loop. After correcting the path everything was working fine. Hope that helps.
This solved my issue with october CMS and laravel-mix. Was trying to import a font by using relative path and that was causing infinite loop on my watch script. Thank you!
It happens to me because I'm importing Bootstrap-RTL then defining some font-faces.
SOLVED by importing the bootstrap after defining the font-faces.
Most helpful comment
KNOWN SOLUTION (with explanation)
Ok, i know why this is happening now (and how to solve it), for both images and fontawesome. There is an option in Laravel Mix to process all files with relative urls. It is not really discussed in the documentation, but its functionality can be inferred through an option I found on this page of the documentation which offers a brief explanation: https://github.com/JeffreyWay/laravel-mix/blob/master/docs/options.md
processCssUrls: true
So this option defaults to true. It then goes forth to copy relative URLs it finds in the SASS file (presumably LESS also, but i have not tested), and copies these to relative locations in the public directory (so the urls will continue to work after moving the processed .css file to the
public/css
directory).To be honest, this functionality actually makes sense, so long as you are not trying to help Webpack, by putting the files in the public directory yourself (as i think we all where) it will work as intended. The idea is to put everything in the
resources/
folder and let webpack handle thepublic/
directory itself.Why FontAwesome Breaks this?
Because we pull the
fontawesome.scss
file into ourresources/sass
, it uses relative URLs to link to the font files. If you were putting the font files in thepublic/fonts
directory (as I was), then it caused a conflict because it is trying to copy the font files from where they already are to where they already are. I think this set it into some sort of infinite loop, instead of causing an actual error.How to solve: Put the font files inside
resources/fonts
and let them copy over to the public folder. After webpack processes, it will have put the files in the same place you wanted them to go anyway (public/fonts/
). As an alternative solution you could opt to install fontawesome via NPM, and require it from thenode_modules/
directory. After webpack processes, it will copy the font files from yournode_modules/
to yourpublic/fonts/
. _If you prefer to manage the public folder yourself, read below to disable this._Why Do Public/Images Breaks this?
Once again, just like above, the relative urls used in things like
background-image
trigger webpack to try to "optimize and copy" the images. It is again trying to move the file from where it already is to replace it again. That is why moving the images to theresources/
folder works and so does putting them into any subfolder inside ofpublic/images/{{subfolder}}
. It works because then webpack can copy the image from the subfolder into thepublic/images
without a conflict.How to Solve: Put the images that you call in the SASS files, into
resources/images
and then when webpack runs it will "optimize and copy" them into yourpublic/images
folder at the root. _If you prefer to manage the public folder yourself, read below to disable this._How to disable this functionality altogether?
If you prefer to manage your
public/
folder yourself and not have webpack attempt to copy and optimize things on your behalf then you can disable this functionality altogether. Simply go into yourwebpack.mix.js
file and add options onto the end of it to not process the relative urls.Your file will look like this, with the option disabled (defaults to true):
I have tested this in a fresh Laravel install. By setting this option to
false
, now both fontawesome and images placed inpublic/images
no longer goes into an infinite loop. When I remove the option or set the option totrue
, and i runnpm run watch
again, then it enters the loop. It solves this infinite loop problem!!!Tell your friends 馃槃 ,
happy coding!
_It would be cool if we could have Laravel mix identify this and throw an error instead of going into an infinite loop which confuses new comers. At the very least we should document this in the documentation with the known solutions._