Raise error on unknown options
fschwahn opened this issue · comments
We just caught the following during code review:
model.to_sgid(purpose: :api, expires_at: 1.day.from_now.end_of_day)The correct option to pass is for instead of purpose. This went unnoticed because everything still works, but the default purpose is used.
Maybe it would make sense to raise an error in case an unknown option is passed to to_sgid (and friends)?
Would be nice to switch this to kwargs. Do investigate a PR.
I quickly looked into this, but this change is not possible without changing API. The reason is that all unknown options are converted to params, so for the example above this would yield: gid://app/Model/123?purpose=api.
This could be made explicit by requiring users to pass params explicitly (eg. model.to_sgid(params: { purpose: "api" }, expires_at: 1.day.from_now.end_of_day)), but I'm not sure such a breaking change would be feasible. It'd require a deprecation cycle for sure, but I'm not sure it's worth the effort?
Doesn't def to_sgid(expires_at: nil, for: :default, **params) work?
Ah sure, switching to kwargs is still possible (and may be worthwhile), but wouldn't fix the problem I originally ran into - namely that someone tried to change the purpose using the wrong keyword (ie. purpose instead of for).
oh, right. Yeah, I'm not sure it is worth the effort to have a deprecation cycle.
Just to clarify, are you saying "let's do the change, but not have a deprecation cycle" or "let's not do the change"?
I'm not sure if doing the change is worth. The new API would be worse for the most common use case. Sure, it means that people will sometimes make mistakes in the call, but that is why we recommend to write tests.