Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version number comparison & fix chained version renames #134

Merged
merged 14 commits into from
Sep 23, 2024

Conversation

angelikatyborska
Copy link
Contributor

@angelikatyborska angelikatyborska commented Jul 19, 2024

Resolves #123

TODO:

  • numerical comparisons for versions
  • fix chained version renames for Upgrade bitstyles to 6.0.0 #127
  • recheck documentation for potential updates
  • changelog entries

@angelikatyborska angelikatyborska force-pushed the feature/123-version-number-comparison branch from d05d272 to 5edc84c Compare July 24, 2024 07:49
Comment on lines 14 to 31
# TODO: delete
test "chained version" do
assert classname("u-version-5-0-0", {5, 0, 1}) == "u-version-5-0-0"
assert classname("u-version-5-0-0", {5, 0, 0}) == "u-version-5-0-0"
assert classname("u-version-5-0-0", {4, 9, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {4, 4, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {4, 3, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {4, 2, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {4, 1, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {4, 0, 0}) == "u-version-4"
assert classname("u-version-5-0-0", {3, 9, 9}) == "u-version-2"
assert classname("u-version-5-0-0", {3, 0, 0}) == "u-version-2"
assert classname("u-version-5-0-0", {2, 0, 0}) == "u-version-2"
assert classname("u-version-5-0-0", {1, 6, 0}) == "u-version-1-5"
assert classname("u-version-5-0-0", {1, 5, 0}) == "u-version-1-5"
assert classname("u-version-5-0-0", {1, 4, 0}) == "u-version-1-3"
assert classname("u-version-5-0-0", {1, 3, 0}) == "u-version-1-3"
end
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be deleted after the code review, together with the corresponding classes in bitstyles.ex. I added this test to change a check that the new chaining behavior works as expected.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a great idea to keep it. You could add the class mapping in as a compile time switch config
(add_version_test_classes), so they do not end up in the compiled versions for prod.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. let's say I do something like

# config.exs

if config_env() in [:test, :e2e] do
  config :bitstyles_phoenix, add_version_test_classes: true
end

I'm not even sure how to use it as a compile-time check in something like this:

defp downgrade_classname(class, target_version, current_version)
       when should_downgrade_from({4, 0, 0}, target_version, current_version) do
   mapping =
      case class do
        "u-overflow-y-auto" -> "u-overflow--y"
        # I can't sqeezee an if expression here
        "u-version-4" -> "u-version-2"
        _ -> class
      end
end

But I'm also thinking: if somebody adds bitstyles_phoenix to their project and compiles their project in test env (to run tests), then bitstyles_phoenix will include those 'test' classes in its source. Which means, if the user of the library is relying on class substitution in their app, and for some weird reason uses a class like u-version-4, then that class will get substituted in their app 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dependencies are always compiled in prod ENV except when you state it on the dependency directly.
https://hexdocs.pm/mix/Mix.Tasks.Deps.html#module-dependency-definition-options

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For compile time switches you can even have a if block around the whole function definition

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@angelikatyborska angelikatyborska force-pushed the feature/123-version-number-comparison branch from 7e6333a to b3ce605 Compare July 24, 2024 08:01
@angelikatyborska angelikatyborska marked this pull request as ready for review July 24, 2024 08:19
Copy link
Member

@andreasknoepfle andreasknoepfle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm 💚🚀 Nice work

@angelikatyborska angelikatyborska merged commit c101a50 into main Sep 23, 2024
3 checks passed
@angelikatyborska angelikatyborska deleted the feature/123-version-number-comparison branch September 23, 2024 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Version number comparison
2 participants