search

dkebler / 4S

Super-Static-Site-Starter- 4S - (getting closer to..) Complete static site builder development environment, any html templates/generator (hugo), any styling code (sass), Bower for asset libraries, js based workflow library, S3 and gh-pages for deployment...and more
MIT License
12 stars 2 forks source link

Consider converting to a Yeoman generator #1

Open adrinux opened 8 years ago

adrinux commented 8 years ago

I noticed one of your todos "Organize the repo so it can be installed as a submodule (tasks and library) so latest improvements can be updated in an existing content only repo." and wondered if you'd considered eventually making a Yeoman generator for your project.

This allows you to do 'yo super-static-site-starter' and then commit the resulting code and your content to the same repo, rather than messing with subodules. You can also include some logic to allow choice at generation time over which vendor additions or features to include. Take a look at https://github.com/yeoman/generator-gulp-webapp to get an idea of whats possible.

You probably don't want to do this until you gave working features in this project however, it adds an extra step to testing and slows down progress.

(Uncannily it seems I started my own static site starter with hugo and gulp on the day you committed this, no where near as far on as yours though https://github.com/adrinux/web-starter-hugo

Much as I'd love to merge efforts you seem to love splitting up files as much as I hate it – I much prefer to have monolithic files until they get unwieldy :)

dkebler commented 8 years ago

A yeoman generator version is definitely a possibility for the reasons you state but as you say best after this project is further along.

Having starter be a submodule of library and tasks submodule is mostly about the idea that content writers can be kept away from the "code". You start a repo for the content then you add the submodule that renders everything. I've probably not thought all this completely through but clearly from experience working with non-coders who need to edit content there is a separation required.

Utilities like this https://packagecontrol.io/packages/Dependents take some of the pain away from having code in multiple files. At least for me personally it's easier to keep track of things this way. Mostly I have taken approach from the one thing "module" design of nodejs and also from this fellow who I consider be the "god" of sass http://sass-guidelin.es/#the-7-1-pattern. So I'm sticking to it.

Being in pieces/files like this maybe down the line you can grab what you want easily.

Thx for your input!

adrinux commented 8 years ago

'content writers can be kept away from the "code"' – that's much more understandable. I'll take a closer look at Dependents, thanks.