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

chore: add type signatures and type checker for CI #58

Closed
wants to merge 4 commits into from

Conversation

mschoenlaub
Copy link
Contributor

This PR

  • adds type checking to the CI

Related Issues

Fixes #53

Notes

Some of the types around contexts are probably a bit off. Then again, parts of the spec aren't actually implemented anyways. It seems to be a chicken-egg problem.

Follow-up Tasks

Decide which route to go for the context types (Hash vs class). The latter oen ahs better typing support, Hashes with optional keys are a bit weird.

How to test

This comes with a new job in the CI.

Signed-off-by: Manuel Schönlaub <manuel.schoenlaub@gmail.com>
Signed-off-by: Manuel Schönlaub <manuel.schoenlaub@gmail.com>
@mschoenlaub
Copy link
Contributor Author

Hey, @maxveldink

any chance this could get approved. It would bring the RBS in a somewhat usable state.
Due to the brittleness of RBS and the active development on the project itself currently, I decided to not make type checking a hard dependency for the build right now. I am open for discussion on this one though.

@mschoenlaub
Copy link
Contributor Author

Also tagging @josecolella to get a feel for who maintains this now.

@maxveldink
Copy link
Member

Howdy 👋🏻 I'll give this a look tonight and make sure I have notifications properly set up for this repo.

josecolella
josecolella previously approved these changes Sep 8, 2023
Gemfile.lock Outdated
Copy link
Collaborator

Choose a reason for hiding this comment

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

This probably shouldn't be removed. Were you running into an issue with it present?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm... I think I had a bundler version mismatch and then remebered that it wasn't recommended to check Gemfile.lock in anyways. However, this recommendation ahs since been revised and so yeah, the lockfile is back :)

@@ -26,7 +26,7 @@ def initialize(name:, version: nil)
end

def ==(other)
raise ArgumentError("Expected comparison to be between Metadata object") unless other.is_a?(Metadata)
raise ArgumentError, "Expected comparison to be between Metadata object" unless other.is_a?(Metadata)
Copy link
Member

Choose a reason for hiding this comment

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

This seems unrelated to the RBS changes. Did we pick up a new Rubocop rule?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, it's actually steep complaining.

lib/openfeature/sdk/metadata.rb:29:14: [error] Type `::OpenFeature::SDK::Metadata` does not have method `ArgumentError`
│ Diagnostic ID: Ruby::NoMethod
│
└         raise ArgumentError("Expected comparison to be between Metadata object") unless other.is_a?(Metadata)
                ~~~~~~~~~~~~~

Looking at the documentation for Kernel::raise it kind of makes sense. TIL, they are pretty clear about how thet expect raise to be used when setting an error_message.

@@ -43,6 +43,17 @@ jobs:
- run: bundle install
- name: Rubocop
run: bundle exec rubocop --color
steep:
Copy link
Member

Choose a reason for hiding this comment

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

@josecolella @technicalpickles Thoughts on enforcing this check on CI if we're going to start supporting RBS?

Signed-off-by: Manuel Schönlaub <manuel.schoenlaub@gmail.com>
@technicalpickles
Copy link
Collaborator

It's worth noting the initial rbs was just part of the bundle gem or whatever generated it, it wasn't like it was intentionally added.

@josecolella and I talked about sorbet for typing over on one earlier PRs, ie #8 . Aside from the runtime dependency, I'm in favor of holding off typing until the implementation is a bit more solid. I argued it take more time keeping the types up to date while we are still working out the details, and that that would discourage refactoring..

_:pear:'d with @josecolella on 👀 _

This was referenced Sep 12, 2023
@technicalpickles
Copy link
Collaborator

Closing for #66

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.

Amend type signatures
4 participants