Extend infer with annotations for aliases and resource deprecations
#245
Conversation
thomas11
force-pushed
the
tkappler/aliases
branch
from
e322e2c to
1e2877a
Compare
thomas11
changed the title
infer with annotations for aliases and resources deprecationsinfer with annotations for aliases and resource deprecations
|
|
||
| AddAlias(module, name string) | ||
|
|
||
| SetResourceDeprecationMessage(message string) |
There was a problem hiding this comment.
Nitpicking, but given that this is backed in the implementation by a field called DeprecationMessage, I'm inclined to think Resource is superfluous here? Moreover, if we're feeling cheeky, we could call it Deprecate to align with Describe.
There was a problem hiding this comment.
Yeah, good thoughts .. perhaps also AddAlias could just be Alias?
There was a problem hiding this comment.
I called it SetResourceDeprecationMessage because resource properties can also be deprecated. The field DeprecationMessage is on the resource level so there's no ambiguity.
For the aliases, I went with "add" because it can be called more than once to add different aliases, which I wanted to call attention to.
Let me know if my reasoning doesn't make sense to you.
There was a problem hiding this comment.
Describe also applies to both the resource and it's fields. I agree that Deprecate would have been a more consistent name.
Following up on #245, we specify the boundary requirements of `AddAlias` and `SetToken` with the types that they accept. This is a breaking change unless you are using untyped constants in `SetToken` and `AddAlias`, which I expected to be the common case.
Following up on #245, we specify the boundary requirements of `AddAlias` and `SetToken` with the types that they accept. This is a breaking change unless you are using untyped constants in `SetToken` and `AddAlias`, which I expected to be the common case.
This allows authors of providers built on
inferto alias and deprecate resources.