Open dorxy opened 11 months ago
@weaverryan if this is the way to go I'll do the same for the twig bundle! 😄
I apologize for the late response, apparently GitHub either didn't notify me of all the conversations or my spam filter got them. I'll fix all the comments!
@bocharsky-bw I like the idea of downloading the latest version, we would however not be able to show the default config for it with bin/console debug:config SymfonycastsSassBundle
, and I'd be interested in your thoughts on automatically upgrading any version with for example a new deploy, the developer having no control over it.
In case there is no explicit version configured in the binary_version
entry, we could do something like:
sass:upgrade
command which downloads the latest available binary and updates the projects configIt would even be possible to explicitly enable the 'download the latest version I don't care if it breaks' by allowing a 'latest' string in the binary_version
entry, which always checks for a newer version whenever your building. We could take a minimum of 1 day checking fmtime
of the binary to not do version check requests for every time you build.
@dorxy OK, let's see the big picture here: I think we definitely want to get the latest version of Sass binary by default here. But we also want to be able to specify which version you want to use via a config file (it may be useful for legacy purposes, e.g. when the latest version causes problems and you want to rollback to a specific version). If the user specified a version in the config - we will use it. If not - we will use the latest available. To solve the problem with upgrading - we need to use the version in the path to the Sass binary file, e.g. /path/to/sass/binary/1.63.6/
- this will solve the problem with the upgrade. Whenever a new Sass release comes up - the bundle will automatically fetch it. I think this is what is almost done for the Tailwind bundle here: https://github.com/SymfonyCasts/tailwind-bundle/pull/38 - the path that contains the binary version will solve the problem with upgrading, i.e. you will not need a specific command for it, it will work behind the scene.
Yeah, debug:config
will not show the version, but that's fine I think, if you care about the specific version - just specify it in the config and the bundle will use it always. If you don't care - you should count on the latest version always.
Only Windows-related tests left... any ideas how to fix them?
the testlogfiles have expired, can someone retrigger the tests?
I merged the latest changes from main
and retriggered the build - as you can see test failures are relevant.
@dorxy do you have some time to finish it? It would love to merge it when tests pass
Hey @c33s , thank you a lot for such details here - pretty useful debugging!
Since @dorxy is probably busy and isn't active on it lately, do you want to fork this PR (basically base yours on top of https://github.com/dorxy/sass-bundle/tree/issue-3-binary-version ) and help to finish? Otherwise, I can take a look at it closer to the end of the week, I really would like to see this feature released.
I'm sorry for not getting back to you guys sooner, @c33s thanks a lot for trying to dive into the issue! I'd copy pasted from the previous solution before my implementation on downloading the executables, so I'm not sure why it's not passing the tests anymore. Perhaps we can compare it with the tailwind version to see how the downloads are happening there (and passing tests)?
@bocharsky-bw @dorxy just tell me if i can help. i am currently quite busy but as soon as my load lightens i can do a fork if @dorxy gets stuck. but i can do smaller tests/debuggings on windows if you need
Resolves #3