Use wellington?
drewwells opened this issue · comments
I see that you are calling out to a node-sass binary for Sass compiling. Any interest in using a Go wrapper to libsass instead Wellington? I can PR the needed changes to make make the switch.
@drewwells greetings, any update on this?
Off topic: Do you have any workflow devised that you used in the interim to build with wellington (with or without train)? I'd really like to try to eliminate the node (edit: fixed) dependency.
I'm not following your question. There's a couple workflows I use with wellington. Standard compass compile/watcher, it will build changes found recursively in a folder ie /sass. By specifying the output folder /build, it will place the resulting CSS in build preserving the path it found in /sass. Wellington also functions as a http/2 server, so you can start it once then post Sass and receive CSS. This acts a lot like sassmeister.com. Does that answer your question?
Correction, eliminate the node dependency, not the "code" dependency.
Regarding workflows, being new to golang and coming from django - which workflow is closest to how an asset pipeline in django/rails would work?
Any update in terms of the PR?
I'm not very familiar with rails asset pipeline. Wellington as a cli tool works much like compass which expects a tree like
sass/
im/
build/css
build/css/im
Since train is also written in Go, it wouldn't need to be installed separately. Train can include wellington and provide Sass support directly from the train tool. I'm looking for contributor input before I look at the best way to provide Sass support to train.
I'm looking for a workaround for Wellington on windows since they don't support windows. If Wellington will be used here then thus workaround won't work anymore
You could run train in a container to get windows support. I think they're also bundling ubuntu VMs with windows now