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

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.

Why FontAwesome Breaks this?

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.

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

---

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 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 have the same issue and I resolve this by adding mismatch images files use on css background rule with relative url.

My assets was:

• assets
• • sass
• • • _fileA.scss
• • • main.scss

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

• assets
• • images
• • • sprite-skin-flat.png
• • sass
• • • _fileA.scss
• • • main.scss

(sorry for approximate english)

Same issue here.

This also seems to happen when referencing custom fonts being loaded from the public directory in sass.

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 👍

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.

I had same issue, moving images folder from public to assets fixed it.

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.

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

I found an issue

Simple example

-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

NOTES:

-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

Real life example:

-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”

Another issue:

-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”

Conclusion

-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!

I have the same issue https://screencast.com/t/15nTaNVrgZL when using @import “vendor/font-awesome/font-awesome”;

Got no idea why, but using URL() (uppercase) instead of url() (lowercase) fixed it for me … :\

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');

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

I had the same problem, and in my case it was triggered by importing the same file twice in SCSS. My main SCSS file imports file a and b; a imports c; b imports d; and d imports also c (Of course the files are not really named like this and also import loads of other files, but this isolates the problem). This results in c being imported twice and triggers the infinite loop problem described here.

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.

@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! ✌️ 😉

The issue i’ve had was because of not using NPM for font-awesome.

@adriaanzon it solved my issue. Thx 👍