These are chat archives for jescalan/roots

23rd
Jun 2016
loganweilenman
@loganweilenman_twitter
Jun 23 2016 00:50 UTC

needed to install coffee-script in the directory up, and require coffee-script/register

var Roots = require('roots'),
    coffeeScript = require('coffee-script/register'),
    project = new Roots('example-project');

Thanks for the help

Jeff Escalante
@jescalan
Jun 23 2016 01:44 UTC
:+1:
Tom Kraak
@tkraak
Jun 23 2016 14:23 UTC

@Hoenoe … here is how to use roots with sass and autoprefixer

https://github.com/tkraak/roots-sass

still lacking proper docs, but I tried to keep the commit history as clean as possible for people to follow along with how I arrived at this
much thanks and credit to @Leeds-eBooks for helping me along and pointing me in the right directions :)
Tom Kraak
@tkraak
Jun 23 2016 14:34 UTC
next up is to turn this into a proper roots template
Timothy Johnson
@RedHatter
Jun 23 2016 19:03 UTC
In the File Sorting hook is there any way to determine what other categories the file has already matched?
Jeff Escalante
@jescalan
Jun 23 2016 19:03 UTC
sorry im not entirely sure what youre referring to
Timothy Johnson
@RedHatter
Jun 23 2016 19:08 UTC
Basically in the code below how can I know what categories 'file' has already been sorted into by other extensions?
 fs: ->
   detect: (file) ->
    console.log
nesth
@nesth
Jun 23 2016 19:09 UTC
hello, I seem to be having issues installing roots on ubuntu.
Error: EACCES: permission denied, mkdir '/root/.config/roots'
even after chnod 0777 /root/.config
Jeff Escalante
@jescalan
Jun 23 2016 19:10 UTC
Oh @RedHatter no i dont think so. let me check
Timothy Johnson
@RedHatter
Jun 23 2016 19:11 UTC
@nesth npm scripts are run by nobody by default. Use sudo npm --unsafe-perm true install roots -g to run as root.
nesth
@nesth
Jun 23 2016 19:12 UTC
thank you! I worked like a charm
Timothy Johnson
@RedHatter
Jun 23 2016 19:14 UTC
@jescalan What I'm actually trying to do is get the final output path for the file. I can use @roots.config.out(file, 'html') but I would need to know what the final extension will be. I was thinking I could determine that from the previous categories. Is there another way?
Jeff Escalante
@jescalan
Jun 23 2016 19:17 UTC
ok so @RedHatter the extensions run their detect functions in order, so the last extension in the array will have access to other extensions' categorized files
unless they have set the extract option, in which case the file is not available to subsequent extensions
where are you trying to get the output path from?
like in an extension?
Timothy Johnson
@RedHatter
Jun 23 2016 19:26 UTC

@jescalan Yeah I currently have this

module.exports = (opts = {}) ->
  class PathSorter
    constructor: (@roots) ->
      @category = 'byPath'

    fs: ->
      ordered: true
      detect: (f) =>
        console.log @roots.config.out(f, 'html')

But this obviously breaks if the final extension isn't html.

Jeff Escalante
@jescalan
Jun 23 2016 19:29 UTC
ok, so whats the overall problem you're trying to solve here with the extension?
Timothy Johnson
@RedHatter
Jun 23 2016 19:31 UTC
I'm hacking on the DynamicContent extension so it reads the front matter before compilation allowing dynamic pages access to the full list of data.

Currently if you do something like

each page in site.views
    a(href=page._url)= page.title

in a dynamic page it will only show links for already compile files instead of all dynamic pages.

I thought I could read the front data in the detect function. It works well, but I have no way to define the _url property.
Jeff Escalante
@jescalan
Jun 23 2016 19:42 UTC
i think dynamic content is just for files targeting html
i havent heard of anyone using it for css or js
so you should be safe to assume html
Timothy Johnson
@RedHatter
Jun 23 2016 19:43 UTC
It mostly will be just html but I have used it for css before (dynamicly generating animations and such).
Jeff Escalante
@jescalan
Jun 23 2016 19:45 UTC
oh wow for real
might be the first time
hmm let me look into this
Timothy Johnson
@RedHatter
Jun 23 2016 19:47 UTC
Ok. Thank you.
Timothy Johnson
@RedHatter
Jun 23 2016 19:53 UTC
One more question: Is there a way to get roots to output 'pretty' urls? So /views/page.jade would compile to /page/index.html allowing it to be accessed like example.com/page/?
Jeff Escalante
@jescalan
Jun 23 2016 19:53 UTC
yeah, the clean urls option should do it
Timothy Johnson
@RedHatter
Jun 23 2016 19:54 UTC
Ah, thank you. Somehow I missed that.
Jeff Escalante
@jescalan
Jun 23 2016 19:58 UTC
so for the detect thing, i think that's going to be pretty messy
the fs hooks run before the compiler has even begun
roots can be used with pretty much any language so extension detection wont help
bc you need to know the output
i cant think of a way off the top to make that detection work reliably
Timothy Johnson
@RedHatter
Jun 23 2016 19:59 UTC
What about using a hook that runs right before the category is compiled?
Or right at the start of compilation? Once all files have been sorted and such.
Jeff Escalante
@jescalan
Jun 23 2016 20:01 UTC
only one that might fit that is the before_category hook
could try that one
you'll get back the compile context there
Timothy Johnson
@RedHatter
Jun 23 2016 20:06 UTC
I don't see any reference to a before_category hook. I assume I would use it like so?
module.exports = ->
  class FooBar

    category_hooks: ->
      before: (ctx, category) ->
        console.log "do stuff"
Jeff Escalante
@jescalan
Jun 23 2016 20:06 UTC
yeah
Timothy Johnson
@RedHatter
Jun 23 2016 20:08 UTC
Thank you, I think I can get that working. (Might want to mention in the docs that you can use before as well as after)
Jeff Escalante
@jescalan
Jun 23 2016 20:12 UTC
good call!
thanks @RedHatter
Timothy Johnson
@RedHatter
Jun 23 2016 20:23 UTC
@jescalan Sorry to bother you again, but I can't seem to get the before hook to work. The following code logs after but not before.
module.exports = (opts = {}) ->

  class DynamicContent
    constructor: ->
      @category = 'dynamic'
      @all_content = []

    fs: ->
      extract: true
      ordered: true
      detect: (f) -> helpers.detect_file(f.path)

    category_hooks: ->
      after: after_category.bind(@)
      before: before_category.bind(@)

    before_category = (ctx) ->
      console.log 'before'

    after_category = (ctx) ->
      console.log 'after'
Jeff Escalante
@jescalan
Jun 23 2016 20:49 UTC
ah shit there is no before
hahaha
oops
Timothy Johnson
@RedHatter
Jun 23 2016 20:51 UTC
Haha, well I guess I'll just assume html for now...
Jeff Escalante
@jescalan
Jun 23 2016 20:52 UTC
ah im sorry!
we'll probably be able to provide a better solution for you with spike
Timothy Johnson
@RedHatter
Jun 23 2016 21:14 UTC
I hadn't heard about spike. I did some googling and read this, sounds interesting. But one small clarification: spike will not support styles and coffeescript? Roots out of the box for stylus and coffee is the main reason I switch from Jekyll. I'm still interested to see where spike goes, but if development is moving from roots to spike maybe for the time being I should go back to Jekyll.
Tom Kraak
@tkraak
Jun 23 2016 21:26 UTC
@RedHatter as far as I understand it, spike will use plugins for everything
so nothing prevents you from pluging in stylus, coffeescript or whatever else you can think of
oh, and I recently jumped ship from Jekyll as well :)
Jeff Escalante
@jescalan
Jun 23 2016 22:03 UTC
yeah you can use anything, but out of the box we will provide superior options to stylus and coffee
roots will continue to be supported but not actively developed with new features
spike's defaults are sugarss/cssnext for css, you still get whitespace significant parsing, and spec-compliant future css
and es6 for javascript, which is better than coffeescript
however you can plug in what you want
Timothy Johnson
@RedHatter
Jun 23 2016 22:12 UTC
es6 is not 'better' than coffeescript they are different things and not directly comparable. es6 is the next version of javascript, coffeescript compiles to javascript. You can have coffeescript compile to es6 javascipt. Coffeescript adds syntaxual sugar to javascript (indent to define blocks, simpler function declarations etc.) while es6 add actual new features to javascript (and by extension coffeescript).
Jeff Escalante
@jescalan
Jun 23 2016 22:13 UTC
yup i know
but es6 is better
haha
it has almost all of the sugar that coffeescript has, while being more widely accepted by the community
and eventually will not need to be compiled at all
i use uncompiled es6 for node libraries, its fully supported in the current stable version of node
dont get me wrong i used coffee very extensively
the entirety of roots and its ecosystem is written in coffee
but the accessibility cost is too high. developers have to "learn" coffeescript, and it will always have to be compiled
es6 is just the default
coffeescript has done its part. it had an enormous influence on es6, for the better
but it's now a relic
Timothy Johnson
@RedHatter
Jun 23 2016 22:19 UTC
Ok, that's cool, I understand. I just get a little irritated with all this 'coffeescript out es6 in!' talk that's been around the web. And yeah es6 does solve a lot of the problems... but it still has brackets instead of indentation. For me the main draw of coffeescript is just how more clean it is. Once you remove the brackets semicolons and function () {} code becomes so much more readable.
Jeff Escalante
@jescalan
Jun 23 2016 22:19 UTC
arrow functions help a lot with that
dont get me wrong, i still think that coffeescript syntax is cleaner
Timothy Johnson
@RedHatter
Jun 23 2016 22:19 UTC
True
Jeff Escalante
@jescalan
Jun 23 2016 22:19 UTC
but at this point the difference is small enough between the two that the accessibility cost of coffee isn't worth it
check out the spike source if you want, it was the first major project i wrote with es6
it's very readable
and i don't need any compile tasks at all, which feels so good
give it a shot, and you'll end up a convert
Timothy Johnson
@RedHatter
Jun 23 2016 22:22 UTC
Almost all of my javascript is for browser use which means that I would have to run the es6 through babel. Once es6 has enough browser support and I can use it in production I'll give it another look.
Jeff Escalante
@jescalan
Jun 23 2016 22:29 UTC
its worth getting on the train now just for the accessibility
development is working with other devs
telling someone else they have to learn coffee to work on your projects is limiting
telling them they have to learn es6 is a no brainer, everyone has to learn es6
its not going to be that long either before es6 has browser support
all major browsers are on evergreen versioning
support dropped by microsoft for all versions of IE except for 11
once support drops for ie11, we're going to be on the fast train to the modern web
Timothy Johnson
@RedHatter
Jun 23 2016 22:36 UTC
Fair point. And switching to es6 is definitely the correct decision for some developers, but in my case I rarely if ever work with other developers (at least on projects with javascript) and I don't see enough of a reason to switch. As for as browser support goes just because microsoft stops supporting doesn't mean I can. I have some sites that get 60% of there traffic through ie8.
In addition to that once all browser support es6 there will still be babel for es7 etc. this article sums up by view point nicely.
But I do see the benefit of removing coffeescript support for spike. And switching to es6 in general.
Jeff Escalante
@jescalan
Jun 23 2016 22:40 UTC
eh, not necessarily. es6 includes all the features we had with coffeescript, and that was ok for developers for quite a long time. nobody is designing languages that compile to es6
i see it as being a "if you want to use X advanced features you can compile for es7, or just wait" kind of game
and if you are a solo developer that never intends to work with anyone else, and develops for heavy IE usage, I can see justifying using coffeescript
but i also dont see it as a benefit at all
as soon as anyone else ever needs to look at or work on your code at any point, you will pay the accessibility cost
i mean, you can look at the HN comments, they all echo the same thing: https://news.ycombinator.com/item?id=9082335
its just the way to go
technologies come and go
and coffeescript has done its part for the js community, and it was a huge part for sure, now it's on the way out
:sparkling_heart:
this comes from a big fan of coffeescript, who used it extensively, so im not trying to hate by any means
Jeff Escalante
@jescalan
Jun 23 2016 22:45 UTC
its just a practical argument, and eventually it got to the point where i couldn't deny the practicality of it, and I do frequently work with other developers, so that was that