Remove uglify from JS-Dev task and Redesign Enhancements

Would be great if we could add a JSHint task and a task to compile a vendor bundle into a separate JS file. Also, I don't see why you would want to uglify the javascript in your dev tasks. And is there a reason why you write the css files to the src directory and not dist?

Sorry, I should have just asked a bunch of questions instead of raising a ticket :-)

gulp.task('scripts-vendor', function() {
    return gulp.src(['app/scripts/vendor/**/*.js'])
        .pipe(plumber())
        .pipe(concat('vendor.js'))
        .on('error', gutil.log)
        .pipe(gulp.dest('app/scripts'))
        .pipe(browserSync.reload({stream: true}));
});

gulp.task('scripts-vendor-deploy', function() {
    return gulp.src(['app/scripts/vendor/**/*.js'])
        .pipe(plumber())
        .pipe(concat('vendor.min.js'))
        .pipe(uglify())
        .pipe(gulp.dest('dist/scripts'));
});

Happy to answer any questions you have :)

JSHint

I'm cool with a JSHint task. My concern would be, I'd have to provide a JSHint config out of the box, but my team's preferences could be a lot different than someone else. What would be a good way to handle that, especially if someone wasn't used to using things like JS/ESHint? And would it need to support ESHint as well?

Vendor script

I'm on the fence about creating a separate bundle for just the vendors. It's my personal preference to have everything bundled together but that's just me :) Could always have a config that allows you to say "Create full bundle" or "Create app bundle and vendor bundle" so it'd be able to do either one.

Uglify JS in Dev

That's a good point, it really shouldn't be uglifying the JS during DEV mode. That was probably a small oversight on my part. I can remove that.

SCSS -> src directory

I just preferred to have everything encapsulated inside of the app folder whenever I'm actively working on front-end work. And I like to have the dist folder to be whatever I specifically want to use when I'm done working on things that would be integrated into the application (Rails/Node/etc). I usually just customize the deployment to copy the final versions into the right application folders (e.g. asset pipeline). And during the deployment, I'm tearing down the entire dist directory and its contents and re-building it to make sure everything is up to date and if anything got deleted that they're not lingering. Pushing things around to dist during active development might have a little conflict on that. But if someone has a compelling reason to adjust the architecture, I'm all ears :) I'm always open to hearing how I can improve things.

I appreciate the feedback and thoughts!

JSHint

I wouldn't be too worried about the rules. If you just provide a .jshintrc file with a fairly strict default configuration it should be easy enough to customise. But fair point on ESLint etc. Not sure if JSHint is the de facto standard for code linting and you probably want to avoid a boilerplate project to be too opinionated. That said, all devs I know use JSHint and 99% of frontend devs would probably want to use some form of code linting, whether thats JSHint, JSLint, ESLint or something more esoteric :)

Vendor script

Fair point and I guess it all depends on the scale of the project and the amount of third party libs you use. It should however make a difference in concatenation and minification time at some point...

SCSS -> src directory

Not sure if we are talking about the same thing. I would prefer not having any .css files in the styles folder but only .scss files:

/app/scss/
  /config
  /layout
  ...
 _main.scss
 _ie9.scss
 _ie8.scss

and the styles task would then generate main.css, ie9.css and ie8.css inside the dist/styles folder.

Other

It would also be nice to outsource the paths in the gulp file to either a separate config file or constants for easy configuration.
You could also set up a tests folder and task. But then again, which framework do you use.
There are also some unused variables which you initialise on top of the file: app, base, directory, hostname, path, refresh, del and tmp argument of the images task.
I think you can get rid of the scaffold task as gulp.dest() creates your folders automatically if they don't exist, no?
replace clean shell task with del to provide more flexibility with different configurations (https://github.com/gulpjs/gulp/blob/master/docs/recipes/delete-files-folder.md)
follow standard and use colon separator for different targets, e.g. styles:deploy and make it easier to distinguish between dev and deploy targets by adding :dev to the default target.
remove README reference from images task and replace the README file in the images folder with .gitkeep
as your app grows and you add more tasks it might be better to split up the tasks into individual files, stick them in a separate folder and load them via require-dir in your gulp file.
rename html task to copy because that's what it is doing :-)

It's quite tricky to satisfy everybody's needs and I've looked into a few other gulp boilerplate projects on Github. Most of them had few things I liked and some things I disliked. Yours comes pretty close to my personal preferences.

Perhaps this could be a Yeoman generator project whereby you can choose your linting library, vendor bundle (yes/no) and testing framework :)

JSHint

Thinking about it, adding a sample config for both JSHint and ESLint should be easy enough. I can just grab a default one from both and supply it in the root of the project. That'll work for in-editor detection, but adding running tasks is another thing. That bleeds into something else below (other section).

App vs Dist

I understand what you're saying, and I see the value of it. But it's just my personal preference to keep things that I'm actively changing into the app folder. I try to keep dist reserved for things that are built, compressed and generated for production environment. I need to go back and remove the uglify feature on the JS, which shouldn't be in that task. But at least the code is easy to update if you would prefer to move your generated CSS into dist by modding the HTML and the gulpfile in a couple spots.

Other

Thanks for all of the feedback :) I appreciate it. It touches on a lot of things I've been thinking about for some time now actually. I've been meaning to go back and create a yeoman/slush generator out of this so you could decide if you want SCSS/LESS/Stylus, ESLint/JSHint, Testing, ES2015/Browserify/Webpack and so on and so on. And I'd want to redo it all in ES2015, modular libraries, and clean up things here and there.

I like a lot of what you've posted. I'm hoping to get back to working on the next big release of this soon, but as of now I don't really have a timeline for when I can finish rewriting things. I might toss up what I'm working on up on Taiga (public Kanban / Scrum) so the progress can at least be transparent.

I removed the uglify() from JS for the in-dev task: https://github.com/ryanbenson/Harvest/commit/618cb0e68a72be425f7e64eae958df701803abd3

Just to give you an update on the rest, I have been researching the generator system and I'm on a good and interesting path. And I have outlined other things I'm working through: https://tree.taiga.io/project/ryanbenson-harvest-20/kanban

I'll rename the issue since this is working through a new redesign of the system :)

digitalthrive / Harvest