-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.0.0 busting multiple times #180
Comments
Hi @olimortimer. Looks like you were using the The problem you're seeing is because the task is processing the same files over and over. It's recommended that the process for running these tasks is:
Following this mentality means that only a copy of the source files are altered. In your case, it looks like the raw source file is being altered every time the task runs. In previous versions, there was an attempt to detect when a reference to a file was already "busted" but it proved very difficult to do accurately and also meant that the above process was probably not being taken into consideration. If you provide more details of the project and setup then I might be able to help out |
I had that issue too (in a single run, it was very long), but don't know why. |
Are either of you able to create a simple test to show this happening? Could you also post the JSON output by setting The list of files to be hashed should be set in reverse alphabetically order so we shouldn't be seeing this issue. |
I was able to reproduce mine. I have multiple directories (Symfony bundles) that contains assets. I've set a config object for each bundle having base dir of all bundles (so every bundle goes through that same assets) cacheBust = { options: { baseDir: 'someRootDir' } }
cacheBust['bundle1'] = { src: 'someRootDir/bundle1/public/**/*.css' }
cacheBust['bundle2'] = { src: 'someRootDir/bundle2/public/**/*.css' } Then it would go hashing all the assets twice. "Website/CommonBundle/Resources/assets/icons/plus.svg": "Website/CommonBundle/Resources/assets/icons/plus.a2f25fe6.svg",
"Website/CommonBundle/Resources/assets/icons/plus.a2f25fe6.svg": "Website/CommonBundle/Resources/assets/icons/plus.a2f25fe6.a2f25fe6.svg",
"Website/CommonBundle/Resources/assets/icons/plus.a2f25fe6.a2f25fe6.svg": "Website/CommonBundle/Resources/assets/icons/plus.a2f25fe6.a2f25fe6.a2f25fe6.svg", I've fixed it by having a separate baseDir for each bundle (it had to point to Of course this is not the issue with @olimortimer - although I would change this line: assets: ['skin/**/css/*.css', 'skin/**/css/*.scss', 'skin/**/css/*.min.css', 'skin/**/scripts/*.js', 'skin/**/scripts/*.min.js'], to assets: ['skin/**/css/*.css', 'skin/**/scripts/*.js'], Because why hash |
Hi, I ran into the same problem. sorry, don't understand the comment #180 (comment) what do you mean by your mentality? |
What I mean by mentality is a change in the way your application builds. So many web applications have a build process that does some form of pre and post processing of these files. To make sure the build steps will produce the same results no matter how many times you run them, it's best to follow this mentality:
This will keep your source files the same. I'm assuming the problem both are having is that you running this |
@HollandBen I understand the thinking on the workflow for the src files (javascript and css etc, the files that are being renamed because their hash has changed), but are you suggesting a separate copy of the html must be maintained too? |
I'm also getting this issue, and can't think of a workaround to get my configuration working. I have the following set up: File structure:
So The gruntfile:
I have added the So i'm stuck in a catch 22, either the files are hashed multiple times or the references in the template files can't be changed. Is there a workaround, or am I missing something really simple/can't see the wood for the trees? I'm guessing the main problem is the matching rules for the assets, they are always going to match with existing hashed files and just rehash them again, as well as creating another copy of the file. So 5 files become 10, 10 becomes 15, etc..... |
After a few hours tinkering with this, I've managed to hack around this issue by using The gruntfile:
The above allows a workflow whereby you have your asset source files outside of the public folder for editing, and have them watched by grunt for changes. Upon change, they are concatenated, minified and published to a public folder for inclusion in view templates. The view templates have their references replaced by So to sum up the above will work as follows: Application structure:
This allows continuous development of asset files, ensuring the application has bang up to date changes with the files cached until they are changed again. Version control is also unaffected as the source files are can be in the repository and the public files ignored, created after a checkout followed by executing Great plugin @HollandBen , coupled with a few other grunt tasks this has turned out to be a great way of automating the caching process with no impact on source files and no manual renaming and moving files to do. |
@djjohnjosephuk I am running in to the exact catch 22 scenario. I can't believe this has not being sorted, it seems to me as if this package does not do what it is intended to do. I appreciate the hard work on the project, but I have spent hours trying to figure this out. Having to "hack/workaround" this issue is a big problem to me. Are we missing something? 1000's of people seem to download this plugin every week. So I can only assume I am at fault? |
@revalgovender @djjohnjosephuk this plugin's purpose is to hash files and change the references in the specified files. It does some extra minor things as requested by some users over time. Prior to version As you have probably read in a few issues, there was a change to follow an immutable approach as well, i.e. you can run the task 1000 times and you'll get the same output. This meant forcing users to figure out their own approach to "cleaning up" there workspace. I have given some advice in other issues about doing this but clearly it doesn't fit with some users build systems and methodologies.
Firstly, I haven't used
In terms of the functionality, it does do what is intended. Maybe some of the language in the readme should be changed to point out that it will not re-hash your already processed files - I'm open to suggestions and pull requests |
Thanks for your response @HollandBen . Again, appreciate the work on the plugin so we can use it for free. Unfortunately, it does not work as I need it to work. I guess I was confused by the description. It does add a hash to the file and it does update the reference. But, if you run it again, then you run into issues as described above. I just assumed I could do it over and over again. Maybe make that clear/clearer in the ReadMe? Have a good day! |
I've found the way for update the reference to the file that already was hashed. The code is the follows:
This resolves the issue #183. |
@krobing great work..i think this should be considered |
Since upgrading from 0.4.13 to 1.0.0, I'm finding that that busted files are being busted multiple times, so I end up with lots of the same file:
How do I stop this from happening?
Maybe I haven't quite got my
Gruntfile.js
setup correctly:Any help would be appreciated, and sorry if I'm missing something obvious to solve all these issues.
The text was updated successfully, but these errors were encountered: