Decouple CoffeeScript and Sass gems.

[parkr]

Strong coupling requires a huge investment by users in terms of
troubleshooting and other packages (e.g. NodeJS or therubyracer)
Running gem install <blah> isn't a significant cost, especially
given that the user ran 'gem install jekyll' just fine. If this
process is automated, adding in these gems and their dependencies
is easy and can be automated too.

To install either of these gems, run gem install <gem_name>
or add them to your site's Gemfile (if exists) by adding
gem <gem_name> to your site's Gemfile, then run bundle install.
They will be automatically required – no work beyond that!

Jekyll shall not be bloatware.

• Decouple
• Write installation instructions in docs

Fixes #2335.

[mattr-]

Why don't we just change the gemspec in jekyll-coffeescript to require a javascript runtime (i.e. therubyracer) for platforms that require it. I think Linux is the only one that does...

[parkr]

Why don't we just change the gemspec in jekyll-coffeescript to require a javascript runtime (i.e. therubyracer) for platforms that require it. I think Linux is the only one that does...

Because it's adding bloat. If I have NodeJS installed, I don't want to spend the time installing yet another gem I don't need or want. It's really about bloat. I'd rather decouple in the manner proposed because it introduces a very, very light lift for those that want to use Sass & CoffeeScript, and removes the bloat for those who don't. 😃

[mchelen]

Installing therubyracer gem also requires the g++ compiler which users may not otherwise have installed.

[parkr]

This seems like a pretty severe breaking change from 2.0 to 2.1 if you haven't installed the gems before installing Jekyll 2.1. Is this acceptable for a MINOR bump? Is good documentation & a clear release post enough? /cc @envygeeks

[envygeeks]

The question is, do you provide this documentation on the Jekyll page, on the Jekyll-(Sass/Coffeescript) page or both? Clear and concise is great but the hardest part is deciding where to place all this information because placing it on the wrong spot is just as bad as not documenting it sometimes.

That said, I think this is an occasion where I would probably deprecate the feature in a minor bump and then remove it in a major bump, add a warning (with a switch to disable it of course) letting them know that the gems will be decoupled come Jekyll v2.* and that they should ensure that they have them added to their Gemfile if they use them and wish them to remain on by default.

[mchelen]

The question is, do you provide this documentation on the Jekyll page, on the Jekyll-(Sass/Coffeescript) page or both? Clear and concise is great but the hardest part is deciding where to place all this information because placing it on the wrong spot is just as bad as not documenting it sometimes.

The current Jekyll guide will result in a non-functional Jekyll installation, so it seems like the extra step would need to be mentioned there.

[parkr]

This will happen automatically in Jekyll 3, you think?

[envygeeks]

It depends on how we handle assets but more than likely I think it will because of the nature of the way Jekyll 3 works. It would just be natural to follow Jekyll's flow in the asset plugin.