Sass fragmented into multiple versions. The older Ruby one was what Cryogen was originally built with, but I believe the interface is the same, so the simplest way to install is probably npm install -g sass
I will have a look, I do install it for my Netlify build too
Or we can configure cryogen not to look for it if it doesn't use sass
I've enjoyed reading https://circleci.com/blog/meet-the-interns-carmen-la/ :-) Thank you, Carmen, for sticking with Cryogen for so long!
Why would we need that when there is no sass stylesheet?
There might be something in the config that triggers sass
According to https://github.com/cryogen-project/cryogen-core/blob/master/src/cryogen_core/sass.clj#L42 it shouldn't require sass? Or is it true for some reason?
This is the cause (update-in [:sass-src] (fnil identity ["css"]))
Fix coming soon
Here you go https://github.com/cryogen-project/cryogen-docs/pull/34
Awesome, thanks a lot!
Regarding sass, I did opened an issue https://github.com/cryogen-project/cryogen/issues/214
yes, but someone pointed out that libsass and consequently jsass and similar wrappers are being deprcated en-mass. jsass itself is in maintenance mode for that reason. They are working on something like libsass-protocol but doesn't seem to go anywhere for now. I think the best way to solve this for now is to improve the docs and recommend people install a compatible sass compiler.
Thanks for digging in to it. Then let's do that!
sure
PR applied.
Thanks!
I'm working to make Live Reload work properly https://github.com/cryogen-project/cryogen/issues/118 and some feedback is welcomed.
Right now it fails quite often with Page Not Found
I believe this is caused because Cryogen does a lot of writes to disk:
• whypes out the files
• compiles and writes all files regardless if they changed or not ?!
I believe this makes Live-Reload start when the files are deleted and it finishes when there is still no page rendered.
This could be solved if Cryogen emitted events when it processes data and it finishes things.
This way we could hook into those events and take action.
Do you think it is a good addition for Cryogen?
It could emit some events at start / end of each compilation phase.
It could also emmit events when compiling content files.
Something like:
{:src { :path "/content/asc/my-blog-post.asc" :hash "md5-abcd"}
:dest {:path "public/posts/my-blog-post/index.html" :hash "md5-bcda" } }
Hi, I think it will. I saw your PR a while back and I thought it was a great idea. it is a step in the same direction for sure. I do think it will help, even if only by side effects (faster compilation time).
Is there a way to append changes to the change/set compilation pipeline? For example your code does not work for next/previous. Would it help if we add the previous/next files to the compilation queue as the compilation happens?
Not built in. We would need to make a more complicated (and maintainenance-expensive) change to enable that and personally I do not think it's worth that because who cares about those links during development? Why?
I was just curios if there is enough need for something like that. I'm not familiar with the code to know how hard it would be to implement. I think the event part would be nice.
I just want to take a moment to say thank you to everyone that has been contributing to cryogen lately. I haven't really had the energy to work on cryogen, so I really appreciate you all coming together to review and merge PRs! ❤️
There was still the issue with the path in store_artifacts
. I fixed that (directly on master, not via a PR) and the CircleCI job now completes without any errors. Thanks for all the help. If it is all okay, I will bump up the version and tag it in the next few days.
And, thank you for starting the project!
here here 🍻
Would it help to use it together with https://github.com/cryogen-project/cryogen-core/pull/149?
That sounds as a great idea!
@carmen I'd be happy if you made me a contributor, if it is OK for you. And if we are multiple contributors, perhaps it would be helpful to write down a few guidelines, such as the general project philosophy (e.g. KISS to keep maintenance cost down, to keep a balance between user needs and stability and developer time) and "best practices" regarding testing before merging a PR, versioning and releases... . What do people think?
@holyjak that is a great idea, and I'd love to make you a contributor!