When I run .version() under dev ... the app.js file isn't created, so that's broke.
When I run it under production, Laravel doesn't read the manifest for some reason and tries to deliver app.css and app.js which aren't found.
Perhaps I need to change my Envoyer set up?
Right now I use npm run dev in my local environment, and I have Envoyer hooks on my production server to install node modules and run Mix in production.
Do I need to change the flow of my deployments or is this going to get fixed so that it works as it did in version 5?
Can you give me specifics here? I can't help debug without seeing some of your code.
npm run dev?Hey Jeffrey.
I was using the master by calling JeffreyWay/laravel-mix in my package.json but the same issues exist all the way back to version 0.5.16 which is what I currently have installed and versioning is still failing.
Mix file:
mix.copy('node_modules/material-design-icons/iconfont', 'resources/assets/sass/fonts')
.js('resources/assets/js/app.js', 'public/js')
.sass('resources/assets/sass/app.scss', 'public/css')
.version();
Manifest file:
{
"/js/app.js": "/js/app.js",
"/css/app.css": "/css/app.css"
}
If I remove the .version() method in the mix file all works well on both dev and production, but with the method everything breaks.
And I'm using Laravel 5.4.9
Thanks.
-V
I just ran your webpack.mix.js file in dev mode, and got
https://www.dropbox.com/s/baluqem4suasyy3/Screenshot%202017-02-07%2011.36.56.png?dl=0
It all worked.
Try nuking your node_modules directory and installing from scratch. And don't use the master branch. Just stick with the latest tagged release.
Cool, thanks I'll give it a shot.
Nope ... the latest tag doesn't include the fix for issue #295 so it still fails. This is why I was pulling in the master so that pull request would be included.
These dependencies were not found in node_modules:
* ../fonts/MaterialIcons-Regular.eot
* ../fonts/MaterialIcons-Regular.woff2
* ../fonts/MaterialIcons-Regular.woff
* ../fonts/MaterialIcons-Regular.ttf
* ../fonts/roboto/Roboto-Thin.eot
* ../fonts/roboto/Roboto-Thin.woff2
* ../fonts/roboto/Roboto-Thin.woff
* ../fonts/roboto/Roboto-Thin.ttf
* ../fonts/roboto/Roboto-Light.eot
* ../fonts/roboto/Roboto-Light.woff2
* ../fonts/roboto/Roboto-Light.woff
* ../fonts/roboto/Roboto-Light.ttf
* ../fonts/roboto/Roboto-Regular.eot
* ../fonts/roboto/Roboto-Regular.woff2
* ../fonts/roboto/Roboto-Regular.woff
* ../fonts/roboto/Roboto-Regular.ttf
* ../fonts/roboto/Roboto-Medium.eot
* ../fonts/roboto/Roboto-Medium.woff2
* ../fonts/roboto/Roboto-Medium.woff
* ../fonts/roboto/Roboto-Medium.ttf
* ../fonts/roboto/Roboto-Bold.eot
* ../fonts/roboto/Roboto-Bold.woff2
* ../fonts/roboto/Roboto-Bold.woff
* ../fonts/roboto/Roboto-Bold.ttf
Did you forget to run npm install --save for them?
So for this comment:
When I run .version() under dev ... the app.js file isn't created, so that's broke.
Based on the screenshot you shared in the other issue, it was created after all. So what do you mean by this? You're trying to load app.js, but you versioned the file, so you can't hardcoded the file path.
No it wasn't ... it created a js file with a hashed filename ... but not just plain app.js like it does with the css. Versioning creates a hashed version AND an app.css file for the css, but it doesn't for the JS.
Look again at the two screens, the CSS folder has two files, the JS folder only one.
Versioning creates a hashed version AND an app.css file for the css, but it doesn't for the JS.
No it doesn't. When you request mix.version(), you're specifically asking for it to hash the output file name.
I dont mean to argue ... but it doesn't.
When I delete the css, font, and js folders, and the manifest file, and rerun npm run dev it creates:
public/css--
app.hash.css
app.css
public/font--
roboto fonts
materical icons fonts
public/js--
app.hash.js
public/mix-manifest.json
In the manifest there is no reference to hashed files, only the app.css and app.js files, since no app.js was created the whole thing fails.
Same exact situation when it's run under production except the manifest DOES reference the hashed versions, but the helper seems to fail because it doesn't find the the hashed files for some reason.
Can you create a fresh Laravel project and give me reproducible steps to see this problem for myself? Something like -
I think maybe I was getting a bad version since I was requesting 0.7.* in my package file, I switched it to 0.7.0 and now it's creating the assets correctly.
BUT ... it seems that mix refuses to adhere to the order in which processes are called.
I need to copy font files from a node package before my sass compiles, but copy always runs last, which causes mix to fail to compile the sass since the font files aren't found.
This only happens on the first run of mix since afterwards the fonts are already in place.
Is there a way to ensure that processes are run in the order they are chained?
webpack.mix file:
mix.copy('node_modules/material-design-icons/iconfont', 'resources/assets/sass/fonts')
.js('resources/assets/js/app.js', 'public/js')
.sass('resources/assets/sass/app.scss', 'public/css')
.version();
Just to follow up on this latest development, everything works fine if I run production, but running dev I get the errors that the font files aren't found.
I need to copy font files from a node package before my sass compiles, but copy always runs las
Mix doesn't work that way. It's not a series of pipes that trigger one after the other. So your copying will always take place after the compile.
Mix File
let mix = require('laravel-mix')
mix.js('resources/assets/js/app.js', 'public/js')
.sass('resources/assets/sass/app.scss', 'public/css')
.version();
Response

Mix Manifest
{
"/js/app.js": "/js/app.js?id=92b261429d3aa1b907b2",
"/css/app.css": "/css/app.css?id=b9cb5c393f3dcc0fb457"
}
For anyone still coming to this thread:
As of version 1.0
File versioning has been simplified. When using mix.version(), no longer will we version the file name, itself. Instead, we'll generate an md5 of the file's contents, and apply it as a query string to the generated mix-manifest.json file. If using a service like Cloudflare, please ensure that you've enabled querystring-based cache-busting.
So don't expect to have versioned files created. You'll just have your app.js, main.css, etc. Query strings will be referenced in the manifest file that will handle the cache busting.
@devcircus , squid and others proxies/caches and majority of browsers works OK with this querystring-based cache-busting yet?
Concerning squid, from version 2.7, they no longer have the obsolete rule of not caching when query strings are used. I don't know of any services on which query strings don't work for cache busting. There are some services which require you to explicitly set that option though.
When you use versioning, make sure to use mix("path-to-file/file.js") instead of asset("path-to-file/file.js") in your views.
When you use versioning, make sure to use
mix("path-to-file/file.js")instead ofasset("path-to-file/file.js")in your views.
I'd prefer use: asset(mix("path-to-file/file.js")) :-) my opinion
Most helpful comment
For anyone still coming to this thread:
As of version 1.0
So don't expect to have versioned files created. You'll just have your app.js, main.css, etc. Query strings will be referenced in the manifest file that will handle the cache busting.