Skip to content
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

Multiple busting tasks overwrites busters.json? #20

Open
Dylan190774 opened this issue May 10, 2016 · 7 comments
Open

Multiple busting tasks overwrites busters.json? #20

Dylan190774 opened this issue May 10, 2016 · 7 comments

Comments

@Dylan190774
Copy link

Dylan190774 commented May 10, 2016

I created seperate busting tasks in gulpfor javascript files and for css files, to keep things fast (only build the files that have changed).

When I do just gulp everything works fine: both the css and js files are inbusters.json.
But when a busting task is called seperately, for example by a watch, then the old busters.json that contained all files is overwritten and only contains the files that were in that specific task.

Any way to avoid this?

@UltCombo
Copy link
Owner

Can you show the code of your gulp task(s) that cause the issue?

As long as you have the same output name (busters.json) and run the tasks in the same process, the hashes should be joined together in the same file. The point is to pass all files through gulp-buster at least once in the process, so their hashes stay up-to-date and overwrite outdated busters.json.

@Dylan190774
Copy link
Author

Dylan190774 commented May 11, 2016

My gulpfile looks something like this :

gulp.task('bust_css', ['css_build'],  function() {

  return gulp.src([
                    'public/css/**/*.css'
                 ])
             .pipe(bust('busters.json'))
             .pipe(gulp.dest('public'));

});


gulp.task('bust_js', ['js_build'],  function() {

  return gulp.src([
                    'public/js/**/*.js'                   
                 ])
             .pipe(bust('busters.json'))
             .pipe(gulp.dest('public'));
});

gulp.watch('resources/css/**/*.css', ['css_build','bust_css']);
gulp.watch('resources/js/**/*.js', ['js_build','bust_js']);

The idea is that each watcher only watches certain files (css or js) and then calls its build task and the bust task afterwards. But when gulp watch is active, only one of the two tasks is called, so busters.json gets overwritten.
I solved it for now, by using different filenames for css and js, but ideally I would prefer just one manifest file.

The reason I'm not using one big bust task for everything, is because of the dependencies for each bust task, which make sure that the build tasks are done before the busting. And building everything again when only one file changes slows the building down, of course.

@UltCombo
Copy link
Owner

Oh, I see. In fact, I've considered adding this feature in the past, but there were quite a few issues as mentioned in the README:

A feature to allow inputting an already-generated hashes file was considered in order to avoid having to pipe all the to-be-busted files at startup, but that seems to bring more cons than pros -- the auto-cleanup of deleted files' hashes would no longer happen, outdated hashes could stay in the output hashes file if the to-be-busted files were edited while gulp was not running, and finally it'd also be incompatible with the transform and formatter features.

But I believe such a feature could still be useful in some cases. Perhaps we can add an option to pass in an initial hashes object, but the user would have to be mindful of the quirks above.

@hpawe01
Copy link

hpawe01 commented Nov 8, 2016

Hello @UltCombo

what is the current status on this? I found your package and liked it but ran into the same issue as @Dylan190774 .

Regarding your cons:

  • Normally you don't change your productive asset structure that often. For example if you started with styles.css and scripts.js, you will propably stay with those filenames. And even if you change the scripts.js to local.js and vendor.js later on, it is unlikely that you run into any issues. Because you will adjust the name in your views as well, so there should be no reference anymore to this outdated hash. So although it is unclean to have an invalid reference in your json-file, it won't be a big problem.
  • Normally you don't change your productive asset files manually, because most of the times they are a concatenation of different source files and often even minified/uglyfied. And this is done by gulp.

It is perfectly fine to mention those cons in the README, because the users have to be aware of those pitfalls. But I think those pitfalls are not so bad that the feature @Dylan190774 asked for shouldn't be implemented.

Thanks in advance for any infos or thoughts on this.
Cheers

@UltCombo
Copy link
Owner

UltCombo commented Nov 8, 2016

Yep, I've been considering to add an option such as initialHashes so that you can do:

bust({
  initialHashes: require('busters.json')
})

This option's documentation should have an warning about the pitfalls, I believe that should be enough.

I haven't had much free time lately though, PRs are welcome to speed up the implementation.

@hpawe01
Copy link

hpawe01 commented Nov 28, 2016

Thank you for your reply! Unfortunately I have no experience with PRs or any open source development.

Besides I pursue another build strategy now, so that I need to rev my assets only when preparing my app for production. So I still have different gulp watchers in my development mode, but I don't need to provide each time an existing buster.json as I don't rev the watched files in development mode anymore.

Cheers

@akmjenkins
Copy link

@Dylan190774 - Bust all your static assets at the same time:

gulp.task('bust-all',['js_build','css_build'],function() {
    return gulp.src(['public/js/**/*.js','public/js/**/*.css']).pipe(bust('busters.json'))  
})

gulp.watch([
    'resources/css/**/*.css',
    'resources/css/**/*.js'
],['bust-all']);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants