Optionally use sassc

[perlpunk]

Summary

This PR will use sassc if MOJO_PLUGIN_ASSETPACK_SASSC is set.

Motivation

ruby's sass is officially abandoned, and it has problems with some css files, for example the latest bootstrap css, so it would be good to have the option to use sassc. Or even other sass implementations.

References

• Run sass with --trace os-autoinst/os-autoinst-distri-openQA#180
• Call sass with --trace #150

[kraih]

Rebase on main.

[perlpunk]

Rebased.
This PR actually includes the --trace from #150 . So I can rebase again when that is merged

[kraih]

Without tests i don't think this has much of a chance i'm afraid.

[nicomen]

I'm not sure if using a very specific envv-ar with just a boolean value bolted on the existing Sass module is ideal. I'm guessing sassc also needs a different install approach than using ruby gems?

Would it make sense to add Mojolicious::Plugin::AssetPack::Pipe::SassC or ::RubySassC module instead (subclassing should be possible)? Adding tests for a separate pipe might be more straight-forward too.

Another approach would be to be able to set the whole cmd to call with an envvar eg: MOJO_PLUGIN_ASSETPACK_SASS_CMD="sassc -s --strace", but the _install_sass method would still be wrong.

The --strace part could probably be added independently just depending on whether the general DEBUG flag is set.

[perlpunk]

I'm not sure if using a very specific envv-ar with just a boolean value bolted on the existing Sass module is ideal. I'm guessing sassc also needs a different install approach than using ruby gems?

We're installing rubygem-sass as an openSUSE package anyway, so I don't know when _install_sass would actally be called.

Would it make sense to add Mojolicious::Plugin::AssetPack::Pipe::SassC or ::RubySassC module instead (subclassing should be possible)? Adding tests for a separate pipe might be more straight-forward too.

Another approach would be to be able to set the whole cmd to call with an envvar eg: MOJO_PLUGIN_ASSETPACK_SASS_CMD="sassc -s --strace", but the _install_sass method would still be wrong.

Yeah, since there's also the recommendation to use dart-sass the command line might be different for that as well. So an approach to support various implementations would be good.
But the command must still put together the parameters like include_paths correctly. That would work if every sass implementation uses -I.

The --strace part could probably be added independently just depending on whether the general DEBUG flag is set.

IMHO adding --trace always won't hurt, as it only really outputs something when there is an error. Without it the error message is pretty useless.
But that can maybe be discussed in #150

[Martchus]

Making the whole command overrideable sounds simple enough.