Documentation - setup project - add information about building sass files

[pavelee]

Right now there is no information about sass compilation step. It makes harder to less experience developer to start with project.

We should complete documentation about it.

[tolik518]

@pavelee
Thank you for addressing the issue - there's two options I see to that can solve the problem:

1. Get rid of sass, and just use plain (clean) css, as it adds unnecessary overhead

2. Add a Dockerfile to transpile the sass to css, so one doesn't need to install a sass transpiler locally. The command to call the sass transpiler should be documented in the Readme.md of course.

I'm more of a fan of the second approach to be honest, but I'll accept both ways :)

[pavelee]

Second option sounds much better, that would be great to keep sass.

Of course It has cost because we have to still remember to recompile after any change. It is possible to run extra container with sass in watch mode but it sounds pretty overhead (maybe not? 🫣)

I would recommend:

• Adding compile automation so you can run project without bothering about local sass dependency and add info about it in readme
• Add to readme information about sass and how to install it locally. Recommended way if someone want to run it in watch mode, so development is much better experience

What you think about it?

PS, I could do that 🙏

[tolik518]

I haven't encountered the sass issue until now since phpstorm has an embedded functionality that makes it untroublesome to work with it.

A container with sass in watch mode sounds good to me - as far as I can see it's just sass running in watch mode with the code in a mounted volume?

The alternative would be a container that has to be started every time a change to a sass file was made.

I think the local solution should be only optional and only the last resort - as it would lead to people using different versions of sass (which would have influence on the compiled file and features)

I think it's a question of preference at this point.
One way would require a container running in the background while developing - while the other solution would require the dev to run a command every time after a change.

I'll leave it up to you at this point and assign the ticket to you :)

[pavelee]

as far as I can see it's just sass running in watch mode with the code in a mounted volume?

Yes exactly, but it should be container working only on development environment, so it bring the next problem we should create separate docker-compose for development purpose (with this extra container). It shouldn't be present on production.

With local working and version we could just specify version of sass you using with package.json inside project or just mention version in docs
npm install ssas@here_version

I will prepare proposal to discuss

[tolik518]

Hey @pavelee, I ws wondering if you are still interested in the task?

[pavelee]

Hey, currently i have a lot on head 😅 so if you have anyone who would like to look into it, go ahead 🙂

[tolik518]

@pavelee oh no, don't worry
I was just wondering. Take your time - I didnt want to rush you :)

[pavelee]

Sure 👍, no problem

[pavelee]

I analyzed problem again. Still the best solution would be separate container (alpine based) woking with sass in watch mode and mounted css folder.

That should be only development purpose, but as I assume from code you don't host production using docker?

I am asking, because I am not sure it is necessary to create separate docker-compose.dev.yml file to overwrite with extra sass container. If you don't use it on production and don't mind it, I would skip creating extra file and more complex into project.

[tolik518]

Yeah I think your proposal would be best practice.

In the future the blog will be hosted using docker (with the help of portainer) but for now it's not needed since the infrastructure isn't there yet.

So I don't think there's a necessity to have separate docker compose files just yet - I could adjust it myself when I start migrating all my services.

Edit: making separate docker files would be a ticket on its own :)

[pavelee]

I prepared proposal of solution -> #12