bin/jekyll has grown to the point where it would be easier to maintain in small chunks, rather than as one big script with many different pieces all jammed together.
These changes accomplish three things:
This is an alternative plan to @tombell's "The Big Jekyll Command Cleanup" (#690).
I've always preferred working with sub-commands in this way: each sub-command script has only one piece of the responsibility of making Jekyll go, and only deals with one thing.
This will make adding on generators (e.g., jekyll generate post lalala) less painful.
jekyll generate post lalala
Moved import code to jekyll-import sub-command script
Move OptionsParser options for import to jekyll-import
Using system instead of require, which looks for a .rb file
Beginnings of jekyll-init
Create default directory structure with --init.
Addresses issues #451 and #194.
Signed-off-by: Parker Moore <firstname.lastname@example.org>
Using empty_dir so as not to mess with source_dir scaffold
Site#create_default_directories -> Jekyll.init
Documentation in jekyll-init and final newline
Ignoring test/empty directory
Extension upon #461.
Removing debugging ARGV puts statement
Why not use "jekyll new" instead of "jekyll init"? I think the "new" keyword is widely used by other generators and probably easier to grasp if you don't come from a programming background. Rails uses "new" for what it's worth.
I'd consider using jekyll new for sure.
jekyll new seems much better. 👍
So it creates them! Right? ;)
(This is an old commit, just so you know).
What advantages does this have over my proposed changes to the jekyll command?
Moved jekyll-init to jekyll-new
Writing configuration settings to _config.yml
I think this is a bit easier to extend, because you just have to write a new file (bin/jekyll-whatever) in order to use whatever new command you want to use.
It also doesn't require Yet Another Gem Dependency, which I like.
I'd prefer 1 gem over unreadable option parsing.
puts "Please install the jekyll-migrator gem."